LetoDB

[jblizama]

Biel:

Si los creadores de letodb hacen una nueva version, estas mejoras que tu creastes se perderan...?

Salud...

[pymsoft]

Bueno, probando en la red local a 1 gb. no hay problemas... es una bomba.
pero probando desde otra adsl, la cosa cambia, hay mucha latencia para mostrar los datos (hice un browse). casi la misma para una tabla de 234 registros y otra de 387.049.

La adsl donde puse el server tiene un upload (libre en el momento de las pruebas) de 512 y la otra adsl desde donde accedi, supera claramente esos 512 (son 2 mb.).

Por lo que entendí, los datos que se muestran en el browse son los unicos que viajan a traves de la red, es asi? (deberia, porque una dbf tiene 120 mb. y no creo que pase toda tan rapido por el cable)


saludos

[Biel EA6DD]

Biel:

Si los creadores de letodb hacen una nueva version, estas mejoras que tu creastes se perderan...?

Salud...

De momento no he hecho commit de las modificaciones, pero podria hacerlo. Con lo que hoy por hoy, si se perderian. Pero bueno, cuando tenga más testeado lo subiere al SVN.

[Biel EA6DD]

Hola Pedro,
vamos por partes,

Lo de las funciones en los indices, podrias solucionarlo linkando esas funciones con el server, y en server.prg hacer un REQUEST de la función.


Lo de poder abrir los ficheros en modo compartido, supongo que lo habran hecho por el tema de control de transaccionalidad, y evitar corrupciones de indices. Si a muchos les parece interesante, se puede hacer el comentario en la lista para ver si se puede implementar un parametro para poder compartir ficheros.

Y lo del trafico, en teoria solo viajan los datos usados en el programa cliente, aunque puede que haya otras funciones que tambien generan trafico, sobrte todo en browse(tipo control de registro visibles, total registros , etc).

[Alfredo Arteaga]

Pedro, haz realizado alguna comparación de tiempos con SQLRDD?, me gustaría ver eso.

Espero desocuparme esta semana de algunos compromisos y en la próxima seguir haciendo pruebas.

[jblizama]

Biel:

Podria ademas agregarse, si es posible, un icono en la barra de notificacion para saber cuando esta letodb en funcionamiento...

Salud...

[pymsoft]

Biel,

efectivamente, ayer hice algunas pruebas agregando las funciones que uso en mis indices y resuelto el problema de los indices, asi es compatible 100% con el programa principal, y solo me bastaría abrir cada dbf con su indice y estarían siempre actualizados.

A mi me parece importante que los archivos sean abiertos en modo compartido porque la idea sería usar el programa de gestion en red local sin letodb y poner algunas estaciones desde fuera de la red local usando letodb como servidor de archivos (yo hice el cambio en la apertura de los archivos en server.prg como comenté en algún post precedente)

Hice una prueba simple ayer para ver si la velocidad era similar en local y desde remoto. (siempre usando letodb) y se ve que algo estoy haciendo mal... los resultados no fueron los esperados.
En la red local, el dbeval demoró 13 segundos y poco (archivo con 387.049 registros), desde remoto... bueno, no se cuanto podría haber demorado, ya que luego de los 20 minutos me tenía que ir y apagué mi pc. Aquí la función que usé para probar.

Code: Select all  Expand view  RUN


