TDbf PRO disponible...

[ruben Dario]

Los índices maneja todos los tipos , los NTX y CDX etc.

Saludos

[xmanuel]

Absolutamente todos
Incluso los de ADS, Apollo, USRRDD, SQLRDD!!!

Realmente la clase se debería llamar TRDD. Si existe un RDD, TDBF_PRO lo sabe manejar

[xmanuel]

He ampliado el ejemplo con el uso de _.

Voy a prepara una demo para que podais usar TDbfPro en vuestros programas y así comprobar.

[xmanuel]

He puesto la DEMO 02 de TDbfPRO con uso de scopes y _. He documentado la clase TTest...

[FiveWiDi]

Manuel,

Creo recordar que cambié el nombre de la clase que maneja los índices para evitar conflictos con otros fuentes (creo que los propios de FiveWin).

Entre mis notas pata TDBF tengo lo siguiente:

/*
> 01/06/2006 C.Gelabert
- A la funció Str() li he afegit Str(...,5 ,0) doncs en Harbour pren els decimals
de SET DECIMALS.
< 01/06/2006

> 05/12/2007 C.Gelabert.
- A los METODOS RecLock() y UnLock() se les ha añadido el número de registro a
bloquear/desbloquear cambiando RLock() x DBRLock() y DBUnlock() x DBRUnLock().
De esta manera se persigue que se pueda realizar el bloqueo de varios registros
a voluntad, evitando que al momento de ser grabados se eliminen los bloqueos
existentes en otros registros del mismo oTDbf.
Los registros bloqueados se pueden obtener de -> aMiarray := DBRLockList().

- El METODO RecLock() ha sido modificado para evitar intentar bloquear un
registro ya bloqueado previamente.

- A la llamada al METODO Append() en el método Insert(), se le ha añadido el
parámetro .F. para evitar que se liberen los bloqueos existentes.

- Se ha creado un METODO RECLOCK2() para bloquear un registro sin posibilidad
de reintento por parte del usuario.

= Con estas modificaciones se pretende que si el programador desea realizar
bloqueos a varios registros de varios oTDbf previos a la grabación de los
datos, estos puedan realizarse manualmente y de manera controlada por la
lógica establecida por el propio programador, sin provocar que se liberen
forzosamente los bloqueos ya existentes.
Por otro lado, a medida que se vayan grabando los registros con Save(),
estos iran siendo desbloqueados uno tras otro.
< 05/12/2007

> 30/01/2008
METODO IdxActivate modificado; añadida línea "( ::nArea )->( dbClearIndex() )"
Daba error al querer crear un nuevo índice no encontrado en el CDX.
< 30/01/2008

> 13/05/2008
Añadido "lRet := ::aTFilter[ i ]:Destroy" en el METHOD DelFilter( oFlt )
(Debería haber sido una función [acabado con paréntesis] y ahorrar "lRet :=" )
< 13/05/2008

> 20/03/2009
- La DATA hDataFile estaba definida como AS NUMERIC y con la nueva versión de
Harbour (9.02), y el cambio del 'valor' hDataFile por pDataFile en la
estructura _DBFAREA de HbRddDbf.h, esta definición era incompatible; de ahí
que ahora en la declaración de DATA hDAtaFile se haya omitido AS NUMERIC.
< 20/03/2009

> 04/11/2009
En el METHOD KillFilter( lDelfilter ) se ha añadido el parámetro lDelFilter
para forzar la eliminación del filtro activo y del ::oFilter.
En el METHOD DelFilter( oFlt ) se ha dado valor a la variable
cName := "1234567890poiuytr" para evitar que valga Nil y se produzca una
comparación de una cadena a un Nil cuando en este método se recibe como
parámetro un Nil
< 04/11/2009

> 14/09/2010
En el METODO Save() se le añade un 'Commit' faltante.
< 14/09/2010

> 15/09/2010
Modificat METHOD ChangeMark(), para no alterar los registros borrados.
Modificat METHOD GetStatus() i SetStatus(), añadiendo ::SetFilter().
<

> 21/01/2011
Per a ser compatible amb XBROWSE:
+afegit METHOD SETXBROWSE()
+afegit tambe #define DATATYPE_ODBF 16
#define DBS_TAG 8
#define VK_ESCAPE 27 // 0x1B
<
*/

Saludos,

[xmanuel]

