HCAD, Acceso Comun a Bases de Datos con Harbour...

[xmanuel]

Estaría bien que de una vez por todas pudieramos tener un único programa que cambiado solo el nombre del gestor de bases de datos pudiera trabajar con cualquiera de ellas no?
Tal vez me lo tome en serio y me ponga a currar en esa idea...

Podría emezar por:
1) SQLite
2) MySQL
3) ODBC
4) Postgres
5) Firebird
6) Oracle (OCILIB)
...
No sé si falta alguna.

Lo que os pido es un análisis, o sea, clases y metodos...

Espero vuestra participación

[nageswaragunupudi]

FWH provides this facility since a long time.
Using ADO, FWH's ado and sql functions, xbrowse, datarow, trecset all work like this. At present the full support is for (1) DBase SQL, (2) MS Access, (3) MS Sql Server (including free SqlExpress), (4) Oracle, (5) MySql, (6) SqLite3, (7) SqlAnyWhere. Others are partially supported.

In other words, using these functions, same program code works with any of these servers without any change. Only change is the initial connection.

We also like to include full support for others like Postgre, Informix and Firebird, if programmers using these databases provide necessary support and feedback to us.

[xmanuel]

Ya lo sé, ya lo sé...
Y con el sistema ADO metemos capas y capas que ralentizan los proceso.
1) La capa de M$ ActiveX
2) La implementación del envoltorio en C para harbour
3) La parte PRG de harbour
4) La implementacion del vendedor del gestor de bases de datos
5) La gestion del error para hacer llamadas a ADO que hace harbour etc...

Yo propongo algo diferente y más directo.
Acceso directo al API del cliente de cada gestor de bases de datos como lo hace por ejemplo Java con JDBC o PDO de PHP.
Es más, yo haria la clases de harbour en lenguaje C con lo que nos saltaríamos incluso la maquina virtual de harbour.

De caulquier modo lo que pido es que me digais de qué clases y métodos deberíamos dotar a este sistema, por ejemplo:

La clases:
- THCADConnection
- THCADStatement
- THCADDataSet
- THCADException
Y métodos de THCADConnection:
open, close, getStatement, execDirect, etc

Claro que si no veo interés me callo y ya está

[lucasdebeltran]

Hola Manuel,

De momento el proyecto más parecido a lo que comentas es este:
viewtopic.php?f=3&t=30266

Y descargable desde:
https://github.com/AHFERREIRA/adordd

Y para nada es lento. Efectivamente es mucho mejor lo que tú propones, pero esto creo que es el comienzo.

Una vez que este RDD funcione, entonces habría que sustituir las llamadas a ADO por las llamadas a las funciones nativas.

[Carlos Mora]

....
Claro que si no veo interés me callo y ya está

Nooo, no te escapes!

La idea es muy buena! Alguna vez se habló de este tema, Rafa Carmona arrancó con algo y se debatió bastante al respecto. Su nombre consensuado fué HDO (Harbour Data Objects), pero quedó aparcado (falta de tiempo, interés, lo de siempre...).

Actualmente estoy usando mi propio código para acceder a MySQL, trasladando algunas ideas copiadas de los frameworks de PHP que he estado usando y tienen un diseño más o menos parecido, pensando siempre en la misma arquitectura:
TConnection (la unica clase que se instancia directamente en la aplicacion)
-->TQuery -- Resultado no editable de las consultas
-->TModel -- ORM (Object Relational Mapper) , crea instancias editables. Hace instrospección de los datos para crear los objetos con sus variables.
--->TRecord Las filas provistas por TModel (Active Record)

