Walter, si usas RDP, te conviene crear una carpeta para cada usuario para los 
temporarios cuando el usuario se conecta tomar esa carpeta como unidad de red 
(T: por ejemplo) para todos.

 

De esta manera, tu aplicación siempre usa T: para los temporarios, pero estos 
no se mezclan entre diferentes usuarios, lo que a veces puede traer conflictos.

 

Espero te sirva esto. Yo lo hago así y funciona muy bien.

 

 

Saludos…

Claudio E. Segretin

Este mensaje se dirige exclusivamente a su destinatario y puede contener 
información CONFIDENCIAL sometida a secreto profesional o cuya divulgación este 
prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por 
error,  le rogamos que nos lo comunique inmediatamente por esta misma vía y 
proceda a su destrucción.

(This message is intended exclusively for its address and may contain 
information that is CONFIDENTIAL and protected by a professional privilege or 
whose disclosure is prohibited by law. If this message has been received in 
error, please immediately notify us via e-mail and delete it.) 

 

 

 

De: [email protected] [mailto:[email protected]] En nombre de Walter Comito
Enviado el: viernes, 28 de octubre de 2016 12:34
Para: GUFA List Member <[email protected]>
Asunto: [GUFA] Velocidad Tablas Nativas

 

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.

 

*   <mailto:[email protected]> [email protected]

          <mailto:[email protected]> [email protected]

 

'   +54 9 351 494.4667

         +54 9 3513.292.707

 

*  <http://www.softram.com.ar/> 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  <mailto:[email protected]> 
walter.comito@ <http://gmail.com/> 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]] 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

 

 

 

 

Responder a