FUNCTION LetoDbProva()

   LOCAL cServer:="", n, nIni


   cServer := "//85.34.123.173:2812/"
   cServer := ProfileString( oV:cIniStaz, "CollegamentoRemoto", "IndirizzoIPePorta",  cServer )

   SetProfile( oV:cIniStaz, "CollegamentoRemoto", "IndirizzoIPePorta",  cServer )

   REQUEST Leto
   RDDSetDefault("Leto")
   IF Leto_Connect(cServer)==-1
      MsgAlert("No se puede establecer la conexión.","Verifique!")
      RETURN (NIL)
   ENDIF

   DBUseArea(.T.,, cServer + "categ.d07", "categ2" )

   DBUseArea(.T.,, cServer + "corpo2.d07", "corpo2b" )

   msginfo( "Corpo: " + NTRIM( corpo2b->( reccount() ) ) )

   cursorWait()
   nIni := SECONDS()
 
   n := 0
   corpo2b->( dbEval(  {|| IIF( corpo2b->cor_cart = "JAB", n++, "" ) } ) )

   cursorArrow()
   msginfo( NTRIM( SECONDS() - nIni ) + " secondi per trovare " + NTRIM( n ) + " descrizioni JAB" )

   corpo2b->( dbGoTop() )
   corpo2b->( browse() )
   corpo2b->( DbCloseArea() )

   msginfo( "Categ: " + NTRIM( categ2->( reccount() ) ) )
   categ2->( browse() )
   categ2->( DbCloseArea() )

   RDDSetDefault("DBFCDX")

RETURN (NIL)

*
**


A propósito, no se podría ademas tener una gestión de usuarios y password para poder entrar al server letodb solo con usuario y pass? (tipo mysql)

Otra pregunta, se supone que el servidor abre los archivos una vez sola, cuando otra estacion de trabajo pide abrir el mismo archivo, ya està abierto, es así como me lo imagino?


Alfredo,

como escribí anteriormente, o estoy haciendo algo mal o no se que pasa, pero desde remoto, hace mucho proceso desde local, no se cual sea el asunto, entonces la comparación con sqlrdd todavía no la pude hacer, de todos modos, hacer un dbeval como en mi ejemplo, seguramente sea 90 veces mas rapido con mysql que con dbf.

Bueno, sigo haciendo pruebas...

Saludos

[Carlos Mora]

Bueno, probando en la red local a 1 gb. no hay problemas... es una bomba.
pero probando desde otra adsl, la cosa cambia, hay mucha latencia para mostrar los datos (hice un browse). casi la misma para una tabla de 234 registros y otra de 387.049.

La adsl donde puse el server tiene un upload (libre en el momento de las pruebas) de 512 y la otra adsl desde donde accedi, supera claramente esos 512 (son 2 mb.).

Por lo que entendí, los datos que se muestran en el browse son los unicos que viajan a traves de la red, es asi? (deberia, porque una dbf tiene 120 mb. y no creo que pase toda tan rapido por el cable)


saludos

Todos los sistema ISAM, incluyendo a Leto y a ADS, son lentos por internet. Todos. Por eso se usan los SQL, que hacen una 'foto' de los datos, te lo entregan y es esa copia sobre la que vas trabajando.
Si habías pensado que ibas a poder usar tu aplicación por internet como si fuera una red local, creo que te vas a desilusionar. La idea del cliente servidor es, fundamentalmente, evitar la corrupción en redes locales, y como ventaja adicional poder hacer consultas puntuales via remota, pero *nunca* hacer un browse.
El modelo que tiene el RDD descarta un registro inmediatamente al saltar a otro, no como los clientes de SQL que guardan el resultado. Es decir que al hacer un refresh de un browse, cada Skip es una retransmision del registro.
Si vas a usar tus aplicaciones via internet, creo que vas a necesitar replantearte la forma de consultar los datos.

Y ya puestos, el tema de usar los datos de forma compartida en el servidor es contrario al diseño: o se es cliente servidor o no. El objetivo fundamental es evitar la corrupción de datos evitando el acceso compartido directo, por lo que hacer que el servidor los comparta me parece que debería evitarse. Por supuesto cada uno es dueño de hacer lo que desee con sus datos, pero hago notar las desventajas de esa alternativa.
Es cierto que ADS permite el eventual acceso compartido de la BBDD, pero tambien es cierto que hay una penalización importante en la perfomance del servidor (los datos no son cacheables) y ademas que se recomienda seriamente que esa opcion no se use.

Copio una nota de la ayuda del ADS:

