Biel:
Si los creadores de letodb hacen una nueva version, estas mejoras que tu creastes se perderan...?
Salud...
LetoDB
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
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
Pedro Gonzalez
-
Biel EA6DD
- Posts: 680
- Joined: Tue Feb 14, 2006 9:48 am
- Location: Mallorca
- Contact:
Re: Pregunta
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.jblizama wrote:Biel:
Si los creadores de letodb hacen una nueva version, estas mejoras que tu creastes se perderan...?
Salud...
-
Biel EA6DD
- Posts: 680
- Joined: Tue Feb 14, 2006 9:48 am
- Location: Mallorca
- Contact:
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).
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
- Posts: 326
- Joined: Sun Oct 09, 2005 5:22 pm
- Location: Mexico
- Contact:
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.
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
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
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
Pedro Gonzalez
-
Carlos Mora
- Posts: 988
- Joined: Thu Nov 24, 2005 3:01 pm
- Location: Madrid, España
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.pymsoft wrote: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
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
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.
Un saludo,
Carlos.
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.
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.
Pedro Gonzalez
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
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
Pedro Gonzalez
-
TecniSoftware
- Posts: 213
- Joined: Fri Oct 28, 2005 6:29 pm
- Location: Quilmes, Buenos Aires, Argentina
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!
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!
Alejandro Cebolido
Buenos Aires, Argentina
Buenos Aires, Argentina
Carlos escribio
George
Usando la version "ADS remote" (que es exclusiva para ser usada en el internet) tambien tenemos problemas de lentitud?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.
George
-
Antonio Martinez
- Posts: 72
- Joined: Tue Sep 11, 2007 3:51 pm
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
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
Carlos Mora wrote: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.pymsoft wrote: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
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:
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.Code: Select all
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.
Un saludo,
Carlos.
-
Carlos Mora
- Posts: 988
- Joined: Thu Nov 24, 2005 3:01 pm
- Location: Madrid, España
Hola George,
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.
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.George wrote: Usando la version "ADS remote" (que es exclusiva para ser usada en el internet) tambien tenemos problemas de lentitud?
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.