FiveTech Support Forums

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

Saludos

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

He ampliado el ejemplo con el uso de campos calculados.

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

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

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,

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?

xmanuel wrote: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?

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

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?

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

Hola,

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

Cada vez estamos abandonando los dbfs...

Un saludito

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

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

xmanuel wrote:
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.

xmanuel wrote:
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.

xmanuel wrote:
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

      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 los campos 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

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!!!!