Code: Select all  Expand view  RUN

Advantage Compatibility Locking allows other applications to write to tables and index files. This decreases the amount of concurrency Advantage can provide and reduces performance. There is a possibility of index corruption with Advantage Compatibility Locking because tables and index files may become only partially updated if a workstation goes down that is running a non-Advantage application. It is recommended that you use Advantage Compatibility Locking only when first converting your applications to use Advantage that share files with other non-Advantage applications. Once all applications are converted to use Advantage, use Advantage Proprietary Locking to regain index integrity and concurrency control, and improve performance.


Dicho de otra manera, si el servidor tiene que hacer de cliente de los archivos es contradictorio, y más si las aplicaciones pueden usar tambien Leto.

Un saludo,

Carlos.

[pymsoft]

Carlos,


Bueno, ahora me quedan las cosas mas claras (creo). LetoDB entonces trabajando en una red local me evitaría además de la corrupción de datos (cosa importantísima), un tema de velocidad cuando accedo a mis bases de datos con mas de 5 estaciones de trabajo (cosa que ahora me sucede). Entonces me sería útil para cambiar el modo de trabajo en red local, no para acceder a los datos por internet (que era lo que tenía en mente cuando me puse a hacer pruebas con letoDB)

Me queda claro tambien el tema de usar los datos de forma compartida o no desde el servidor, solo que al inicio, cuando hay varias aplicaciones que acceden a los mismos datos me parece una cosa útil. (antes de hacer en modo que todas se conecten al servidor letoDB)

Voy a probar entonces xScript para acceder a los datos en via remota, solo que ahi me encuentro con otros problemas, como por ejemplo, usar letoDB, y el otro que me viene enseguida en mente, para abrir archivos con indices que contienen funciones hechas por mi. (lo se que es mala práctica, pero asi lo hice al inicio)

Y la otra opción, claro está, es pasar todo el sistema a una base de datos SQL... Justamente, estoy haciendo todas las consideraciones del caso.


Saludos.

[jblizama]

pymsoft:

de que se trata "...xScript para acceder a los datos en via remota...", podrias, por favor contarnos..., a los que no sabemos...?

Salud...

[pymsoft]

jblizama,


el xbScript es un producto free de xharbour que funciona como jscript o vbscript para ASP, con lo cual, te haces una pagina en ASP que te permiten visualizar tus bases de datos dbf.
Justamente, acabo de poner en el foro si alguien tiene un ejemplo, porque no hay documentación.


http://xharbour.com/index.asp?page=add_ ... show_i=999

algo hay en este foro al respecto, pero no mucho.

Saludos

[TecniSoftware]

Me está dando este error y no entiendo por que....

Se conecta ok, no me da ningun mensaje de error.

Al intentar abrir un archivo en una intranet me da:

cServer := "//172.20.145.66:2812/"
cFile := "CFG"
DBUseArea(.T.,, cServer + cFile, cAlias )

Descripción del error: Error LETO/1021 Error de tipo de datos: -003:21-1001
LLamada de DBUSEAREA(0)
DBUSEAREA
Param 1: L .T.
Param 2: U
Param 3: C "//172.20.145.66:2812/CFG"
Param 4: C "Check"
Local 1: U
Local 2: N 0

No entiendo, que puede ser? Por que "error en tipo de datos?"
Alguna idea?

Muchas gracias!

[George]

Carlos escribio

Todos los sistema ISAM, incluyendo a Leto y a ADS, son lentos por internet. Todos. Por eso se usan los SQL, que hacen una 'foto' de los datos, te lo entregan y es esa copia sobre la que vas trabajando.

Usando la version "ADS remote" (que es exclusiva para ser usada en el internet) tambien tenemos problemas de lentitud?

George

[Antonio Martinez]

Carlos,

