Se trata de una cadena de tiendas de recambios, situadas en diferentes ubicaciones y desean tener en cada tienda un programa (MDE o bien uno de Visual Basic...), solo el programa y en un ordenador de Madrid los datos y todas las sucursales chupar 'algunos' datos de dicho ordenador. Todos disponen de Adsl de 256/128 de Telefonica. No tengo ni idea de como empezar, qué sistema escoger etc. En principio cada sucursal debe tener sus clientes propios, hacer sus ventas sus facturas etc, propias de cada sucursal. Pero los repuestos les deben chupar de un mismo sitio, pues allí en el servidor habrá un persona encargada de meter datos de repuestos, actualizar precios etc. O sea una aplicación que manejaría Datos Locales+Repuestos Remotos Había pensado hacer una aplicacion tipo Web, con ASP, no sé... Es que es la primera vez que me enfrento a un tema como este. Me consta que muchos de vosotros manteneis aplicaciones de este tipo, es decir un programa local y unas bases de datos a distancia. Me hago un lío con las herramientas que hay que utilizar (¿Proyectos ADP? ¿SQL Server? ¿ASP?) Gracias por vuestra sugerencias VER HILO COMPLETO ================= Respuesta de Jose María Fueyo ----------------------------- Hola Buho/Coruxa (je, je, je). Bueno, dado que todos los usuarios tienen conexión ADSL, y que están digamos, tan distanciados entre si, creo que lo mejor es que hagas una aplicación ASP. Por un lado, el usuario ahorra en infraestructura. No necesita una linea dedicada para cada cliente. Si, tienes la opción de crearte una VPN, pero ¿sabes tu? yo no. Y el cliente lo dudo. Por otra parte, está el tema de mantenimiento. Con que actualices tus .asp en el sevidor, ya está actualizada la aplicación. Y luego el cliente. ¿Quien no sabe navegar?. Definitivamente, yo me inclino por una ASP para los clientes. Y una plicación en VB para mantenimiento de la base de datos. Espero te sirva. [A esta Respuesta de Jose María, responde el Buho]: --------------------------------------------------- Gracias Jose María. El tema es que yo había pensado en una aplicación...no se como llamarla..'hibrida', por decir algo. Hibrida en el sentido que cada surcursal tiene sus propios clientes, facturas...demás tablas...que me gustaría mantener en 'local'. El problema se suscita a la hora de realizar una venta o una simple consulta de materiales, que esos sí estarían en el Servidor. Hombre, una opción, sería, al entrar en el programa, detectar si hay nuevos productos y mediante FTP descargar la Mdb de productos. Eso más o menos lo sé hacer. Es más, lo he hecho. Tengo un programa que se actualiza automaticamente. En el servidor coloco un fichero INI plano, donde una de las lineas es la version disponible. Al abrir el programa de VB, se conecta vía Ftp, se baja el fichero de version actual. Compara con otro INI que se guarda local y si las versiones son diferentes, automaticamente se avisa al usuario que hay una actualización y se procede a bajarla. Pero...no me convence para este caso. A ver con ASP...voy a escribir segun me van saliendo las cosas...así que habrá cosas incosistentes...pero bueno... ahí va... Si lo hago en ASP todo, lo primero será requerir una autentificacion de usuario y Contraseña en la Web (Una Mdb de Contraseñas). Bien, establecida la conexion de esta forma, en esa misma tabla de usuarios y contreseñas, tendría grabado el nombre de la MDB personal de dicho usuario, por ejemplo, usuario CASTAÑO, contreseña 776767676, en ese mismo registro tiene grabado un campo con el nombre Us00001.Mdb, que sería SU base de datos personal. Esta variable sería la utilizada en el resto de ASP para saber de qué base de datos debe extraer clientes etc etc, es decir, lo que he llamado 'datos locales'. Y mediante codigo de ASP crearía la cadena de conexion a dicha MDB. Y a la hora de hacer pedidos, ventas etc, existiría una unica MDB comun para todos los usuarios, de donde extraer los precios. Mmmmm....voy a madurar esta idea. [EL HILO CONTINUA].... RESPUESTA DE QUIQUE ------------------- Yo me inclino por poner un Server W2000 en la central, al cual te conectarias a traves de una VPN por cliente, en el estarian las tablas ( podrias diferenciar los clientes/ubicacion ) y el tipico MDE en cada cliente con las personalizacion adecuada, haria mas facil las copias de seguridad y el mantenimiento. Solo es una idea, pero te permite trabajar en tiempo real, ¿ has calculado que bajar una tabla de por ejemplo 3 Mb. supone por ADSL aprox. 10Kb/s.... +/- 300 sg = 5 minutos ?. Si tiene que hacer una consulta y actualizar la base local... bueno si es un buen vendedor le intentara vender algo mas, si no lo es ... adios al cliente. Un saludo E. Feijoo [EL HILO CONTINUA] RESPUESTA DE CHEA ----------------- Si lo único que se ha de mantener en común es el catálogo de repuestos (que, es de suponer, será grande), yo lo trabajaría todo en local y, una vez al día, antes de empezar o al finalizar la jornada, con la aplicación cerrada, actualizaría los datos del catálogo. Sería simplemente un hipervínculo a una URL donde la persona encargada habría introducido las últimas modificaciones; luego, con un consulta de actualización se pondría el catálogo al día [EL HILO CONTINUA] RESPUESTA DE CHEEKY ------------------- Totalmente de acuerdo contigo Chea, una cosa es el ideal teórico y otra el funcionamiento práctico. A su vez en la central se podrían descargar copias de los datos locales para seguridad y estadísticas. Si alguien se plantea el problema de control de stock, no creo que sea así pues hace tiempo que yo siempre hago una tabla diferente de la de artículos para el stock, y claro la tabla de stock sería local, no actualizable desde la central. [EL HILO CONTINUA] SIGUE CHEA ---------- Para el mantenimiento del stock en el caso que necesariamente fuese centralizado, se podría tener en red una tabla con los movimientos del día, exclusivamente del día. El stock en cualquier momento sería el del catálogo que se recibe diariamente +/- los movimientos que se mantienen en caliente. Una BD con exlusivamente los movimiento del día no ocuparía gran cosa y se podría mover por la red con relativa facilidad; además sólo se dependería de la red en los momentos de actualizar o consultar stocks. La persona encargada en los servicios centrales se ocuparía de pasar actualizar diariamente el catálogo con esa tabla y de borrar y compactar los datos cada día. [EL HILO CONTINUA] Mezcla Access local y Mysql para el remoto. Y...este es más o menos el hilo completo. Es un problema que se puede dar perfectamente en la vida real y debemos estar preparados para implementar unsa solución adecuada [Calidad/precio/rendimiento] [EL HILO CONTINUA] A.L. ---- Vamos a ver si no digo un burrada, pero te explico: Timofonica esta vendiendo una solucion ( ADSL NET LAN ) que consiste en una VPN ( Virtual ... como su nombre indica ) que ellols te montan la VPN sobre ADSL ( incluso con accesos RTC ) donde tu no te tienes que preocupar de nada. Ellos te lo montan, se lo guisan, lo cuecen y se lo comen. Por no dejar, no te dejan ni la posiblidad de modificar la configuracion del router que te ponen. ( Lo hacen ellos en remoto ) Es bastante asequible de precio para cualquier empresa, y con ella te puedes crear cualquier accesso directo en los pc remotos de una unidad del servidor, y tratarla como un pc mas de la red. Asi podrias trner una MDB con tablas vinculadas del ordenador local y otras visnculadas de la uidad de red remota ( Creo... :( ) Otra posibilidad seria, sobre esta solucion ( NETLAN ) montar un servidor W/2000 Terminal Services en la central y las sedes trabajarian contra este servidor. Ellos se creen que estan trabajando en local, pero en realidad trabajn con una sesion del servidor TS. Espero no haberte liado mas..... Saludos [EL HILO CONTINUA] E.Feijoo -------- VPN es algo así como Virtual Private Network, en cristiano y a lo practico, un canal de comunicaciones (codificado) entre dos ordenadores utilizando como medio de conexión Internet. Este canal tiene como ventajas: esta codificado, permite mas protocolos de comunicación, con un poco de suerte comprime... No es difícil ( al menos muy difícil ) de conseguir y trasparente al uso que le des. El símil seria: una red local en que el cable es Internet, lo malo... Una ADSL es 256/128 Kb. solo se aprovechan los 128, dado que es lo que puedes 'sacar' y son Kilobit, no Kilobites así que debido al encapsulado IP y las reservas del Sistema operativo se queda en una conexión ( con suerte ) de 10 Klobites/s. Mi experiencia con el caso ( el trabajo en red en tiempo real de una sucursal con la nave ) me hizo ver que las soluciones eran: A) Un Server y trabajar con terminal Server ( la adoptada ) con un costo aceptable. B) Montar un servidor SQL, el costo se dispara y fuerza a reconvertir todo el trabajo creado, además para un solo terminal aun vale pero si deseas mas de una conexión, añádele el W2000 Server de regalo. Si los clientes utilizan como sistema operativo el W2000 o XPprofesional, no consumen licencias del servidor, si acaso utilizan el W98, 95 o incluso el W3.0 o el simple DOS si las consumen. Un Saludo E.Feijoo Para lo que deseas tendrás que poner un W2000 Server en la central, pues si no me equivoco el W2000 a pelo solo soporta una conexión, al igual que el XP. [SIGUE EL HILO] Jose María Fueyo ---------------- ¿Quieres una alternativa más? servicios de terminal + metaframe de Citryx.. Tienes un servidor en el cual se ejecutan tooodas las aplicaciones de los clientes, y estos solo reciben pantallas. Es decir, por la conexión solo viajan las pantallas, no los datos. Mi opinion: ASP para los clientes, y el encargado de administrar la base, una aplicación con VB. [SIGUE EL HILO] Mi opinión: Primero, no puedes pensar en bases de datos compartidas en tiempo real, aunque tengas una conexion dedicada entre las sucursales, recuerda que eso depende mucho de situeción climática, seguridad de la comunicación, etc entre los puntos. Segundo, piensa que la disponibilidad y lo óptimo que sea el servicio de ADSL en localmente, estás seguro que lo puedes mantener vivo por 24 horas al día como si fuera la red de tu casa?. Tercero, podrá ser 256kbps o si quieres lo ponemos a 1024kbps, tu sabes el tamaño del archivo que maneja cuando access se dedica a actualizar una base de datos? o piensalo así, hasta cuando duraría tu access trabajando cómodo mientras la base de datos sea pequeña. Bueno, considera lo siguiente, lo que se tenga que transmitir o actualizar en tiempo real, lo tienes que hacer lo mínimo posible, por ejemplo, la lista de productos, lo colocas en un archivo diferente, así access no toca ese archivo sino cuando lo vayas a accesar. Asegurate que esa o esa tablas no esten likeadas al momento de abrir la terminal, sino que se intente al momento de necesitarla, así evitaras errores en momento de uso, o sea, el vendedor solo recibirá un mensaje de conexión negativa si no se logra conectar por cualquier causa. Es necesario que configures el VPN, es sencillo, al crear el VPN, windows crea como un especie de tunel codificado. Este espera la llamada al IP address del servidor y si cumple con los resquisitos de validación de seguridad, éste le da acceso a todos los protocolos que se hayan configurado en él. Yo dudo mucho que te sirva el protocolo microsoft, pero es el mas facil de usar, te aseguro que esos 256kbps seran nada si metes el cliente microsoft, o sea, piensa en otra cosa entonces. Te sugiero mas bien que actives el cliente web del server 2000 que viene en su versión a traves del IIS, y hagas peticiones ASP para accesar la las tablas necesarias. Así desde las terminales solo tienes que intentar conectarte una sola vez y pides tus tablas por ASP y las importas en tiempo real. Otra opción es colocar estas tablas de productos localmente, y el servidor sea el encargado de actualizarlas cuando sean necesarias, eso implica, VPN, cliente microsoft y réplicas de las tablas en cada terminal. El problema sería, que pasa si no se logró la réplica de algunas de las terminales, me imagino que ya se te ocurrirá algo. Lo mejor es que haya la menor dependencia posible con la central, piensa el mejor ejemplo: los bancos, si la línea está caída, se puede realizar transacciones locales y que tengan que ver con la sucursal local. Si hay línea, la petición hacia el servidor se hace solo sí se necesita y en el momento de la transacción. Ellos nunca mantienen la línea viva las 24 horas, solo se conectan cuando se necesita. Y la data que comparten no es el 100% de su información. Ellos hacen como una especie de sincronización de los datos solo después de cerrar el banco. Espero que todo esto te pueda ayudar en algo. A esta hora estoy como un poquito cansado y no se me ocurre mas nada, pero estaré pendiente.... ELCHINO [SIGUE EL HILO] Hola Francisco: No se si te servirá, pero te cuento como lo he montado yo. Yo he montado una VPN con los siguientes recursos: Sede central: ADSL 2Mb Sedes clientes (7): ADSL 512 Kb Para garantizar una cierta seguridad, hemos creado tuneles con un firewall en cada sede, el modelo que he cogido es uno jerárquico, la sede central abre un tunel con cada sede, de tal forma que todas pueden ver a la central, pero no pueden verse entre sí (mas que nada para no empezar a abrir un montón de tuneles y ralentizar todo) A nivel de software de servidor, uso w2k server en la sede central, con un servidor de ficheros, un servidor de BBDD y un servidor de correo. Los clientes usan w98 y xp prof. Como servidor de BBDD uso SQL Server 2000 (ya que está especialmente orientado a proporcionar servicios de red). Como aplicaciones tengo un sitio web con ASP para una actividad de la empresa, otra basada en access 97 con vínculos odbc al sql y un par de desarrollos en VB6 Lo desarrollado en ASP y VB6 funciona bastante rápido, el problema lo tengo si ejecutamos access desde el servidor, pero si lo ejecutas desde el cliente, viene a costarle un par de segundos el realizar las ABM tipicas. Espero que te sirva de orientación Saludos++ Jon