windows 7 prof bloquea red

[guillotmarc]

Empezado por benjaminao

Hola amigos del foro, he estado buscando y no consigo nada de información al respecto.
Aprovechando este hilo, les pregunto:
¿Como tienen sus sistemas en red? Yo desarrolle un sistema para la gestion hotelera, antes instalaba a cada computadora cliente todos los archivos de mi aplicación y colocaba el .ini la ruta de la db, todo funcionaba de maravilla pero como eran muchas computadoras clientes aproximadamente 16 un amigo me recomendó que colocara los archivos de la aplicación en una carpeta en el servidor y configurara en cada cliente como unidad de red y así cada cliente siempre tendría actualizado el sistema cada vez que hiciera un cambio o actualización del mismo y no tendría que ir maquina por maquina actualizando archivos. Ahora no se si realmente es la mejor solución, ya que de un tiempo para acá los usuarios me están reportando que el sistema se ha vuelto lento pero no siempre solo a ciertas horas del día.
Nota Aqui les dejo información a considerar:
*El servidor tiene windows server 2008 sp2, procesador intel core I5, 4GB de Ram, disco duro de 500GB en 2 particiones una de 200GB para el SO y el resto para la aplicación y la db, tarjeta de red gigabit.
*Las computadoras cliente tienen windows XP procesadores varian entre dual core, celeron, pentiun 4, 2 GB de ram y otras tiene windows 7 con procesadores intel dual core con 2 GB de ram.
*Utilizamos Firebird 2.0 SS, el tamaño de la db es de 130 MB con 145 tablas, 470 Procedures y 131 vistas.
*La carpeta que configure como unidad de red en los clientes que es en donde esta el sistema es de 76,3 MB.
*Cuando abro el sistema en cualquier pc cliente el sistema es realmente lento pero cuando lo abro directamente en el servidor funciona perfecto.
*El sistema lo hice en delphi 7 y para la conexion con la db utilizo TIBDatabase
*Ademas les comento que el sistema lo tengo instalado en 17 empresas(Hoteles) y solo en los hoteles grandes(con mas de 5 computadoras ) me esta presentando el problema.
Muchas gracias por su ayuda este foro siempre me ha aportado mucha información valiosa. Disculpen si es una tontería pero realmente me esta volviendo loco este problema.

Hola.

Yo tengo ambas configuraciones en mis clientes.

Normalmente siempre instalamos la aplicación en local, en cada equipo. Pero en algunos clientes les pusimos la aplicación en una carpeta compartida. Para varios de ellos, les funciona perfectamente bien, pero en otros aparecen al azar pequeños bloqueos de unos pocos segundos que impiden su uso fluido, y por tanto les volvimos a poner la aplicación en local en cada equipo (junto a un pequeño archivo de comandos .BAT que comprueba que en la carpeta compartida no haya una versión más actualizada, en cuyo caso la copia en local).

Nunca he descubierto (tampoco he perdido demasiado tiempo con el tema, y si aparecen problemas vuelvo a dejar la aplicación en local) cual es la razón por la que en determinadas configuraciones de red, un ejecutable no se puede compartir correctamente, y aparecen bloqueos para su lectura del mismo (al menos esa es la impresión que me ha dado).

Saludos.

[[birmain]]

¿Accedes a la Base de Datos a través de ODBC para impresión?. En ese caso el controlador ODBC para firebird se configura con una transaction por defecto en espera. Para solucionar el problema, hay que ir a la configuración de la conexión ODBC y marcar la casilla "No wait".
Si en el equipo nuevo está configurada en la conexión la transacción en espera, podría dar la sensación de que este equipo bloquea a los demás cunado imprime, si el resto la tienen configurada como "no espera"
Repito, esta solución es válida si imprimes a través de ODBC

[benjaminao]

Empezado por birmain

¿Accedes a la Base de Datos a través de ODBC para impresión?. En ese caso el controlador ODBC para firebird se configura con una transaction por defecto en espera. Para solucionar el problema, hay que ir a la configuración de la conexión ODBC y marcar la casilla "No wait".
Si en el equipo nuevo está configurada en la conexión la transacción en espera, podría dar la sensación de que este equipo bloquea a los demás cunado imprime, si el resto la tienen configurada como "no espera"
Repito, esta solución es válida si imprimes a través de ODBC

