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]> 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] <[email protected]>* > > *[email protected] <[email protected]>* > > > > *'* *+54 9 351 494.4667 <%2B54%209%20351%20494.4667>* > > * +54 9 3513.292.707 <%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 > <[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]] *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] <[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]> 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] <[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]> > 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] <[email protected]> en nombre de Norberto Mario > Alvarez <[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* > > > > > > > > >
