Cita:
|
Empezado por taita
Me veo obligado a trabajar con Access por motivos de fuerza mayor (cabezonería del jefe). Hasta el momento existía una carpeta compartida, pero por paranoia del jefe está a punto de pasar a una etapa superior de la existencia informática...
|
Acces es un sistema de datos basado en archivos. Sin carpeta compartida, no hay Acces. Punto final. Acces no se puede en C/S 2 niveles, toca mover a 3 niveles.
Cita:
|
Empezado por taita
El problema surge al plantear la aplicación. ¿qué debo hacer? o mejor dicho, ¿qué pasos debo seguir para poder realizar esta aplicación en formato cliente/servidor?
Gracias.
|
1- Lo mismo que se hace al comprar ropa: Miras la talla, luego las camisas que te quedan. No al reves. Si necesitas salir de los archivos compartidos Acces no da la talla. Es hora de mover a un motor Sql. Si no quieren cambiar a un motor Sql, OBLIGATORIAMENTE tienen que usar carpetas compartidas o DNS....
2- Si es posible, porque no le dices al Jefe que lea el mismo blog?
http://www.solucionesvulcano.com/blo...ciendo-la.html
Tal vez asi se entere un poco de como la decision tecnologica afecta la eleccion de las herramientas.
3- Para hacer una aplicacion multi/nivel tienes:
- Usar un motor Sql (Firebird/Interbase, Sql Server, Oracle, MySql, NexusDB, etc...). Otros como Acces/FoxPro deben ser "segundas opciones". Ten en cuenta que Acces no posee las capacidades de un motor Sql como procedimientos almacenados, triggers, seguridad seria, comunicacion tipo 2-niveles. Cuando un proyecto usa un motor Sql y luego se pretende usar Acces, toca "hackear" la libreria de acceso a datos para duplicar la funcionalidad del motor Sql. O si se arranca desde Acces, se sub-utiliza los motores Sql. Ahora,si la BD no se usa para nada mas que guardar listas y no se pretenda tener un desempeño, seguridad o escalabilidad importante, pues ok.
- Una libreria/framework de comunicacion. Como Indy, RemObjects, MsGConnect,Asta. Recomiendo mucho es RemObjects. Indy solo si se tiene experiencia en networking...
- Un framework de acceso a datos. DataSnap, RemObjects, DataAbstract o el que te inventes
- Una separacion de codigo de a)Lo que accesa a los datos b)La comunicacion c)Lo que procesa la logica de negocios y d)La parte grafica.
Despues de hacer de esto 8 años, he notado que hacer a) y b) ha tomado mas del 80% de todo el esfuerzo AUN USANDO COM+ y lo que traiga la herrmianta de turno por defecto. Por eso no les duelan pagar miseros 300 US por RemObjects. O usen MSgConnect la version gratis PERO NO SE CARGEN ESE TRABAJO.
Esta parte es la mas critica y la que mas gasta tiempo, reorganizar el codigo.
Por lo pronto, un poco mas de informacion sobre la naturaleza delk proyecto, como se va a despelegar y que carga de trabajo tiene ayudaria a respuestas mas especificas...