Carlos está claro que has seguido con TDbf de toda la vida, lo cual me enhorgullece un montón.
Me encantaría que me ayudaras a mejorar TDbfPRO con tus ideas.

Quiero decirte que la nueva TDbf es un desarrollo absolutamente diferente, no tiene nada que ver con lo antigua. He primado la velocidad y por eso esta hecha en C al 100 * 100

Voy a implenetar todo lo que se pueda y te aviso de lo que no estará de entrada.

En la vieja TDbf todos los componentes eran objetos, en la nueva los he evitado y ahora son metodos de la clase principal.
En la mediad de lo posible, los métodos tienen los mismos parámetros que la función DB...().

Ya te comento. Si quieres me das un teléfono y te llamo y hablamos un poco del tema

PD: Todo lo que se te ocurra me lo dices ok?

[FiveWiDi]

Carlos está claro que has seguido con TDbf de toda la vida, lo cual me enhorgullece un montón.
Me encantaría que me ayudaras a mejorar TDbfPRO con tus ideas.

Quiero decirte que la nueva TDbf es un desarrollo absolutamente diferente, no tiene nada que ver con lo antigua. He primado la velocidad y por eso esta hecha en C al 100 * 100

Voy a implenetar todo lo que se pueda y te aviso de lo que no estará de entrada.

En la vieja TDbf todos los componentes eran objetos, en la nueva los he evitado y ahora son metodos de la clase principal.
En la mediad de lo posible, los métodos tienen los mismos parámetros que la función DB...().

Ya te comento. Si quieres me das un teléfono y te llamo y hablamos un poco del tema

PD: Todo lo que se te ocurra me lo dices ok?

Muchas gracias Manuel por la atención, es un orgullo.
Sinceramente no estoy en condiciones de poder colaborar, no dispongo de tiempo. Estoy atento a este foro y todo lo veo pasar con ganas de poder participar, pero no me es posible. Sólo has de ver los días que he tardado en aportar algo que sólo costaba un copiar pegar.

Estaré encantado de poder aportar todo lo que se me ocurra, así como mirarlo con cariño, no lo dudes.

Saludos,

[wilsongamboa]

Estimado Manuel
Siempre me ha intrigado porque no desarrollas tu un sqlrdd me parece que tienes el suficiente conocimiento para hacerlo prácticamente ese era el mercado de xharbour.com
Y claro sería un mercado inmenso para ese producto ya que los de la competencia son muy caros
Atento a tus comentarios
Saludos desde Ecuador

[xmanuel]

Muchísimas gracias Wilson. Tus palabras son muy alentadoras.

La verdad es que he pensado más de una vez hacer algo al respecto, pero siempre llego a la conclusión de que son tecnología muy diferentes e intentar aunar esos mundo sería incluso perjudicial para los usuarios de cualquier xBase (harbour, xharbour, etc ) ya que intentarían seguir con las RDD cuando lo que hay que hacer es dar el salto definitivo al mundo SQL.

Estoy empeñado en hacer algo muy parecido a las RDD pero para el mundo SQL, es decir, hacer un programa para un servidor concreto, MySQL, SQLite o cualquier otro pero que se pudiera cambiar ese servidor sin tener que cambiar el programa, como mucho recompilarlo, sin cambiar nada o casi nada. La idea es hacer un PDO de PHP pero para Harbour, el HDO o XDO como queramos que se llame. Digo lo de recompilar el programa para no recargar el EXE con todos los SQLLink (como yo los llamo).
Por ejemplo habría un SQLLink para MySQL-MariaDB, otro para SQLite, para FireBird, PostgreSQL... en principio los gratuitos y más adelante los de pago como Oracle o SQLServer.

La clases básicas de las que se compondría XDO serían:
- DataBase - Conexión: para establecer la conexion con la base de datos del servidor
- Command: Ejecutar commandos que no devuelvan un resultado en forma de conjunto de datos como INSERT, UPDATE o DELETE
- DataSet: Ejecuta sentencias SQL que devuelven un conjunto de datos y lo gestiona.
- DataSet preparadas: igual que la anterior pero con sentencias preparadas en el lado del servidor.
- Table: sería lo más parecido a las DBF, tendría los GOTO, SKIP, APPEND, etc
- Error: Controlar errores y exepciones