El único objeto que el programador instancia es TConnection, TQuery y TModel son creadas por TConnection (Un patrón Factory), con lo que se logra bajar el nivel de acoplamiento, el único punto fijo es la Connection en sí.
Actualmente en proceso: Tambien puedes ponerle mas inteligencia 'alimentando' el esquema con las relaciones, tipo oModelFacturas:HasMany('FacturaItems', 'Items), de forma tal que, por ejemplo, dado un objeto del tipo factura sea capaz de traer todos sus lineas con oFactura:Items, sin necesidad de escribir código extra. Tambien 'aprende' de la recíproca: Dado un item de factura oLinea, oLinea:Factura me devuelve el objeto Factura padre.

Esa estructura sencilla se puede escribir para los diferentes orígenes de datos, puede ser independiente del SSOO (me interesa que se pueda usar en Linux para proveer servicios) y de la interfaz gráfica, y con solo cambiar la conexión en el programa, ya tendrías una aplicacion 'multibase'.

Tal vez si desarrollaras el concepto de tu propuesta, mostrar un pelín más de como llevarías la funcionalidad adelante, podríamos generar algunas ideas.

Y como dice Lucas, para los que prefieren el modelo RDD ya existe ADORDD, por lo que esto lo enfocaría desde una perspectiva totalmente diferente.

[RSalazarU]

Yo creo que TAMBIEN habria que redefinir la clase TDatabase, con una jerarquia que facilitaria su manejo.

Se deberia crear una clase basica, con los metodos comunes de acceso a las tablas/BASE de DATOS

TData

TDataBase deberia descender de esa clase

TData -> TDataBase

y se podria crear otras clases que descenderian de esta clase.

TData -> TDataADS
TData -> TDataADO
TData -> TDataMySQL
TData -> TDataPosgres
TData -> TDataOracle
TData -> ..

tb se podria hacer otras combinaciones

TData -> TDataBase ->TDataADSNtx para darle las funcionalidades de ADS a TDatabase: filtros con SetAOF(), GetAOF()
TData -> TDataBase ->TDataADSCdx para darle las funcionalidades de ADS a TDatabase: filtros con SetAOF(), GetAOF()
TData -> TDataADS ADS puro y duro con instrucciones SQL: Append() con "inser into", Delete() con "delete from"

De esta forma se podria estandarizar el envio de estos objetos a XBrowse u otros DATAAWARE.
Asi xBrowse podria maner un solo objeto de acceso a los datos: cAlias, oRs, oMysql deberias ser un solo objeto

Mi humilde opinion, esperando no molestar a los GENIOS.

Atentamente,

Rolando
Cochabamba, Bolivia
www.sauro-sys.com

[lucasdebeltran]

Hola,

Fivewin ya proporciona TDataRow y TRecSet, que hacen todo ello.

ADS, en cambio, creo que cada vez está más en franco desuso.

Lo que falta es sustituir ADO por las clases que manejen directamente el motor sin la capa intermedia de ADO.

Que, por cierto, estas clases son espectaculares, gracias a Mr. Nages.

[Carlos Mora]

Hola Rolando

...
De esta forma se podria estandarizar el envio de estos objetos a XBrowse u otros DATAAWARE.
Asi xBrowse podria maner un solo objeto de acceso a los datos: cAlias, oRs, oMysql deberias ser un solo objeto
...

Ese concepto, de separar los datos de la presentación/visualización es importantísimo, me alegra que lo hayas recordado. El código de los controles, fundamentalmente los más complejos como los xBrowse, se ha vuelto dificil de seguir debido a la gran cantidad de funcionalidad que le imponen los diferentes modelos de datos. Si se pudiera concentrar en uno, simplificaria el código de una manera importante, y no necesitarian tanta adaptación con cada nueva fuente de datos.

La idea de TDatabase está más en la línea de los RDDs clásicos, tal vez sería mejor seguir con ADORDD y usar la TDatabase que ya existe. La propuesta de un HDO está más en la línea de abrir juego a otros modelos de datos, que no sean ISAM. Si nos quedásemos encasillados en él perdemos las enormes ventajas de usar motores de BBDD de verdad. Por ejemplo, considera la solución del Master Rao en viewtopic.php?f=6&t=30606 , es espectacular! Un proceso parecido hecho con DBFCDX de 100k reg me lleva varios minutos, y con MySQL solo 4 segundos.