Biel:
Si los creadores de letodb hacen una nueva version, estas mejoras que tu creastes se perderan...?
Salud...
FiveTech Support Forums
FiveWin / Harbour / xBase community
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
Pedro Gonzalez
jblizama wrote: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.
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).
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.
Biel:
Podria ademas agregarse, si es posible, un icono en la barra de notificacion para saber cuando esta letodb en funcionamiento...
Salud...
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.
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
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
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:
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.
Saludos
Carlos Mora
http://harbouradvisor.blogspot.com/
StackOverflow http://stackoverflow.com/users/549761/carlos-mora
鈥淚f you think education is expensive, try ignorance"
Carlos Mora
http://harbouradvisor.blogspot.com/
StackOverflow http://stackoverflow.com/users/549761/carlos-mora
鈥淚f you think education is expensive, try ignorance"
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.
Pedro Gonzalez
pymsoft:
de que se trata "...xScript para acceder a los datos en via remota...", podrias, por favor contarnos..., a los que no sabemos...?
Salud...
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
Pedro Gonzalez
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
Usando la version "ADS remote" (que es exclusiva para ser usada en el internet) tambien tenemos problemas de lentitud?
George
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
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: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
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:
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.
Hola George,
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.
George wrote:
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.
Saludos
Carlos Mora
http://harbouradvisor.blogspot.com/
StackOverflow http://stackoverflow.com/users/549761/carlos-mora
鈥淚f you think education is expensive, try ignorance"
Carlos Mora
http://harbouradvisor.blogspot.com/
StackOverflow http://stackoverflow.com/users/549761/carlos-mora
鈥淚f you think education is expensive, try ignorance"