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
(
geocities.com/es/ensolva/Descargas) (
geocities.com/es/ensolva) (
geocities.com/es)