birmain muchas gracias por tomarte el tiempo de leer mis preguntas y darme tu aporte, fíjate realmente no uso ODBC en el cliente que me esta presentando el problema sin embargo, si esta instalado en el servidor y en uno de mis clientes con el mismo sistema si lo usan para sacar unos reportes especiales. Aprovechando tu conocimiento me puedes explicar en donde es que se configura?

[benjaminao]

Empezado por guillotmarc

Hola.

Yo tengo ambas configuraciones en mis clientes.

Normalmente siempre instalamos la aplicación en local, en cada equipo. Pero en algunos clientes les pusimos la aplicación en una carpeta compartida. Para varios de ellos, les funciona perfectamente bien, pero en otros aparecen al azar pequeños bloqueos de unos pocos segundos que impiden su uso fluido, y por tanto les volvimos a poner la aplicación en local en cada equipo (junto a un pequeño archivo de comandos .BAT que comprueba que en la carpeta compartida no haya una versión más actualizada, en cuyo caso la copia en local).

Nunca he descubierto (tampoco he perdido demasiado tiempo con el tema, y si aparecen problemas vuelvo a dejar la aplicación en local) cual es la razón por la que en determinadas configuraciones de red, un ejecutable no se puede compartir correctamente, y aparecen bloqueos para su lectura del mismo (al menos esa es la impresión que me ha dado).

Saludos.

Hola Guilotmarc muchísimas gracias por tu pronta respuesta, voy a tomar en cuenta la opción que comentas del .BAT, me imagino que cuando los clientes prenden la computadora el .BAT verifica la diferencia de versiones de las 2 carpetas. Si no es mucha molestia me podrías dar un ejemplo del código que utilizas para hacer el .BAT y como es el proceso realmente para actualizar los archivos de los clientes?

[guillotmarc]

Empezado por benjaminao

Hola Guilotmarc muchísimas gracias por tu pronta respuesta, voy a tomar en cuenta la opción que comentas del .BAT, me imagino que cuando los clientes prenden la computadora el .BAT verifica la diferencia de versiones de las 2 carpetas. Si no es mucha molestia me podrías dar un ejemplo del código que utilizas para hacer el .BAT y como es el proceso realmente para actualizar los archivos de los clientes?

Bueno, el BAT hace un par de cosas más, pero la parte de actualizar los archivos del programa la consigo mediante simplemente ejecutar un XCOPY con el parámetro /D, de forma que solo se copian los archivos que aún no existan, o bien que sean más modernos.

XCOPY /D /S \\SERVIDOR\APLICACION\*.* C:\Aplicacion

Saludos.

[[birmain]]

birmain muchas gracias por tomarte el tiempo de leer mis preguntas y darme tu aporte, fíjate realmente no uso ODBC en el cliente que me esta presentando el problema sin embargo, si esta instalado en el servidor y en uno de mis clientes con el mismo sistema si lo usan para sacar unos reportes especiales. Aprovechando tu conocimiento me puedes explicar en donde es que se configura?

Para configurar o crear una conexión ODBC, debe haber previamente instalado un controlador ODBC para la base de datos en cuestión. Concretamente para Firebird los controladores los suministra Phoenix, estos son Open Source y se pueden descargar desde la propia página de Firebird. Se instalan automáticamente con su programa de instalación.

Una vez instalado se va a Panel de Control, Herramientas Administrativas y Orígenes de Datos. Una vez aquí se puede crear una nueva conexión: Para ello hace falta especificar el controlador que se va a usar, el usuario, el password, path origen de los datos incluido el nombre del archivo de la base de datos, o el alias de esta. La conexión recibirá un nombre, que es el que se utilizará para acceder a los datos desde los múltiples programas de acceso a datos que soportan ODBC. Todo esto es editable y se puede modificar, y por supuesto variar todos los parámetros de la conexión.

Un windows 7, si el controlador ODBC instalado es de 32 bits, no se encontrará de la anterior forma ya que esa es exclusiva para controladores nativos de 64 bits. La única diferencia es donde encontrar el gestor ODBC. En vez de acceder por el panel de control se hará lo siguiente: se ejecutara c:\Windows\SysWOW64\odbcad32.exe

Se tiene la misma interface, y se procede de la misma forma que desde el Panel de Control