Pero quiza en LetoDb se podria montar una funcion CreateCursor() o CreateVista() por ponerle nombre, que devolveria un fichero puente con los datos seleccionados; al ser el servidor el que lo ejecutara deberia ser rapido.
Cada registro de ese fichero puente (o vista o cursor) deberia contener un campo llamado Recno_ que seria el recno() de su maestro (o padre)

no se si mexplique

saludos

Bueno, probando en la red local a 1 gb. no hay problemas... es una bomba.
pero probando desde otra adsl, la cosa cambia, hay mucha latencia para mostrar los datos (hice un browse). casi la misma para una tabla de 234 registros y otra de 387.049.

La adsl donde puse el server tiene un upload (libre en el momento de las pruebas) de 512 y la otra adsl desde donde accedi, supera claramente esos 512 (son 2 mb.).

Por lo que entendí, los datos que se muestran en el browse son los unicos que viajan a traves de la red, es asi? (deberia, porque una dbf tiene 120 mb. y no creo que pase toda tan rapido por el cable)


saludos

Todos los sistema ISAM, incluyendo a Leto y a ADS, son lentos por internet. Todos. Por eso se usan los SQL, que hacen una 'foto' de los datos, te lo entregan y es esa copia sobre la que vas trabajando.
Si habías pensado que ibas a poder usar tu aplicación por internet como si fuera una red local, creo que te vas a desilusionar. La idea del cliente servidor es, fundamentalmente, evitar la corrupción en redes locales, y como ventaja adicional poder hacer consultas puntuales via remota, pero *nunca* hacer un browse.
El modelo que tiene el RDD descarta un registro inmediatamente al saltar a otro, no como los clientes de SQL que guardan el resultado. Es decir que al hacer un refresh de un browse, cada Skip es una retransmision del registro.
Si vas a usar tus aplicaciones via internet, creo que vas a necesitar replantearte la forma de consultar los datos.

Y ya puestos, el tema de usar los datos de forma compartida en el servidor es contrario al diseño: o se es cliente servidor o no. El objetivo fundamental es evitar la corrupción de datos evitando el acceso compartido directo, por lo que hacer que el servidor los comparta me parece que debería evitarse. Por supuesto cada uno es dueño de hacer lo que desee con sus datos, pero hago notar las desventajas de esa alternativa.
Es cierto que ADS permite el eventual acceso compartido de la BBDD, pero tambien es cierto que hay una penalización importante en la perfomance del servidor (los datos no son cacheables) y ademas que se recomienda seriamente que esa opcion no se use.

Copio una nota de la ayuda del ADS:

Code: Select all  Expand view  RUN

Advantage Compatibility Locking allows other applications to write to tables and index files. This decreases the amount of concurrency Advantage can provide and reduces performance. There is a possibility of index corruption with Advantage Compatibility Locking because tables and index files may become only partially updated if a workstation goes down that is running a non-Advantage application. It is recommended that you use Advantage Compatibility Locking only when first converting your applications to use Advantage that share files with other non-Advantage applications. Once all applications are converted to use Advantage, use Advantage Proprietary Locking to regain index integrity and concurrency control, and improve performance.


Dicho de otra manera, si el servidor tiene que hacer de cliente de los archivos es contradictorio, y más si las aplicaciones pueden usar tambien Leto.

Un saludo,

Carlos.

[Carlos Mora]

Hola George,

Usando la version "ADS remote" (que es exclusiva para ser usada en el internet) tambien tenemos problemas de lentitud?

Si. René Flores publicó hace cosa de 1 año o más un prg que accedía a tablas en su servidor via ADS remote. Ahora mismo no te puedo dar el enlace, si lo encuentro lo posteo. Creo que el nombre de 'remote' confunde un poco.
En realidad lo único que cambia es el soporte de la conexión, pero no hay nada diferente de un servidor de ADS del LAN de uno remote salvo que se usa TCP/IP en internet, usando puertos diferentes, o el de LAN donde puedes conectarte por TCP/PI, IPX y diferentes protocolos.

Un saludo,

Carlos.