Ejecutable por cada cliente o uno solo compartido [Archivo]

MartinS

01-08-2012, 01:16:24

Hola gente, recurro a ustedes que deben tener mucha mas experiencia en sistemas de bases de datos cliente/servidor que yo. Necesito que me orienten sobre la ejecucion y ubicacion del archivo ejecutable de mi aplicacion delphi XE.
El hecho es que el ejecutable pesa alrededor de 6 mb y actualmente cada nodo o cliente que opera en el sistema tiene una copia de este
Ahora la pregunta:

¿Esta bien que ponga un ejecutable (copia) por cada pc que ingrese a operar el sistema o bien debo hacer el enlace para que lo ejecute desde la Pc donde se encuentra la base de datos?. ¿es indistinto o va en detrimento de la red?. ¿hago un acceso directo al ejecutable o debo generar una unidad de red?

Para acceder a la base de datos existe un archivo .ini que utiliza cada pc con la ubicación de la base de datos y sus respectivos parámetros (Ubicacion, claves, directorios y demas).-

Esta consulta viene porque si hay que modificar algo obviamente debo actualizar los ejecutables de todos lo clientes en vez de actualizar solo uno y si definitivamente pongo uno solo para todos los clientes no se si se vera afectado el rendimiento general.

Saludos.-

Pd: El sistema operativo donde se aloja la base de datos (Firebird 2.5) es win 7 y los clientes Xp Sp2

roman

01-08-2012, 01:26:52

En mi experiencia, el ubicar el ejecutable en una locación central hace muy lenta la operación. Yo pensaría más por el lado de agregar al software un módulo de actualización automática que detecte cuando hay nuevas versiones, las descargue y las instale. Se ha habaldo de esto anteriormente en los foros.

En su defecto, mientras implementas la actualización, pones una dirección web de dónde descargar las actualizaciones y avisas a todos por mail/teléfono cuando haya una. Yo hago algo similar en un sistema y lo que se descarga es un instalador hecho con InnoSetup para que el usuario no tenga problemas en cómo instalar.

// Saludos

MartinS

01-08-2012, 01:40:54

Gracias román por responder. Igualmente el sistema esta en un red local y mas de ahí no va a pasar el tema es que hay 12 PC's que usan la aplicación por lo tanto 12 copias del ejecutable. Creo que mucho no se va a actualizar, tal vez ahora porque lo implemente la semana pasada y algunas correcciones surgieron. Si sugeris que siga así, así va a ser. Todo sea porque no se me venga abajo el rendimiento.

Gracias y saludos

newtron

01-08-2012, 10:00:07

Hola.

Ciertamente el tirar del ejecutable en el servidor se nota al ejecutar el programa pero una vez cargado en memoria no debe de haber muchas diferencias entre usarlo en modo local o desde el servidor y para mi es bastante más cómodo mantener un ejecutable del servidor que no andar actualizando cada uno de los clientes.

Un ejecutable de 6 megas lo debe de leer facilmente desde la red pero no te costará mucho probar las dos opciones y escoger la que más te convenga.

Saludos

Casimiro Notevi

01-08-2012, 11:10:27

Es que todo esto realmente es mucho más amplio de lo que aparenta. En principio, un servidor de bases de datos debe ser sólo eso, un servidor de bases de datos, los demás equipos no deben tener acceso a nada del servidor, sólo hacer una petición por un puerto al mismo y esperar a que te conteste por el mismo puerto. Todo lo demás es sobrecargarlo con cosas que no son necesarias.
En todo caso para esa tarea se debería usar un servidor de aplicaciones, que para eso están.
Además que con más usuarios conectados... más sobrecarga y más lento se va a convertir ese servidor, y si además añadimos directorios compartidos, servidor de impresión, etc. entonces el servidor se va a arrastrar de lento.
Entiendo que una pequeña oficina con 4 ó 5 equipos puede aprovechar un servidor para ese tema (aunque los precios hoy en día permite poner un servidor dedicado bastante económico), pero si ya son más de 10 equipos, la cosa empieza a cambiar, para empezar, que yo sepa, un windows "normal" no admite más de 10 conexiones de usuarios, y aquí se está hablando de 12, así que a pagar más licencias o poner una versión del windows que permita más.
Y si hablamos de memoria ram, 12 usuarios conectados también se lleva una buena cantidad, porque estamos hablando de "sesiones abiertas" en el servidor, no de simples conexiones para hacer/recibir peticiones por un puerto.
En fin, que son muchos detalles los que hay que tener en cuenta, y para ello hace falta conocer bien el caso, estudiarlo y llegar a una conclusión.
Todo lo que se ha comentado aquí es algo muy "genérico", ya que no conocemos los detalles concretos de esta oficina/empresa.

