Hola Walter
Es una muy buena práctica lo que recomienda Fernando. En mi experiencia no hemos tenido problema de bloqueos. La tablas tienen un tamaño cercano a los 2Gb, lo que si requieren es que quincenalmente se pasen datos a históricos. Saludos ________________________________ De: [email protected] <[email protected]> en nombre de Fernando D. Bozzo <[email protected]> Enviado: viernes, 28 de octubre de 2016 03:48 p. m. Para: GUFA List Member Asunto: [GUFA] Velocidad Tablas Nativas Hola Walter: No es buena idea apuntar todos los archivos temporales de los usuarios al mismo directorio, porque te puede pasar que a 2 o mas usuarios se les genere el mismo nombre de archivo temporal y comiences a tener problemas de bloqueo. Incluso aunque no llegara a ocurrir un bloqueo, tampoco es bueno tener muchos archivos en un solo directorio, porque el sistema de archivos se pone cada vez mas lento, tanto para abrir una tabla como para crearla. Una solución es usar un programa lanzador, que cree un subdirectorio por usuario (ej: TEMP\<USUARIO>) basandose en lo que devuelve el SYS(0), luego crear un archivo CONFIG.FPW en el mismo y finalmente que el lanzador arranque el Sistema usando el parámetro -c para indicar el archivo CONFIG a usar (cada usuario tendrá uno) Esto lo estamos usando para un Sistema con más de 50 usuarios concurrentes y va bien. El 28 de octubre de 2016, 17:33, Walter Comito <[email protected]<mailto:[email protected]>> escribió: Jose cuando sugerís el uso del Config.fpw al proyecto, configurando el "path" a una carpeta temporal (existente) del puesto de trabajo. TMPFILES path EDITWORK path SORTWORK path PROGWORK path Yo estoy usando escritorio remoto, o sea que todos los usuarios caen al mismo lugar o mismo disco. Ese path debe estar en el mismo disco donde esta el sistema o debe ser otro? Gracias. Walter Cómito Analista de Sistemas MP 0397 C.P.C.I.P.C. › [email protected]<mailto:[email protected]> [email protected]<mailto:[email protected]> ' +54 9 351 494.4667<tel:%2B54%209%20351%20494.4667> +54 9 3513.292.707<tel:%2B54%209%203513.292.707> þ www.softram.com.ar<http://www.softram.com.ar/> Q Si no es necesario, no imprima este correo. Todos somos responsables por el cuidado del medio ambiente. NOTA DE CONFIDENCIALIDAD Este mensaje (y sus anexos) es confidencial y puede contener información de propiedad exclusiva de Walter Cómito (SRS Sistemas). Si usted ha recibido este mensaje por error, por favor comuníquelo inmediatamente a walter.comito<mailto:[email protected]>@gmail.com<http://gmail.com/> y tenga la amabilidad de eliminarlo; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona. Muchas Gracias. De: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] En nombre de Norberto Mario Alvarez Enviado el: jueves, 27 de octubre de 2016 16:18 Para: GUFA List Member Asunto: [GUFA] Velocidad Tablas Nativas Desde Ya Muchas Gracias, voy a tomar en cuenta estas recomendaciones y chequear todo lo expuesto. Por otro Lado de a poco y con paciencia voy a migrar a MySQL que tengo entendido, que es una BD muy rápida y compatible con MariaDB, de la cual me hablaron maravillas. Se que es un largo camino, pero mucho mas seguro. Desde ya muchas gracias!!! Norberto Alvarez Socio # 1882 De: [email protected]<mailto:[email protected]> [mailto:[email protected]] En nombre de Carlos Miguel FARIAS Enviado el: jueves, 27 de octubre de 2016 15:37 Para: GUFA List Member Asunto: [GUFA] Velocidad Tablas Nativas Para tablas, si no se cambian mucho (sean grandes o chicas), lo mejor es copiar local y acceder localmente. Evitas cargar la red (primer cuello de botella) y no hay necesidad de compartir, por lo que solo tienes que poner un testigo accesible en el servidor para que desde los clientes pueda consultarse periódicamente y si una de las tablas estáticas cambió, disparas un proceso de actualización a donde corresponda (podes copiar desde dentro del mismo fox). Si accedes con seek y found, tendrás un esquema más o menos como: lnAreaPrevia = SELECT(0) && guardas donde estabas SELECT tablaDondeBuscas lnOrdenPrevio = ORDER() && guardas que orden tenía la tabla donde buscaras SET ORDER TO TAG xDondeBuscas SEEK tuValorClave IF FOUND() * transferencia de datos, procesos asociados, lo que se necesite ELSE * procedimiento que no encontrado, blanqueo de campos o mensajes, lo que de ENDIF SET ORDER TO lnOrdenPrevio && dejas la tabla accedida con el orden que tenía SELECT (lnAreaPrevia) && vuelves a la tabla donde empezastes Con el código anterior se usaron 8 instrucciones para la tarea, lo puedes acelerar con: IF SEEK(tuValorClave, 'tablaDondeBuscas', 'xDondeBuscas') * transferencia de datos, procesos asociados, lo que se necesite NOTE que en este caso, hay que agregar el nombre de la tabla donde se busco cuando se referencian sus campos. ELSE * procedimiento que no encontrado, blanqueo de campos o mensajes, lo que de ENDIF Como se puede ver, se pasaron de 8 instrucciones a 1, por más que fox sea rápido, las instrucciones tienen que ser interpretadas por el runtime, 1 a 1, si además este proceso lo tienes dentro de un bucle, podrás ver que se dispara la cantidad de instrucciones que se hacen. Otra cosa a analizar es como usas los índices. Si usas select de sql, los índices tienen que estar desactivados, si no, es más lento aunque el índice activo sea el correcto. (Fox recupera los datos usando el índice activo), y por el tipo de consulta, será más rápido traer los datos en orden físico. Otra cosa a revisar son que tipos de indices utilizas, y si son claves compuestas, como las armas. Saludos: Miguel, Santa Rosa (LP) El Jueves, 27 de octubre, 2016 14:18:45, Norberto Mario Alvarez <[email protected]<mailto:[email protected]>> escribió: Gracias por las respuestas. Para Guardar uso =TABLEUPDATE(.T.) para el caso de un registro y para el caso de varios registros =TABLEUPDATE(2,.T.) Para tablas Indexadas use el SEEK y el IF FOUND() Y para tablas muy pequeñas y en búsqueda el LOCATE Comunmente los índices siempre están activados cuando guardo registros. Norberto Alvarez Socio # 1882 De: [email protected]<mailto:[email protected]> [mailto:[email protected]] En nombre de Carlos Miguel FARIAS Enviado el: jueves, 27 de octubre de 2016 11:50 Para: GUFA List Member Asunto: [GUFA] Velocidad Tablas Nativas Que comando usas para actualizar los datos? gather, replace, replace for, update where? Como accedes a los datos? seek, locate, seek(), find y found()? y luego Scatter? O usas SELECT INTO Cursor, y de allí algo para actualizar? Que tipo de índices tienes para acceder a los datos, tienes indices sobre los campos de acceso (supongo no faltan las PK) o de filtro? Si usas y Cuando usas comandos SQL, tienes los índices activados? Son elementos a tener en cuenta cuando hay cuellos de botella en el acceso a datos, además de lo que indicó José que es importantisimo. Saludos: Miguel, Santa Rosa (LP) El Jueves, 27 de octubre, 2016 11:02:27, Jose Paez <[email protected]<mailto:[email protected]>> escribió: Hola Norberto Sugiero que pruebes agregando un archivo Config.fpw al proyecto, configurando el "path" a una carpeta temporal (existente) del puesto de trabajo. TMPFILES path EDITWORK path SORTWORK path PROGWORK path Saludos José Paez ________________________________ De: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> en nombre de Norberto Mario Alvarez <[email protected]<mailto:[email protected]>> Enviado: jueves, 27 de octubre de 2016 12:02 p. m. Para: GUFA List Member Asunto: [GUFA] Velocidad Tablas Nativas Estimados Colisteros, estoy necesitando un consejo por parte de Uds. Resulta que en un Cliente, debido al crecimiento de equipos a un servidor y al mismo tiempo, aumentó la concurrencia a este, se esta notando que cada vez mas lento, se torna el Sistema. Esto me implica, quejas, etc, etc.. Como comentario adicional, les cuento que abro la base de datos en el momento que se ejecuta el sistema y que en cada formulario, no uso el Entorno de datos, sino, que en el Load de cada formulario, abro las tablas que voy a necesitar en el mismo u las cierro en el momento que salgo del formulario (unload). Cuando baja la concurrencia al sistema, mejora muchísimo la velocidad del acceso. En muchos procesos utilizo cursores, creados al ejecutar el mismo, sobre todos para generar búsquedas rápidas. Pero donde encuentro el mayor de las caídas es cuando guardo registros en tres o cuatro tablas al mismo tiempo, es impresionante la demora. Bueno estoy apelando a vuestras experiencias, consejos y sugerencias. Desde ya muchas gracias por vuestra atención. Norberto Alvarez Socio # 1882
