TDbf PRO disponible...
- wilsongamboa
- Posts: 439
- Joined: Wed Oct 19, 2005 6:41 pm
- Location: Quito - Ecuador
Re: TDbf PRO disponible...
Manuel buenas tardes
que envidia lo de las vacaciones !!!
para mi si me permites es muy simple el tema de que es lo que se haria
haz una encuesta
sqlrdd ?
sqlrdd para SQL ?
porque sigo pensando que lo del sqlrdd seria un exito
gracias por tu tiempo
que envidia lo de las vacaciones !!!
para mi si me permites es muy simple el tema de que es lo que se haria
haz una encuesta
sqlrdd ?
sqlrdd para SQL ?
porque sigo pensando que lo del sqlrdd seria un exito
gracias por tu tiempo
Wilson 'W' Gamboa A
Wilson.josenet@gmail.com
Wilson.josenet@gmail.com
- lucasdebeltran
- Posts: 1303
- Joined: Tue Jul 21, 2009 8:12 am
- Contact:
Re: TDbf PRO disponible...
Hola,
Sí, muchas gracias por la aportación, que todas son siempre bienvenidas.
Efectivamente que el SQLRDD no es fácil, pero tampoco es imposible. Patrick Mast lo tiene casi listo pero faltan ajustes, y como ni los de xHarbour están por la labor ni tampoco dan el código fuente, pues eso impide su éxito.
Si SQLRDD estuviera listo, alguna empresa como Sa... lo compraba fijo. Efectivamente que SQL implica un cambio de filosofía, pero diles que reescriban toda la parte de acceso a DBFS de sus programas insignia. Imposible. No es lo mismo adaptar programitas o trabajos esporádicos que millones de líneas de código. No hay más que ver incluso el código fuente de Windows, que tiene todavía partes de Windows 3.x y MS-DOS.
Fijaros en el ejemplo de EasyReport. Timm tenía bugs importantes y lo tenía en vía muerta y sin arreglar. Pero con la iniciativa de Antonio y el gran trabajo de Manuel y Cristóbal el producto tiene una pinta extraordinaria, es mucho más rápido que el original de Timm, se ha simplificado su código fuente, puede pasarse a 64 bits, modificarse a gusto del usuario.... Sus posibilidades son infinitas.
Sí, muchas gracias por la aportación, que todas son siempre bienvenidas.
Efectivamente que el SQLRDD no es fácil, pero tampoco es imposible. Patrick Mast lo tiene casi listo pero faltan ajustes, y como ni los de xHarbour están por la labor ni tampoco dan el código fuente, pues eso impide su éxito.
Si SQLRDD estuviera listo, alguna empresa como Sa... lo compraba fijo. Efectivamente que SQL implica un cambio de filosofía, pero diles que reescriban toda la parte de acceso a DBFS de sus programas insignia. Imposible. No es lo mismo adaptar programitas o trabajos esporádicos que millones de líneas de código. No hay más que ver incluso el código fuente de Windows, que tiene todavía partes de Windows 3.x y MS-DOS.
Fijaros en el ejemplo de EasyReport. Timm tenía bugs importantes y lo tenía en vía muerta y sin arreglar. Pero con la iniciativa de Antonio y el gran trabajo de Manuel y Cristóbal el producto tiene una pinta extraordinaria, es mucho más rápido que el original de Timm, se ha simplificado su código fuente, puede pasarse a 64 bits, modificarse a gusto del usuario.... Sus posibilidades son infinitas.
Muchas gracias. Many thanks.
Un saludo, Best regards,
Harbour 3.2.0dev, Borland C++ 5.82 y FWH 13.06 [producción]
Implementando MSVC 2010, FWH64 y ADO.
Abandonando uso xHarbour y SQLRDD.
Un saludo, Best regards,
Harbour 3.2.0dev, Borland C++ 5.82 y FWH 13.06 [producción]
Implementando MSVC 2010, FWH64 y ADO.
Abandonando uso xHarbour y SQLRDD.
Re: TDbf PRO disponible...
Es una incongruencia no usar dbf y querer usar Bases de datos SQL al estilo de una DBF. Entiendo que se quiera reutilizar todas esas miles de líneas de código pero al final será un atraso...
Por saberlo... hay alguna aplicación que use SQLRDD, ADORDD o cualquiera otra de este tipo en el mercado?
El principal problema que se me plantea es el concepto de "índice", es completamente diferente en un mundo que en otro, veréis, un índice en el mundo DBF es la ordenación usando una expresión relacionada con la DBF, en cambio, en el mundo SQL es una manera de acceder más rápida por _ que se quiera y además sólo se pueden usar expresiones SQL, para la ordenación está la cláusula "ORDER BY" de la sentencia SELECT. Cómo solventamos eso?
No sé si conocéis mi Eagle1. Además del sistema SQL viene acompañado de E1RDD que es mi propuesta inicial de RDD para MySQL, eso está hecho pero no he metido las funciones "ORD...()" por lo dicho arriba.
Además hay que conectarse con la bases de datos y para eso, no hay funciones en el mundo dbf. Yo en Eagle1, hay varios ejemplos, hago lo siguiente:
Es un mantenimiento completo de una tabla MySQL con comandos DBF...
Por saberlo... hay alguna aplicación que use SQLRDD, ADORDD o cualquiera otra de este tipo en el mercado?
El principal problema que se me plantea es el concepto de "índice", es completamente diferente en un mundo que en otro, veréis, un índice en el mundo DBF es la ordenación usando una expresión relacionada con la DBF, en cambio, en el mundo SQL es una manera de acceder más rápida por _ que se quiera y además sólo se pueden usar expresiones SQL, para la ordenación está la cláusula "ORDER BY" de la sentencia SELECT. Cómo solventamos eso?
No sé si conocéis mi Eagle1. Además del sistema SQL viene acompañado de E1RDD que es mi propuesta inicial de RDD para MySQL, eso está hecho pero no he metido las funciones "ORD...()" por lo dicho arriba.
Además hay que conectarse con la bases de datos y para eso, no hay funciones en el mundo dbf. Yo en Eagle1, hay varios ejemplos, hago lo siguiente:
Es un mantenimiento completo de una tabla MySQL con comandos DBF...
Code: Select all
//----------------------------------------------------------------------------//
// AUTOR.....: Manuel Exp¾sito Sußrez Soft4U 2002-2010 //
// CLASE.....: Pt45.prg //
// FECHA MOD.: 11/04/2010 //
// VERSION...: 6.00 //
// PROPOSITO.: Ejemplo de mantenimiento simple de una tabla //
// Como unir la potencia de los RDD y el objeto TMSTable //
//----------------------------------------------------------------------------//
//-- Definiciones ------------------------------------------------------------//
#define B_BOX ( CHR( 218 ) + CHR( 196 ) + CHR( 191 ) + CHR( 179 ) + ;
CHR( 217 ) + CHR( 196 ) + CHR( 192 ) + CHR( 179 ) + " " )
#define ID_CONSUTA 0
#define ID_MODIFICA 1
#define ID_ALTA 2
#define ID_BORRA 3
//-- Includes ----------------------------------------------------------------//
#include "InKey.ch"
#include "Eagle1.ch"
//-- Fuerza el enlazado -----------------------------------------------------//
REQUEST HB_GT_WIN
//-- Modulo principal --------------------------------------------------------//
procedure main()
local cDb := "E1Prueba"
local cTable := "Test"
local cHost := "127.0.0.1"
local cUser := "root"
local cPwd := "root"
local oCon := TMSConnect():New()
local nWA
SET DATE FORMAT TO "DD/MM/YYYY"
cls
oCon:Connect( cHost, cUser, cPwd, cDb )
if oCon:lConnected
// Se inicia el sistema E1RDD
InitE1RDD( oCon )
// A partir de aquÝ como una DBF
USE test NEW ALIAS test VIA "E1RDD"
nWA := Select( "test" )
GestBrw( nWA )
else
Alert( "No se pudo conectar..." )
endif
// Liberamos la memoria de la conexion
oCon:Free()
return
//-- Modulos auxiliares ------------------------------------------------------//
//----------------------------------------------------------------------------//
// Gestion completa de una tabla MySQL
static procedure GestBrw( nWA )
local oBrw, oCol
local lEnd := .f.
local nKey, n, nFld
local oTb := GetTableObject( nWA )
oTb:SetTinyAsLogical( .t. )
oBrw := TBrowseNew( 1, 0, MaxRow() - 1, MaxCol() )
oBrw:goTopBlock := { || ( nWA )->( DbGoTop() ) }
oBrw:goBottomBlock := { || ( nWA )->( DbGoBottom() ) }
oBrw:SkipBlock := { | n | ( nWA )->( E1DbSkipper( n ) ) }
oBrw:colorSpec := "W+/B, N/BG"
oBrw:ColSep := " │ "
oBrw:HeadSep := "─┼─"
oBrw:FootSep := "─┴─"
nFld := ( nWA )->( FCount() )
FOR n := 1 TO nFld
oBrw:AddColumn( TBColumnNew( PADL( n, 2, "0" ) + "-" + ;
( nWA )->( FieldType( n ) ) + "-" + ;
( nWA )->( FieldName( n ) ), ;
GenCB( nWA, n ) ) )
NEXT
cls
@ 0, 0 SAY PadC( "Ojeando la tabla: " + ;
upper( Alias( nWA ) ), MaxCol() + 1, " " ) COLOR "W+/G+"
@ MaxRow(), 0 SAY "INS" COLOR "GR+/R+"
@ MaxRow(), Col() + 1 SAY "Altas" COLOR "W+/R+"
@ MaxRow(), Col() + 1 SAY "ENTER" COLOR "GR+/R+"
@ MaxRow(), Col() + 1 SAY "Mod." COLOR "W+/R+"
@ MaxRow(), Col() + 1 SAY "SUPR" COLOR "GR+/R+"
@ MaxRow(), Col() + 1 SAY "Bajas" COLOR "W+/R+"
@ MaxRow(), Col() + 1 SAY "F1" COLOR "GR+/R+"
@ MaxRow(), Col() + 1 SAY "Ayuda" COLOR "W+/R+"
@ MaxRow(), Col() + 1 SAY "F4" COLOR "GR+/R+"
@ MaxRow(), Col() + 1 SAY "Orden" COLOR "W+/R+"
@ MaxRow(), Col() + 1 SAY "F5" COLOR "GR+/R+"
@ MaxRow(), Col() + 1 SAY "Busca" COLOR "W+/R+"
@ MaxRow(), Col() + 1 SAY "F6" COLOR "GR+/R+"
@ MaxRow(), Col() + 1 SAY "Busca ->" COLOR "W+/R+"
@ MaxRow(), Col() + 1 SAY "ESC" COLOR "GR+/R+"
@ MaxRow(), Col() + 1 SAY "Salir" COLOR "W+/R+"
while !lEnd
oBrw:ForceStable()
nKey = InKey( 0 )
do case
case nKey == K_ESC // Salir
SetPos( MaxRow(), 0 )
lEnd = .t.
case nKey == K_F3 // Activa o desactiva forzar ancho columna
oTb:SetReadPADAll( !oTb:SetReadPADAll() )
oBrw:Configure()
case nKey == K_F4 // Establece el orden
if ElOrden( oTb )
oBrw:goTop()
endif
case nKey == K_F5 // Busca valor en columna
if !BuscaValor( oTb )
Alert( "Valor no encontrado..." )
endif
oBrw:RefreshAll()
case nKey == K_F6 // Busca siguiente columna
if !oTb:FindLikeNext()
Alert( "Valor no encontrado..." )
endif
oBrw:RefreshAll()
case nKey == K_UP // Fila anterior
oBrw:Up()
case nKey == K_DOWN // Fila siguiente
oBrw:Down()
case nKey == K_LEFT // Va a la columna antrior
oBrw:Left()
case nKey == K_RIGHT // Va a la columna siguiente
oBrw:Right()
case nKey = K_PGDN // Va a la pagina siguiente
oBrw:pageDown()
case nKey = K_PGUP // Va a la pagina antrior
oBrw:pageUp()
case nKey = K_CTRL_PGUP // Va al principio
oBrw:goTop()
case nKey = K_CTRL_PGDN // Va al final
oBrw:goBottom()
case nKey = K_HOME // Va a la primera columna visible
oBrw:home()
case nKey = K_END // Va a la ultima columna visible
oBrw:end()
case nKey = K_CTRL_LEFT // Va a la primera columna
oBrw:panLeft()
case nKey = K_CTRL_RIGHT // Va a la ultima columna
oBrw:panRight()
case nKey = K_CTRL_HOME // Va a la primera pßgina
oBrw:panHome()
case nKey = K_CTRL_END // Va a la ·ltima pßgina
oBrw:panEnd()
case nKey = K_DEL // Borra fila
Borrar( nWA, oBrw )
case nKey = K_INS // Inserta columna
Insertar( nWA, oBrw )
case nKey = K_ENTER // Modifica columna
Modificar( nWA, oBrw )
case nKey == K_F1 // Algunos datos
Alert( "Datos de la tabla " + Alias( nWA ) + ";" + ;
";Registro actual......: " + Str( ( nWA )->( RecNo() ) ) + ;
";Total de registros...: " + Str( ( nWA )->( RecCount() ) ) + ;
";Total de columnas....: " + Str( ( nWA )->( FCount() ) ) )
endcase
end
return
//----------------------------------------------------------------------------//
// Crea los codeblock SETGET de las columnas del browse
static function GenCB( nWA, n ) ; return( { || ( nWA )->( FieldGet( n ) ) } )
//----------------------------------------------------------------------------//
// Pantalla de datos de la tabla
static function PantMuestra( nWA, nTipo )
local GetList := {}
local cTipo, cId
do case
case nTipo == ID_ALTA
cTipo := "Insertando"
cId := "nuevo"
case nTipo == ID_BORRA
case nTipo == ID_CONSUTA
case nTipo == ID_MODIFICA
cTipo := "Modificando"
cId := StrNum( ( nWA )->Id )
end
SET CURSOR ON
DispBox( 3, 2, 18, 74, B_BOX )
@ 04, 03 SAY cTipo + " registro en tabla " + Alias( nWA ) + " - Numero: " + cId
@ 06, 03 SAY "First....:" GET ( nWA )->First PICTURE "@K"
@ 07, 03 SAY "Last.....:" GET ( nWA )->Last PICTURE "@K"
@ 08, 03 SAY "Street...:" GET ( nWA )->Street PICTURE "@K"
@ 09, 03 SAY "City.....:" GET ( nWA )->City PICTURE "@K"
@ 10, 03 SAY "State....:" GET ( nWA )->State PICTURE "@K"
@ 11, 03 SAY "Zip......:" GET ( nWA )->Zip PICTURE "@K"
@ 12, 03 SAY "Hiredate.:" GET ( nWA )->Hiredate PICTURE "@K"
@ 13, 03 SAY "Married..:" GET ( nWA )->Married PICTURE "@K"
@ 14, 03 SAY "Age......:" GET ( nWA )->Age PICTURE "@K"
@ 15, 03 SAY "Salary...:" GET ( nWA )->Salary PICTURE "@K"
@ 16, 03 SAY "Notes:"
@ 17, 03 GET ( nWA )->Notes PICTURE "@K"
return( GetList )
//----------------------------------------------------------------------------//
// Inserta una fila
static procedure Insertar( nWA, oBrw )
local GetList := {}
local cPant := SaveScreen( 3, 2, 18, 74 )
( nWA )->( DbAppend() )
GetList := PantMuestra( nWA, ID_ALTA )
READ
set cursor off
RestScreen( 3, 2, 18, 74, cPant )
if LastKey() != K_ESC .and. Updated()
( nWA )->( DbCommit() )
Alert( "Tupla insertada" )
oBrw:goBottom()
oBrw:RefreshAll()
endif
return
//----------------------------------------------------------------------------//
// Modifica la fila actual
static procedure Modificar( nWA, oBrw )
local GetList := {}
local nRecNo := ( nWA )->( RecNo() )
local cPant := SaveScreen( 3, 2, 18, 74 )
GetList := PantMuestra( nWA, ID_MODIFICA )
READ
set cursor off
RestScreen( 3, 2, 18, 74, cPant )
if LastKey() != K_ESC .and. Updated()
( nWA )->( DbCommit() )
( nWA )->( DbGoTo( nRecNo ) )
oBrw:RefreshAll()
endif
return
//----------------------------------------------------------------------------//
// Borra la fila actual
static procedure Borrar( nWA, oBrw )
local nRecNo := ( nWA )->( RecNo() )
if Alert( "Realmente quieres borrar el registro?", { "Si", "No" } ) == 1
( nWA )->( DbDelete() )
Alert( "Borrado en el servidor" )
( nWA )->( DbGoTo( nRecNo ) )
oBrw:RefreshAll()
else
Alert( "No se ha borrado..." )
endif
return
//----------------------------------------------------------------------------//
// Establece un nuevo orden de visualizacion
static function ElOrden( oTb )
local i := oTb:FieldCount()
local aFld := Array( i )
local n, lRet
FOR n := 1 TO i
aFld[ n ] := oTb:FieldName( n )
NEXT
DispBox( 5, 9, 10, 25, B_BOX )
i := 0
i := AChoice( 6, 10, 9, 24, aFld )
if lRet := ( i > 0 )
Alert( "Ordenado por la columna: " + StrNum( i ) + " " + oTb:FieldName( i ) )
oTb:SetOrderBy( i,, .t. )
endif
return( lRet )
//----------------------------------------------------------------------------//
// Busca un valor de una columna
static function BuscaValor( oTb )
local GetList := {}
local nCol := 0
local lRet, uVal
DispBox( 5, 5, 8, 75, B_BOX )
@ 6, 10 SAY "Entre numero de columna:" GET nCol PICTURE "@K"
READ
if nCol > 0 .and. nCol <= oTb:FieldCount()
uVal := oTb:FieldGet( nCol )
@ 7, 10 SAY "Entre valor buscado:" GET uVal PICTURE "@K"
READ
// Ojo cuando es tipo caracter (x)Harbour mete espacios hasta el final
// del ancho del campo
uVal := if( ValType( uVal ) == "C", AllTrim( uVal ), uVal )
lRet := oTb:FindLike( nCol, uVal, .t. )
else
lRet := .f.
Alert( "Emtre un n·mero de columna correcto" )
endif
return( lRet )
//----------------------------------------------------------------------------//
______________________________________________________________________________
Sevilla - Andalucía
Sevilla - Andalucía
Re: TDbf PRO disponible...
Se me olvidaba E1RDD se puede usar con la nueva TDbfPRO
______________________________________________________________________________
Sevilla - Andalucía
Sevilla - Andalucía
- wilsongamboa
- Posts: 439
- Joined: Wed Oct 19, 2005 6:41 pm
- Location: Quito - Ecuador
Re: TDbf PRO disponible...
Manuel buenos dias
Muchas gracias por tu ejemplo
En cuanto a que software esta en el mercado con SQLRDD ? me parece que el software del maestro Arteaga de México esta hecho con SQLRDD y asi mismo he visto varios programas con MEDIATOR
Me parece que lo mismo se decía de Harbour cuando iba en sus inicios, que los SO estaban evolucionados, que no habia como implementar tal o cual caracteristica, etc, siempre que se habla de esto se cierra el capitulo con decir que son modelos diferentes, de hecho lo son pero siempre hay la necesidad y si existe la solucion pues por ahi nos vamos, pero insisto seria un producto de mucho exito, y como he visto los que lo usan van afinanfo las consultas, o los update, etc, con el mismo SQLRDD que permite enviar comandos SQL a la base de datos, es mas estoy convencido que lo que tienes escrito tu va a servir para ese SQLRDD ya que ya tienes hecho clases que acceden o encapsulan los comandos SQL y esa creo seria parte del SQLRDD
En fin muchas gracias por tu tiempo, aprecio mucho poder ser escuchado po un genio como tu
Un abrazo desde Ecuador
Muchas gracias por tu ejemplo
En cuanto a que software esta en el mercado con SQLRDD ? me parece que el software del maestro Arteaga de México esta hecho con SQLRDD y asi mismo he visto varios programas con MEDIATOR
Me parece que lo mismo se decía de Harbour cuando iba en sus inicios, que los SO estaban evolucionados, que no habia como implementar tal o cual caracteristica, etc, siempre que se habla de esto se cierra el capitulo con decir que son modelos diferentes, de hecho lo son pero siempre hay la necesidad y si existe la solucion pues por ahi nos vamos, pero insisto seria un producto de mucho exito, y como he visto los que lo usan van afinanfo las consultas, o los update, etc, con el mismo SQLRDD que permite enviar comandos SQL a la base de datos, es mas estoy convencido que lo que tienes escrito tu va a servir para ese SQLRDD ya que ya tienes hecho clases que acceden o encapsulan los comandos SQL y esa creo seria parte del SQLRDD
En fin muchas gracias por tu tiempo, aprecio mucho poder ser escuchado po un genio como tu
Un abrazo desde Ecuador
Wilson 'W' Gamboa A
Wilson.josenet@gmail.com
Wilson.josenet@gmail.com
Re: TDbf PRO disponible...
Difiero de los que prefieren un RDD para manejar bases de datos, SQL.
Si los RDD lo que hacen es ejecutar una sentencia SQL, SELECT,INSERT,UPDATE,DELETE, etc.
porque no usar directamente estas sentencias desde nuestro código.
Concuerdo completamente con Manuel seguir con los RDD es seguir pensando en las DBFs.
Para desarrollar con tecnología SQL es primordial dejar de ver a las SQL como DBF,
partiendo de eso coincido con el colega Carlos, seria mejor desarrollar CLASES ( CLASS )
que nos ayuden a llevar nuestro desarrollo a un entorno mas comercial, ya que hoy en dia
es difícil competir con aplicaciones que están desarrolladas para conexión remota,
las DBFs no sirven para eso y las SQL si fueron diseñadas para este tipo de entorno.
Carlos por cierto seria bueno que compartieras un poco de lo que haces con fwh/sql/php
creo que ese es el camino a seguir.
Saludos..
Si los RDD lo que hacen es ejecutar una sentencia SQL, SELECT,INSERT,UPDATE,DELETE, etc.
porque no usar directamente estas sentencias desde nuestro código.
Concuerdo completamente con Manuel seguir con los RDD es seguir pensando en las DBFs.
Para desarrollar con tecnología SQL es primordial dejar de ver a las SQL como DBF,
partiendo de eso coincido con el colega Carlos, seria mejor desarrollar CLASES ( CLASS )
que nos ayuden a llevar nuestro desarrollo a un entorno mas comercial, ya que hoy en dia
es difícil competir con aplicaciones que están desarrolladas para conexión remota,
las DBFs no sirven para eso y las SQL si fueron diseñadas para este tipo de entorno.
Carlos por cierto seria bueno que compartieras un poco de lo que haces con fwh/sql/php
creo que ese es el camino a seguir.
Saludos..
Cesar Cortes Cruz
SysCtrl Software
Mexico
' Sin +- FWH es mejor "
SysCtrl Software
Mexico
' Sin +- FWH es mejor "
Re: TDbf PRO disponible...
Manuel,
SQLRDD sí lo emplean en aplicaciones comerciales, el propio Patrick Mast, Alfredo Arteaga y la gente de FivewinBrasil con muchas instalaciones allí, porque además Luiz es uno de sus desarrolladores, entre otros.
Ellos hicieron una simulación de los índices. Lo mejor es que bajaras la demo y vieras cómo lo hacen:
http://ul.to/8tcl5aut
Sabemos que no es fácil. Pero la gente contraria a la idea para nada tiene la verdad absoluta y, como no entienden lo que es tener millones de líneas de código frente a sus aplicaciones sencillitas y simplitas, no tienen ni idea de lo que proponen es muy duro, porque el cliente no le interesan los temas técnicos, quieren unas prestaciones a un precio cada vez más competitivo...
SQLRDD sí lo emplean en aplicaciones comerciales, el propio Patrick Mast, Alfredo Arteaga y la gente de FivewinBrasil con muchas instalaciones allí, porque además Luiz es uno de sus desarrolladores, entre otros.
Ellos hicieron una simulación de los índices. Lo mejor es que bajaras la demo y vieras cómo lo hacen:
http://ul.to/8tcl5aut
Sabemos que no es fácil. Pero la gente contraria a la idea para nada tiene la verdad absoluta y, como no entienden lo que es tener millones de líneas de código frente a sus aplicaciones sencillitas y simplitas, no tienen ni idea de lo que proponen es muy duro, porque el cliente no le interesan los temas técnicos, quieren unas prestaciones a un precio cada vez más competitivo...
Re: TDbf PRO disponible...
SQLRDD +++++1
Tengo una aplicación que hunde sus raíces a FiveDos en 1995, luego la pasé a Fivewin.
Ya la migración a 32 bits fue dolorosa, cómo para ahora reescribir la capa de datos.... No way.
Tengo una aplicación que hunde sus raíces a FiveDos en 1995, luego la pasé a Fivewin.
Ya la migración a 32 bits fue dolorosa, cómo para ahora reescribir la capa de datos.... No way.
Saludos,
Eduardo
Eduardo
-
- Posts: 93
- Joined: Mon Apr 30, 2012 9:10 am
Re: TDbf PRO disponible...
Yo también estaría interesado en un SQLRDD de pago.
Muchas gracias.
Muchas gracias.
Re: TDbf PRO disponible...
Hola FiveWinners.
El uso de SQLRDD se ha convertido en un MITO, en mi opinion, no tiene que ver la forma de pensar tipo DBF o tipo SQL. es mejor verlo como un solucion mas para reducir el tiempo y codigo en la construccion de aplicaciones comerciales.
Es rapido, seguro, confiable, y lo mejor de todo, es que escribes nuevas aplicaciones y migras la ya existentes con minimo de esfuerzo, haciendo el codigo compatible.
Para aplicaciones comerciales que requieren un mayor nivel de seguridad en la infromación es mejor usar SQLRDD.
Otro gran ventaja es que te permite construir tu propia NUBE y tener alli tus aplicaciones.
Saludos
El uso de SQLRDD se ha convertido en un MITO, en mi opinion, no tiene que ver la forma de pensar tipo DBF o tipo SQL. es mejor verlo como un solucion mas para reducir el tiempo y codigo en la construccion de aplicaciones comerciales.
Es rapido, seguro, confiable, y lo mejor de todo, es que escribes nuevas aplicaciones y migras la ya existentes con minimo de esfuerzo, haciendo el codigo compatible.
Para aplicaciones comerciales que requieren un mayor nivel de seguridad en la infromación es mejor usar SQLRDD.
Otro gran ventaja es que te permite construir tu propia NUBE y tener alli tus aplicaciones.
Saludos
Visite Chiapas, el paraiso de México.
-
- Posts: 1033
- Joined: Fri Oct 07, 2005 3:33 pm
- Location: Cochabamba - Bolivia
Re: TDbf PRO disponible...
Buenas tardes,
siempre es interesante este tema de las DB y [x]Hb, puedo dar mi opinion?
Creo que un camino posible es el tema de los datasource como una capa de abstracción y tener todo para arriba estandarizado.
Yo trabajo con ADS, porque me da lo mejor de los dos mundos ISAM y SQL, y también se lo puede tomar como ejemplo, ya que ADS para el resultado de una consulta sql utiliza una tabla ( dbf o adt) como cursor de resultado y esa se puede manipular como siempre lo hacemos, en esa idea se podría tener una capa abajo para atacar las DB y los resultados manejarlos como siempre a través de un RDD adecuado que en general no romperia mucho las aplicaciones actuales, siendo necesario hacer algún cambio en las operaciones de altas, bajas y modificaciones que de verdad con SQL son mucho mas sencillas .
El trabajar con SQL es mucho mas sencillo que solo tener la forma tradicional de navegación, para mi, la combinación es lo mejor, pero no creo que sea tan sencillo.
Saludos
Marcelo
siempre es interesante este tema de las DB y [x]Hb, puedo dar mi opinion?
Creo que un camino posible es el tema de los datasource como una capa de abstracción y tener todo para arriba estandarizado.
Yo trabajo con ADS, porque me da lo mejor de los dos mundos ISAM y SQL, y también se lo puede tomar como ejemplo, ya que ADS para el resultado de una consulta sql utiliza una tabla ( dbf o adt) como cursor de resultado y esa se puede manipular como siempre lo hacemos, en esa idea se podría tener una capa abajo para atacar las DB y los resultados manejarlos como siempre a través de un RDD adecuado que en general no romperia mucho las aplicaciones actuales, siendo necesario hacer algún cambio en las operaciones de altas, bajas y modificaciones que de verdad con SQL son mucho mas sencillas .
El trabajar con SQL es mucho mas sencillo que solo tener la forma tradicional de navegación, para mi, la combinación es lo mejor, pero no creo que sea tan sencillo.
Saludos
Marcelo
-
- Posts: 988
- Joined: Thu Nov 24, 2005 3:01 pm
- Location: Madrid, España
Re: TDbf PRO disponible...
Buenas...
es un debate muy interesante.
Se pueden plantear muchas situaciones y ejemplos de 'parecidos' entre dbfs y sql. Para encontrar un sentido a las ideas habría que considerar ¿Por qué queremos SQL?
1) ¿Porque es una solución cliente servidor? En ese caso ¿No sería mejor usar ADS, Apollo o LetoDB? No requieren casi ajustes en las aplicaciones existentes, solo lo de administrar la conexión. Hay poco que aprender en el manejo de datos, seguimos con el modelo ISAM tal y cual lo conocemos, funciona con FW. La única desventaja es que esos productos están tecnológicamente limitados, aislados de otros ambientes de desarrollo, incluyendo la cada vez más importante web.
2) ¿Me quiero renovar y actualizar? Imprescindible usar SQL. Y pronto, que ya hay nuevos 'kids' en el barrio como NoSQL, MongoDb, etc. Es cierto, no es sencillo: El cambio exige un nuevo aprendizaje, adquirir nuevas experiencias, aprender a gestionar los servidores y bases de datos, autenticación, nuevo lenguaje de manipulacion de datos, etc. Pero compensa en velocidad, seguridad, integración con otros sistemas, escalabilidad, y es un jugador clave en la web. Y tenemos muchas librerías existentes (TDolphin, TMySQL, Eagle) que hacen el 'trabajo sucio' liberándonos para aprender paulatínamente SQL y adquirir nuevas experiencias. Puedes contar además con usuarios que ayudan, los autores son accesibles, cosa difícil y poco frecuente.
3) ¿RDDSQL? Teniendo en cuenta que (como seguramente tarde o temprano sucede) la aplicación de escritorio compartirá datos con aplicaciones web, con lo que los artilugios de _recno(), claves e índices extras añadidos necesarios para simular el comportamiento de las dbfs las vuelven inviables. Solo si nuestra aplicación vive aislada se pueden utilizar con esas particularidades, pero en ese caso la solución que parece ser más lógica y conveniente es usar un cliente servidor de dbfs. Usar un servidor SQL requiere aprender a gestionarlo, y hay que aprender SQL de todas maneras, porque también tendremos que mantener los datos.
Una situación muy parecida: El paso de MS-DOS a Windows ¿Lo recuerdan? Aparecieron muchas herramientas y lenguajes para desarrollar en Windows, Visual Objects, xBase++, etc. y junto a ellas infinidad de herramientas de migración 'automágicas' que convertirían nuestras aplicaciones de escritorio en perfectas aplicaciones Windows. ¿Que pasó en ese entonces? Que esas herramientas fueron un fiasco, nunca funcionaron porque lo que pretendian hacer era imposible: simular un ambiente en otro. Lo poco que se transformó no se usó por mucho tiempo, y no se pudo capitalizar nada del esfuerzo realizado porque lo nuevo se hacía para Windows directamente. Al final la solución viable vino por cambiar de modelo (y es por eso que estamos en este foro).
Mis 2 centavos... Menuda charla, jaja.
es un debate muy interesante.
Se pueden plantear muchas situaciones y ejemplos de 'parecidos' entre dbfs y sql. Para encontrar un sentido a las ideas habría que considerar ¿Por qué queremos SQL?
1) ¿Porque es una solución cliente servidor? En ese caso ¿No sería mejor usar ADS, Apollo o LetoDB? No requieren casi ajustes en las aplicaciones existentes, solo lo de administrar la conexión. Hay poco que aprender en el manejo de datos, seguimos con el modelo ISAM tal y cual lo conocemos, funciona con FW. La única desventaja es que esos productos están tecnológicamente limitados, aislados de otros ambientes de desarrollo, incluyendo la cada vez más importante web.
2) ¿Me quiero renovar y actualizar? Imprescindible usar SQL. Y pronto, que ya hay nuevos 'kids' en el barrio como NoSQL, MongoDb, etc. Es cierto, no es sencillo: El cambio exige un nuevo aprendizaje, adquirir nuevas experiencias, aprender a gestionar los servidores y bases de datos, autenticación, nuevo lenguaje de manipulacion de datos, etc. Pero compensa en velocidad, seguridad, integración con otros sistemas, escalabilidad, y es un jugador clave en la web. Y tenemos muchas librerías existentes (TDolphin, TMySQL, Eagle) que hacen el 'trabajo sucio' liberándonos para aprender paulatínamente SQL y adquirir nuevas experiencias. Puedes contar además con usuarios que ayudan, los autores son accesibles, cosa difícil y poco frecuente.
3) ¿RDDSQL? Teniendo en cuenta que (como seguramente tarde o temprano sucede) la aplicación de escritorio compartirá datos con aplicaciones web, con lo que los artilugios de _recno(), claves e índices extras añadidos necesarios para simular el comportamiento de las dbfs las vuelven inviables. Solo si nuestra aplicación vive aislada se pueden utilizar con esas particularidades, pero en ese caso la solución que parece ser más lógica y conveniente es usar un cliente servidor de dbfs. Usar un servidor SQL requiere aprender a gestionarlo, y hay que aprender SQL de todas maneras, porque también tendremos que mantener los datos.
Una situación muy parecida: El paso de MS-DOS a Windows ¿Lo recuerdan? Aparecieron muchas herramientas y lenguajes para desarrollar en Windows, Visual Objects, xBase++, etc. y junto a ellas infinidad de herramientas de migración 'automágicas' que convertirían nuestras aplicaciones de escritorio en perfectas aplicaciones Windows. ¿Que pasó en ese entonces? Que esas herramientas fueron un fiasco, nunca funcionaron porque lo que pretendian hacer era imposible: simular un ambiente en otro. Lo poco que se transformó no se usó por mucho tiempo, y no se pudo capitalizar nada del esfuerzo realizado porque lo nuevo se hacía para Windows directamente. Al final la solución viable vino por cambiar de modelo (y es por eso que estamos en este foro).
Mis 2 centavos... Menuda charla, jaja.
Saludos
Carlos Mora
http://harbouradvisor.blogspot.com/
StackOverflow http://stackoverflow.com/users/549761/carlos-mora
“If you think education is expensive, try ignorance"
Carlos Mora
http://harbouradvisor.blogspot.com/
StackOverflow http://stackoverflow.com/users/549761/carlos-mora
“If you think education is expensive, try ignorance"
Re: TDbf PRO disponible...
Estimados,
El uso de datasources, como comenta Marcelo, es lo ideal. Lástima, pero no lo tenemos.
Me gusta lo que dice Carlos Mora pero algunas cosas no las veo exactamente como él plantea:
1) "Teniendo en cuenta que (como seguramente tarde o temprano sucede) la aplicación de escritorio compartirá datos con aplicaciones web"... "Solo si nuestra aplicación vive aislada se pueden utilizar con esas particularidades"... eso no es cierto... una aplicación puede usar dos motores de datos: uno RDD y otro SQL. El SQL se utilizará para los datos remotos.
2) "Infinidad de herramientas de migración 'automágicas'" No estoy de acuerdo pq algunas de esas herramientas permitían una programación híbrida text GUI/ graphica GUI y eso facilitaba muchisimo la migracion de los programas. Y por no decir que lastima que entonces no hubiera existido el hbQTWidgets de Pritpal Bedi que se "come" todo el codigo Clipper y genera una aplicacion "Windows's style like".
Cordialmente
El uso de datasources, como comenta Marcelo, es lo ideal. Lástima, pero no lo tenemos.
Me gusta lo que dice Carlos Mora pero algunas cosas no las veo exactamente como él plantea:
1) "Teniendo en cuenta que (como seguramente tarde o temprano sucede) la aplicación de escritorio compartirá datos con aplicaciones web"... "Solo si nuestra aplicación vive aislada se pueden utilizar con esas particularidades"... eso no es cierto... una aplicación puede usar dos motores de datos: uno RDD y otro SQL. El SQL se utilizará para los datos remotos.
2) "Infinidad de herramientas de migración 'automágicas'" No estoy de acuerdo pq algunas de esas herramientas permitían una programación híbrida text GUI/ graphica GUI y eso facilitaba muchisimo la migracion de los programas. Y por no decir que lastima que entonces no hubiera existido el hbQTWidgets de Pritpal Bedi que se "come" todo el codigo Clipper y genera una aplicacion "Windows's style like".
Cordialmente
-
- Posts: 988
- Joined: Thu Nov 24, 2005 3:01 pm
- Location: Madrid, España
Re: TDbf PRO disponible...
Estimado hmpaquito,
Pero en esa época hubiese sido complicado para hbQTWidgets, Harbour no estaba tan maduro como hubiese sido necesario, y lo mismo que QT, que tenía además un licenciamiento bastante estricto y poco viable para el modelo Clipper/Harbour.
No recuerdo ninguna herramienta que se 'comiese' el código tal y como estaba, todas requerían bastantes adapataciones a la idiosincracia propia de Windows, y a un contexto orientado a eventos. La programación híbrida puede haber facilitado la migración, pero no nos eximía de tener que hacerla, y de tener que aprender tarde o temprano los conceptos que le son propios al entorno Windows, y por supuesto, hacer nuevas experiencias y conocimiento del nuevo medio. Y como resultado nos dejaba un producto válido como resultado de una migración, pero comparado con una aplicación hecha nativamente para ese entorno seguramente dejaba bastantes cosas muy mejorables.
Como experiencia personal, cuando enfrentamos el dilema de la migración, elegimos FW, y no nos fue tan mal . Tuvimos que repensar todo en los términos del nuevo ambiente, pero significó un avance para nuestras aplicaciones en terminos cualitativos, y lo que parecieron en un principio costes se transformaron en inversión.
Al margen de todo esto, la idea no era discutir sobre migraciones de MSDOS a Windows, sino la similaridad de la situación respecto de los datos, RDD y SQL. La idea del debate es que a veces los puntos de vista no consideran o valoran correctamente todas las posibilidades, y la idea del RDDSQL requiere un esfuerzo que me parece que no compensa en comparación con las adaptaciones.
Un saludo
Esa idea no es contraria a lo que propongo. Donde ya hay código, sigues con RDDs. Donde hay código nuevo, por ejemplo en los datos remotos, SQL. De hecho es como lo estoy haciendo con los proyectos antiguos: RDDs para la aplicación de escritorio (DBFCDX y ADS) y SQL para la interfaz con WEB.hmpaquito wrote: 1) "Teniendo en cuenta que (como seguramente tarde o temprano sucede) la aplicación de escritorio compartirá datos con aplicaciones web"... "Solo si nuestra aplicación vive aislada se pueden utilizar con esas particularidades"... eso no es cierto... una aplicación puede usar dos motores de datos: uno RDD y otro SQL. El SQL se utilizará para los datos remotos.
Honestamente no conozco hbQTWidgets, creía que era una librería de acceso a QT, no le conocía esas habilidades. Lo poco que había visto no se parece en nada al código Clipper antiguo, por eso nunca lo había tenido en cuenta como herramienta de migración.hmpaquito wrote: 2) "Infinidad de herramientas de migración 'automágicas'" No estoy de acuerdo pq algunas de esas herramientas permitían una programación híbrida text GUI/ graphica GUI y eso facilitaba muchisimo la migracion de los programas. Y por no decir que lastima que entonces no hubiera existido el hbQTWidgets de Pritpal Bedi que se "come" todo el codigo Clipper y genera una aplicacion "Windows's style like".
Pero en esa época hubiese sido complicado para hbQTWidgets, Harbour no estaba tan maduro como hubiese sido necesario, y lo mismo que QT, que tenía además un licenciamiento bastante estricto y poco viable para el modelo Clipper/Harbour.
No recuerdo ninguna herramienta que se 'comiese' el código tal y como estaba, todas requerían bastantes adapataciones a la idiosincracia propia de Windows, y a un contexto orientado a eventos. La programación híbrida puede haber facilitado la migración, pero no nos eximía de tener que hacerla, y de tener que aprender tarde o temprano los conceptos que le son propios al entorno Windows, y por supuesto, hacer nuevas experiencias y conocimiento del nuevo medio. Y como resultado nos dejaba un producto válido como resultado de una migración, pero comparado con una aplicación hecha nativamente para ese entorno seguramente dejaba bastantes cosas muy mejorables.
Como experiencia personal, cuando enfrentamos el dilema de la migración, elegimos FW, y no nos fue tan mal . Tuvimos que repensar todo en los términos del nuevo ambiente, pero significó un avance para nuestras aplicaciones en terminos cualitativos, y lo que parecieron en un principio costes se transformaron en inversión.
Al margen de todo esto, la idea no era discutir sobre migraciones de MSDOS a Windows, sino la similaridad de la situación respecto de los datos, RDD y SQL. La idea del debate es que a veces los puntos de vista no consideran o valoran correctamente todas las posibilidades, y la idea del RDDSQL requiere un esfuerzo que me parece que no compensa en comparación con las adaptaciones.
Un saludo
Saludos
Carlos Mora
http://harbouradvisor.blogspot.com/
StackOverflow http://stackoverflow.com/users/549761/carlos-mora
“If you think education is expensive, try ignorance"
Carlos Mora
http://harbouradvisor.blogspot.com/
StackOverflow http://stackoverflow.com/users/549761/carlos-mora
“If you think education is expensive, try ignorance"
- Uwe.Diemer
- Posts: 81
- Joined: Mon Aug 09, 2010 11:00 am
Re: TDbf PRO disponible...
Where can i download it
Tx
Tx