MartinS

01-08-2012, 13:49:46

Hola: En principio estaba implementado para algunas PC's y se fueron sumando de a poco. También debo reconocer que estoy recién empezando con esto de los sistemas administrativos cliente/servidor, de tal manera que en ningún momento me puse a pensar en un servidor dedicado ni nada por el estilo. Esta organización para la cual trabajo tiene varias secciones y a medida que se iba realizando las pruebas iba creciendo el numero de usuarios que querían participar lo que conllevo a ir "emparchando" el programa ya que había mas cosas que no estaban analizadas desde un principio (y ahí empezaron los problemas).
En definitiva hoy esta funcionando de acuerdo a lo esperado y lo único que hay como "servidor" es una pc nueva con bastante capacidad para lo que se necesita, pero nada raro (2 gb de ram, un disco de 500 gb y win 7 ultimate) donde se aloja la base de datos firebird de 2.9 gb. Lo graciosos es que también esa trabaja como cliente. (Somos una organización mediana, pero sin recursos... Argentina :o ).-
Como verán, eso de emparchar el programa es lo que me lleva a realizar las correcciones que hablaba en un principio y debo andar con un pen con el ejecutable actualizando a cada cliente. Igual estoy conforme con el desempeño del programa porque hace precisamente una semana había un par de cabos sueltos y a partir de ayer comenzaron a cerrar el circuito.- (La famosa luz al fondo del tunel).
Ahora veré como se sigue desempeñando el sistema y en el caso que explote volveré :D

Gracias a todos.