En la clase Database se le diría al sistema con que SQLLink se va a trabajar, el resto de las clases sería identico. Por ejemplo:

...
local oDb := XDO():new( "MySQL" ) // Esta sería la linea que cambiaría

if oDb:connect( cHost, cUser, cPasswd, cDbName )
...
endif

oDb:free()
...

Esa es la idea, qué te parece?

[wilsongamboa]

Estimado Manuel
Gracias por tus respuestas
Me parece muy buena tu idea
Mi enfoque estaba mas bien en crear un producto que se coma los millones de millones de lineas que estan escritas para dbf y que a su vez permita ir migrando las partes que se necesiten poco a poco para aprovechar los beneficios de las bases de datos ya que el modelo DBF es muy diferente
Siempre que se ha discutido de este RDD se ha llegado a un punto muerto pero cuando salio SQLRDD de xharbour.com las ventas que ellos hicieron en su mayoria fueron por ese RDDSQL ya que existe millones de programas escritos que necesitan este empujon
Seria un enorme exito comercial
gracias por tu tiempo

saludos

[elvira]

Hola,

Yo voto por sqlrdd porque a esta clase no le veo utilidad.

Cada vez estamos abandonando los dbfs...

Un saludito

[FiveWiDi]

Hola,
Yo voto por sqlrdd porque a esta clase no le veo utilidad.
Cada vez estamos abandonando los dbfs...
Un saludito

Yo desarrollo muy poco, pero con los DBF tengo suficiente y TDBF es esencial para mi, si no existiera debería fabricarla.

[elvira]

Carlos,

Ahora el mercado exige la cloud y poder acceder remotamente a la datos, por lo que las dbfs son ya una antigualla .

Si se necesitan dbfs para poquita cosa ya está tdbf que Mr. Nages ha ampliado. No veo la recompensa ni la utilidad de este trabajo de Manuel, cuando la corriente mayoritaria queremos un sqlrdd para en un primer momento poder funcionar y luego poco a poco ir cambiando millones de código... Que no es tal fácil

[Carlos Mora]

Hola Manu!

La verdad es que he pensado más de una vez hacer algo al respecto, pero siempre llego a la conclusión de que son tecnología muy diferentes e intentar aunar esos mundo sería incluso perjudicial para los usuarios de cualquier xBase (harbour, xharbour, etc ) ya que intentarían seguir con las RDD cuando lo que hay que hacer es dar el salto definitivo al mundo SQL.

Coincido plenamente, la práctica me ha enseñado que es muy dificil reproducir el comportamiento de las dbfs (ISAM) con un motor de SQL. El esfuerzo que hay que hacer para la 'imitación' y los cuidados que hay que tener con las estructuras, sumado a que sigues limitando la compatibilidad y convivencia en el acceso de otras aplicaciones de terceros, me convenció de desistir de los intentos.

Estoy empeñado en hacer algo muy parecido a las RDD pero para el mundo SQL, es decir, hacer un programa para un servidor concreto, MySQL, SQLite o cualquier otro pero que se pudiera cambiar ese servidor sin tener que cambiar el programa, como mucho recompilarlo, sin cambiar nada o casi nada. La idea es hacer un PDO de PHP pero para Harbour, el HDO o XDO como queramos que se llame. Digo lo de recompilar el programa para no recargar el EXE con todos los SQLLink (como yo los llamo).
Por ejemplo habría un SQLLink para MySQL-MariaDB, otro para SQLite, para FireBird, PostgreSQL... en principio los gratuitos y más adelante los de pago como Oracle o SQLServer.

La idea de los Harbour Data Objects fue algo que en algún momento hablamos con Rafa Carmona, hace varios años ya de eso, la idea era buena pero a mi me faltaba más experiencia, haber trasteado más con los motores. No es que ahora sea un experto pero los uso a diario de forma compartida entre PHP y Harbour, y he ido puliendo las ideas originales. Además hay varios desarrollos muy interesantes como TMySQL, TDolphin, etc que como son abiertos te dan al oportunidad de aprender y sacar ideas.
En su momento pensamos en como montar la cosa de forma tal de que sea compatible con varios motores, sin que enlazase todos los drivers, y es complicado hacerlo sin recompilar.

La clases básicas de las que se compondría XDO serían:
- DataBase - Conexión: para establecer la conexion con la base de datos del servidor
- Command: Ejecutar commandos que no devuelvan un resultado en forma de conjunto de datos como INSERT, UPDATE o DELETE
- DataSet: Ejecuta sentencias SQL que devuelven un conjunto de datos y lo gestiona.
- DataSet preparadas: igual que la anterior pero con sentencias preparadas en el lado del servidor.
- Table: sería lo más parecido a las DBF, tendría los GOTO, SKIP, APPEND, etc
- Error: Controlar errores y exepciones

En la actualidad tengo algo armado para MySQL, basado en las ideas de los frameworks de PHP, TMySql y TDolphin, y es bastante parecido a lo que propones, aunque un poco más simplificado:

TConnection - La clase que hace el trabajo de mantener la conexión y ejecutar los comandos. Tiene un método Execute (Alias Command) que hace el trabajo, y varios accesorios.
TQuery - Clase para gestionar las consultas - ReadOnly
TModel - Similar a tu propuesta de TTable. ReadWrite. Hace las veces de TDBF: es un buffer de edición, sabe hacer un BLANK para editar un nuevo registro, etc.

Con estas 3 clases vengo haciendo todo lo que he necesitado hasta ahora, pero convengamos que solo son tareas de batch, traspasos, etc.

Con la práctica hemos avanzado hacia algunas cosas que nos han ayudado bastante:
usamos TEXT INTO / ENDTEXT para escribir las querys.
parametrizamos las querys con parámetros tipo $1, $2, etc.
Actualiza solo si es necesario, no incluye en la actualizacion campos que no han cambiado.

Voy a ver si los subo, querría añadirles las variaciones protegidas antes que nada.

Ejemplo de como sincronizar una tabla dbf con su contraparte SQL

Code: Select all

      oPasivos := TModel():New( oConnection, 'Pasivos' )
      USE Pasivos INDEX Pasivos NEW
      GO TOP
      WHILE !Eof()
           WITH OBJECT oPasivos 
               MsgWOn( Field->NIF, 'Actualizando pasivos...' )
               IF :GetWhere( 'NIF = $1', Field->NIF )
                  nActualizados++
               ELSE
                  :Blank()
                  nNuevos++
               ENDIF
               :FromWorkArea() // Rellena _ con los homónimos de la dbf
               :Prejubilado := (Field->Area_Per == 7)
               IF :Update()

               ELSE
                  MsgInfo( 'Problemas con NIF '+ Field->NIF )
               ENDIF
               // Traspasar Beneficios
               cTexto := "DELETE FROM ben_pasivo WHERE cod_pasivo = $1"
               IF !oServer:Command( cTexto,  Pasivos->Id )
                   MsgInfo( "|"+cTexto+"|" )
               ENDIF
               SELECT Ben_Pasivo
               dBSeek( Pasivos->Id_sap, .T. )
               WHILE !Eof() .AND. Field->Cod_pasivo == Pasivos->Id_sap
                  WITH OBJECT oBenPasivo
                     IF :GetWhere( { 'cod_pasivo', 'cod_ben' } , { Field->Cod_Pasivo, Field->Cod_Ben } )
                     ELSE
                        :Blank()
                     ENDIF
                     :FromWorkArea()
                     :Update()
                  END
                  SKIP
              ENDDO       
            ..... aca sigue mas codigo pero es igual
          ENDIF
      END
      SELECT Pasivos
      SKIP
ENDDO


 

Pero esto solo funciona con MySQL.

creo que hay ideas que te pueden resultar útiles, que podemos comentar.

Luego seguimos,

un abrazo

[xmanuel]

Hombre Carlos, desde que nos vimos en Sevilla no hemos hablado más!!!! eso hay que remediarlo tenemos que abrir una línea directa

Recuerdo las conversaciones con Rafa, Jose, tú y yo sobre el tema...

Por cierto no me mandaste eso que me comentaste en Sevilla.

Efectivamente se podría simplicar mucho más y seguramente así lo haré, el modelo PDO de PHP es muy simple y muy potente y será el que me servirá de modelo. Habrá que cambiar bastantes cosas pero seguiré ese camino.

El modelo PDO solo tiene las clases:
- PDO
- PDOStatement
- PDOException

Bueno a ver qué sale, ya iré informando.
Como siempre se admiten sugerencias


De momento sigo de vacacines en la Alpujarra granadina en Bubión y Capileira!!!!