PD. (asi por lo bajo... ni se imaginan como son las conexiones, cables, switch y demas (hasta hub`s tengo y ni se de que epoca son ) asi que mucho mas no puedo pedir :D:D )

Saludos.-

cloayza

01-08-2012, 16:20:17

Sobre el tema hay varias alternativas, pero les contaré mi experiencia.

Tenemos desarrollado un software de simulación para plantaciones forestales que usan diariamente las principales empresas forestales de mi país. En las versiones anteriores (monousuario), cada persona que requeria usar el software se le enviaba un instalador y el software tenía un módulo de actualización en línea, que te indicaba que existia una nueva versión y le sugería actualizar.

El problema era que ningún usuario realizaba la actualización, motivo por el cuál muchas versiones estaban distribuidas en las compañías.

Se tomo la desición de cambiar a una arquitectura multu-usuario, todo centralizado en un servidor en cada compañía. Los usuarios acceden al software a través de un recurso compartido así evitamos tener el problema de muchas versiones dando vueltas.

Lo de la carga del software a traves de la red, es un problema menor (12MB app). Y todo funcionando Ok.

Cantidad de usuarios por compañía promedio al mes de julio (23), funcionando a full.

(La famosa luz al fondo del tunel).

Alejate de la luz...:D:D

roman

01-08-2012, 16:56:49

Bueno, yo creo que lo de la desincronización de las versiones se arregla metiendo el módulo de actualización automática en el que no se le de opción al usuario. Es un añadido en el que se tiene que trabajar una vez y ya luego te olvidas y te evitas la sobrecrga del servidor.

Es hasta verdad hasta cierto punto lo que comenta Newtron, pero muchas conexiones a una pequeña máquina (y la descrita es algo pequeña) sí pueden ser una carga fuerte.

// Saludos

rretamar

01-08-2012, 19:17:37

Me llamó la atención que tratándose de "una empresa sin recursos" (sic) tengan instalado el "Windows 7 Ultimate" je je.

roman

01-08-2012, 19:24:01

Es que antes de instalarlo eran una empresa con recursos :D

// Saludos

MartinS

02-08-2012, 01:01:25

Es que antes de instalarlo eran una empresa con recursos :D

// Saludos

Eso.... cof cof cof!!

newtron

06-08-2012, 12:47:01

En todo caso para esa tarea se debería usar un servidor de aplicaciones, que para eso están.

¿Te importaría contarme cómo va el tema ese del servidor de aplicaciones?. Nunca he hecho una instalación con dos servidores, uno para datos y otro para aplicaciones.

Gracias y un saludo

Casimiro Notevi

06-08-2012, 13:32:17

Normalmente se habla de un servidor de aplicaciones en entornos web y se usa para centralizar y tener más control sobre los distintos servicios/dispositivos/fuentes con lo que se trabaja y no tener desperdigados y repetidos distintos sistemas/controles/aplicaciones por la red.
Aunque te recomiendo que leas la entrada en wikipedia (http://es.wikipedia.org/wiki/Servidor_de_aplicaciones) para realmente saber con más seguridad lo que es y de qué trata :)
En mi experiencia hemos usado algunas veces un servidor de aplicaciones para hacer algo similar a lo propuesto antes, los usuarios conectan a un servidor (de aplicaciones) donde está el software que usan habitualmente, por lo que ellos (los usuarios) no tienen esos programas en sus equipos.
Y es el servidor de aplicaciones el que conecta al servidor de BD.
Imagina que los usuarios conectan todos mediante un programa de control remoto al servidor de aplicaciones, allí se identifican y ya pueden ejecutar los programas que están en ese servidor.
Entre otros motivos también es para tener un lugar "controlable" y "centralizado" para todos los usuarios, ya sean 'internos o externos'.
Diría que es como la programación por capas, pero llevado al aspecto físico, separar la BD de la lógica de negocio, cada uno en un servidor distinto.
Puede ser algo similar al cliente/servidor de toda la vida (de antes), terminales 'tontos' conectados a un servidor unix (donde estaba el programa) que conectaba a su web al servidor (miniordenador* o mainframe) donde estaban los datos.

* miniordenador, antes era un gran ordenador, que se llamaba 'mini' porque era más pequeño que el mainframe :)
Las minicomputadoras son una clase de computadoras multiusuario, que se encuentran en el rango intermedio del espectro computacional; es decir entre los grandes sistemas multiusuario (mainframes (http://es.wikipedia.org/wiki/Mainframe)), y los más pequeños sistemas monousuarios (microcomputadoras, computadoras personales (http://es.wikipedia.org/wiki/Computadora_personal), o PC (http://es.wikipedia.org/wiki/Computadora_personal), etc.).

newtron

06-08-2012, 14:45:48

Ok. Hasta ahí llego pero me surge una cuestión. Si tienes la base de datos en un servidor y el programa en otro tendrás que compartir la carpeta donde se aloje la base de datos para que el servidor donde está la aplicación pueda acceder a ella, ¿no?.

Casimiro Notevi

06-08-2012, 15:07:48

No, para nada, ningún sistema de bases de datos (firebird, postgresql, mysql, etc.) necesitan compartir nada en el servidor.
Las peticiones se hacen por un puerto, y se recogen los datos por ese mismo puerto. No hay más.
Los clientes/usuarios no tienen que saber siquiera dónde está la BD, ni siquiera necesitan saber en qué ordenador, normalmente se usa un "alias" y en ese alias se guarda la ruta a la BD.
Los servidores (linux, en mi caso) tienen instalado firebird y no tiene nada compartido, absolutamente nada. Es el servicio/demonio firebird el que "escucha" por el puerto 3050 esperando peticiones y responde por el mismo puerto.

Edito: y el sistema de bases de datos que tú usas también hace eso, seguro.

roman

06-08-2012, 16:02:39

Pero yo no entiendo como funciona esto de un servidor de aplicaciones en entornos web. ¿Cómo se ejecuta una aplicación delphi desde un entorno web?

// Saludos

Casimiro Notevi

06-08-2012, 16:16:01

Supongo que en casos como delphi se ejecutarán mediante aplicaciones cgi.
Aunque el servidor de aplicaciones, "formalmente", se le llama a un servidor web. No conozco bien la denominación, pero supongo que en un modelo MVC (modelo, vista, controlador), el servidor de aplicaciones será el 'controlador', y el servidor web, propiamente dicho, será el 'vista'.

De todas formas no me hagan mucho caso, no estoy informado sobre estos asuntos, y lo que yo llamo un servidor de aplicaciones es lo que he comentado antes, un equipo a donde se conectan los demás usuarios, y que hace de servidor de los programas que usan en la red. En lugar de tener el programa en cada uno de los equipos clientes.

roman

06-08-2012, 16:24:54

Por lo que alcanzo a ver en el artículo, creo que el término se usa más en relación a Java, y claro, ahí tiene más sentido hablar de acceso por web. En el caso que inició este hilo me parece que hablamos más bien de una red local de windows con una aplicación instalada en una pc central a la que se accede mediante una carpeta compartida.

// Saludos

MartinS

06-08-2012, 16:39:44

... En el caso que inició este hilo me parece que hablamos más bien de una red local de windows con una aplicación instalada en una pc central a la que se accede mediante una carpeta compartida.

// Saludos

Si Román, es así, aunque también como dice Casimiro solo comparto la carpeta en la que se encuentra el ejecutable en tanto en la carpeta donde se encuentra la base de datos lo hace a través del 3050 (no se comparte por lo menos "visualmente").-

Saludos

Casimiro Notevi

06-08-2012, 17:03:05

newtron

06-08-2012, 19:12:49

Ok.

Me ha costado (estoy algo espeso) pero creo que he pillado el concepto, aunque instales el programa en otro servidor la ip para conectarse a la base de datos tiene que ser la del equipo que alberga la misma, ¿correcto?.

Saludos

Casimiro Notevi

06-08-2012, 19:22:34

Claro, el programa conectará (hará peticiones y recogerá las respuestas) a la BD mediante la IP del servidor donde está la BD.

El cliente de la BD hace la petición al servidor que está en esa IP, por el puerto determinado, y recibirá la respuesta (si la hay) también por ese puerto. Pero no es necesario tener ningún otro tipo de acceso a ese servidor.
Porque realmente no es el usuario/cliente el que hace la consulta/petición, sino que le hace la consulta/petición al servidor, y es él quien se encarga de recoger/entregar los datos a la BD y contestar al cliente.

Hay un simil muy claro para entenderlo, el típico ejemplo del restaurante:
Los usuarios son los clientes que hacen pedidos al servidor/camarero y es el servidor/camarero/servicio/demonio el que hace el pedido a la cocina/BD. Allí preparan la respuesta que suele ser un plato preparado con las condiciones del cliente. Una vez preparada la respuesta/plato entonces se la entrega al camarero/servidor para que le responda/entregue al cliente/usuario.

Típico cliente/servidor. El cliente no sabe dónde está la cocina, ni cómo preparan los platos, ni siquiera tiene acceso a la cocina (prohibido el paso), pero gracias al servidor/camarero podemos obtener la respuesta/plato que hemos pedido.

Chris

06-08-2012, 22:06:31

Pero yo no entiendo como funciona esto de un servidor de aplicaciones en entornos web. ¿Cómo se ejecuta una aplicación delphi desde un entorno web?

// Saludos

Esto era algo que tampoco yo entendía. De por si la denominación es confusa. Pero un servidor de aplicaciones no es más que un servidor de datos que implementa la lógica de negocios. Puede estar basado en varias arquitecturas, pero los nuevos están hechos exclusivamente sobre HTTP (No es lo mismo que Web).

Para darnos una idea, imaginemos el siguiente escenario:
Una aplicación necesita registrar un nuevo contacto. Luego del registro, necesita aumentar el contador de contactos del cliente padre del nuevo contacto.

Implementando lo anterior en Delphi y usando Firebird lo harías así:
begin
// este codigo implementa la conexión a la DB
// y al mismo tiempo, implementa la lógica de negocios.

// 1. INICIAR CONECCION A LA DB
// 2. INICIAR UNA NUEVA TRANSACCIÓN

// Luego...
// Insertar el nuevo contacto
with ContactosQuery do
begin
SQL.Text :=
'insert into contactos (cliente, nombre, telefono) ' +
'values (:client, :name, :telephone)';
Params['client'] := cliente_seleccionado_en_dbgrid;
Params['name'] := NombreEdit.Text;
Params['telephoe'] := TelefonoEdit.Text;

ExecSQL;
end;

// Increamentar el contador de contactos
contador := ClientesDataset.FieldByName('contactos').Value;
contador := contador + 1;
ClientesDataset.Edit;
ClientesDataset.FieldByName('contactos').Value := Contador;
ClientesDataset.Post;

// Transaction.Commit ...
end;

El código anterior implementa la lógica de negocios y además posee código específico y dependiente de un Motor de Base de Datos.

Pero con un servidor de aplicaciones el código Delphi sería algo así:
begin
RequestData := '?cliente=%s&nombre=%s&telefono=%s';
RequestData := Format(RequestData,
[HTTPEncode(cliente_seleccionado_en_dbgrid),
HTTPEncode(NombreEdit.Text),
HTTPEncode(TelefonoEdit.Text)]);

idHTTP.Get('http://servidor_aplicacion/contactos/agregar' + RequestData);
end;

Con el anterior código sólo realizamos una petición HTTP al servidor de aplicaciones. Éste tomará los datos pasados por nuestra aplicación Delphi y los insertará en un nuevo contacto y también aumentará el contador de contactos. Además es el servidor de aplicaciones el que se encargará de gestionar la conexión a la DB.

La arquitectura anterior es un moderno y verdadero servidor de aplicaciones. Existen otro tipo de Servidor de aplicaciones, los de Java. Pero esos son un ActiveX en términos prácticos.

Casimiro Notevi

06-08-2012, 22:16:20

roman

06-08-2012, 22:18:15

Y del lado del servidor, ¿qué hay? En este esquema, ¿cómo se realiza un transacción?

// Saludos

Chris

06-08-2012, 22:28:47

Ahora si que me he quedado "a cuadros": o no me he enterado... o no le veo la utilidad.
Más que nada porque así visto parece una "encapsulación" de las llamadas a la BD. Y teniendo un stored procedure en la BD sólo hay que pasarle los datos y la misma se encarga de dar de alta al contacto y mediante un trigger se actualizaría el contador. Todo sencillo, rápido, limpio y sin necesidad de todo eso.

Realmente tiene sus ventajas hacerlo así. Este fue sólo un ejemplo sencillo. Pero que tal, que por ejemplo: Luego de registrar un contacto también tengas que enviarle un correo-e con archivos PDF generados dinámicamente?

Aparte de lo anterior, usar HTTP y no un motor DB en específico te da libertad y agilidad en el desarrollo. Por ejemplo, si cierto día deseas cambiar desde Firebird a PostgreSQL por ejemplo. O si te toca escribir un cliente para Android. Dónde consigues bibliotecas para establecer conexiones con Firebird usando Android? Aparte de eso, tendrías que volver a implementar para Android el envío del correo-e y la generación del PDF. Y si luego decides hacer una versión para iOS (iPad)?

Chris

06-08-2012, 22:32:47

Y del lado del servidor, ¿qué hay? En este esquema, ¿cómo se realiza un transacción?

Hay código script (Python, PHP, etc). Estos scripts implementan lo que se llama controladores. Son los controladores los que implementarán la lógica de negocios. Los controladores implementan las transacciones, envío de correos-e, generación de PDFs, y claro, el registro del nuevo contacto.

El código de la implementación de las transacciones ya depende del motor de DB o si usas o no un framework tipo Django o Symfony.

roman

06-08-2012, 22:35:01

Chris

06-08-2012, 22:48:10

No, a mi se me hace que hay algo que no nos estás contando ;)

// Saludos

:D

Que he soñado con poder hacer un TDataset para REST (http://es.wikipedia.org/wiki/Representational_State_Transfer). Pero mis limitados conocimientos no me lo han permitido :o

Casimiro Notevi

07-08-2012, 01:25:21

Chris

07-08-2012, 01:31:57

Tengo la sensación de que la programación web está todavía en pañales, debe de llegar una 'revolución' que lo cambie todo, actualmente parecen parches, apaños, remiendos, cada uno hace las 'mezclas' como mejor sabe o le parece, hay una infinidad tremenda de 'cosas' distintas que se solapan unas a otras, etc. Me parece como si todo fuese una gran chapuza, a la espera de algo definitivo.
No sé, es la sensación que me da.

No creo que cambie. Estas mezclas son el resultado de ser abiertos. Incluso creo que un iZombie se referiría con tus mismas palabras a Linux. Y es por lo mismo, porque Linux es abierto y no es un sistema controlado por sólo un hombre o grupo.

roman

07-08-2012, 02:40:34

Tengo la sensación de que la programación web está todavía en pañales, debe de llegar una 'revolución' que lo cambie todo, actualmente parecen parches, apaños, remiendos, cada uno hace las 'mezclas' como mejor sabe o le parece, hay una infinidad tremenda de 'cosas' distintas que se solapan unas a otras, etc. Me parece como si todo fuese una gran chapuza, a la espera de algo definitivo.
No sé, es la sensación que me da.

¡Ehh! Lo que tu quieres es encontrar el equivalente de delphi en la web :p

// Saludos

Casimiro Notevi

07-08-2012, 09:31:52

¡Ehh! Lo que tu quieres es encontrar el equivalente de delphi en la web :p
// Saludos

Algo así, sí :)
Debería de existir (o habrá que inventarlo) entornos de programación para la web, ya sea en php, python, etc. pero que fuesen herramientas/entornos/IDEs únicas y completas, al igual que ahora se usa IDEs para el escritorio.
Aunque quizás la compleja y variada que es la web en sí misma, lo haga imposible, de momento.

Puede que todo lo que ocurra es que simplemente me estoy haciendo mayor :p

roman

07-08-2012, 16:28:01

Pues ahi está el Delphi for PHP o cómo se llame ahora. Pero pienso que más que pensar que es una dolencia de la programación web, es, por el contrario, bueno que haya mucha diversidad de herramientas, entornos, tecnologías. Hacer un ambiente que abarque todo significaría cerrarse sólo a un conjunto limitado de herramientas.

// Saludos

CSIE

23-08-2012, 11:33:26

Pero para eso, mejor hacemos una aplicación de tres capas que virtualmente puede hacerse independiente del gestor de datos. Además, con esto del HTTP decimos adios a todos los controles dbaware. :eek:
...

Saludos a todos,

Yo creo que de lo que estáis hablando siempre es un desarrollo tres capas: Cliente, Servidor de Apps y BD.

Normalmente el en servidor de aplicaciones deben correr todos los servicios (de la tecnología que sea HTTP, SOAP, Custom): reglas de negocio, manejo de mensajería, etc... y nuestro cliente accederá a esos servicios a través de su puerto correspondiente y jamás accederá directamente a la BD.

Tal como yo lo veo, la ventaja principal es la escalabilidad y la encapsulación de tareas. La utopía es que el cliente se simplifique al máximo y el peso de las tareas recaiga en el servidor de aplicaciones. Tal como se hace con un explorador web, con esto no quiero decir que haya que utilizar aplicaciones WEB :), yo sigo siendo partidario de las aplicaciones de escritorio para entornos empresariales.

mRoman

24-09-2012, 20:50:58

Solo para agregar a hilo, comentarles que desarrolle una aplicacion para la empresa donde trabajo (Delphi6 y Firebird 1.5) y aqui se instalo en una unidad de la RED (LAN) el ejecutable (de 6 Gb.) y las carpetas que el ejecutable buscara en base a la ubicación de este, es decir usando componentes IBx, en especifico el TIBDatabase, en el cual dentro de la programacion hice esto:

procedure TmodDatos.dbFluidaLogin(Database: TIBDatabase;
LoginParams: TStrings);
begin
try
frmConexion:=TFrmConexion.Create(Self);
if frmConexion.ShowModal = mrOk then
begin
LoginParams.Values['user_name'] := frmConexion.edUsuario.Text;
LoginParams.Values['password'] := frmConexion.mskPassword.Text;
dbFluida.DatabaseName:=frmConexion.edServerName.Text+':C:\SysLiquid\BD\DataBase.FDB';
end;
finally
frmConexion.Free;
end;
end;

Desde el formulario de conexion el usuario indica el NOMBRE DE LA PC o bien LA IP DE ESTA.....solo que aqui existe el problema de que el usuario, si tiene conocimientos en informatica sabra la ubicacion de nuestra base de datos.....se puede arreglar agregando mejor la ruta en el archivo .INI de tal manera que sea transparente para el usuario, como el que hizo nuestro compañero que inicio este hilo.....

En lo particular tenemos el ejecutable en la RED y la base de datos en un SERVIDOR DE APLICACIONES. En cada máquina cliente se tiene un acceso directo al archivo EXE de la aplicacion (ej. i:\SisApp\myApp.exe) y este mostrara la pantalla de conexion la cual solo tiene 3 parametros.....usuario, passw y nombre del servidor....

La ventaja q tengo es que son pocos los usuarios que se conectan....no llegan a 10. Ademas de tener el EXE en una unidad de la red, pues es mas comodo a la hora de las actualizaciones.

El servidor de la base de datos esta en Win XP Profesional y en otro estado de la rep. mex. la base de datos esta en un Win Server 2008.

Saludos.