Problemas con Access y poder emigrar a otras plataformas de trabajo
Dispongo de una Gestión Comercial que he realizado y últimamente estoy teniendo problemas con formularios y procesos que siempre has funcionado perfectamente y ahora me están dando errores en el funcionamiento.
Mi pregunta es que podría hacer sin perder toda la programación realizada el emigrar otras plataformas que fuesen compatibles con access.
Lo que necesito es no tener que realizar de nuevo toda la programación ya que esta es bastante grande y con un trabajo de varios años de adaptación a la Empresa.
Esta trabajando actualmente 8 equipos en red local.
Os agradecería si pudieseis aconsejarme que puedo hacer al respecto.
2 Respuestas
Al pasar a otro sistema de datos por ejemplo, PostgreSQL, indiscutiblemente se deben hacer cambios en la forma de accesar a los datos. Ahora, hay mirar si utiliza DAO o ADO. Si lo hace con ADO se requiren menos cambios. Lo que si le recomiendo cuanto antes haga respaldo del backend y no dude en migrar a un servidor de datos más robusto para el backend, personalmente utilizo PostgreSQL y tengo los datos el la nube, esto me permite conectar muchos usuarios concurrentes. Para más detalles me puede contactar a [email protected].
Una simple compactación no soluciona su problema, sería bueno saber sobre cuáles son los errores de funcionamiento. No obstante, le recomiendo trate de migrar a un gestor de base de datos más robusto, por experiencia tuve muchos dolores de cabeza utilizando Access como backend hasta el punto de perder toda una base de datos porque se bloqueó y ni com herrmaientas de terceros se pudo salvar, ahi fue cuanfo fije adiós Access como backend y desde entonces utilizo PostgreSQL, otro mundo y lo mejor puedo utilizarla desde muchas plataformas SIN cambiar nada.
Uno de los problemas que tuve cuando trabajé con el backend en Access, era que si los frontend tenían diferentes versiones de Access se bloqueaba el backend hasta llegar a corromperse. El primer paso que se debe dar es probar la migración de las tablas, si tienen un buen diseño relacional, con sus índices necesarios y restricciones no hay problema en migrar. Si quiere envíeme su backend y le hago una prueba de migración a PostgreSQL a ver como se comporta, si hay que hacer ajustes mínimos etc. No se preocupe por el diseño de sus formularios posiblemente no requieran modificación en cuanto diseño, pero si en las instrucciones que comprometan instrucciones INSERT, DELETE y UPDATE. Por mi parte he pasado y es mi trabajo, varias bases de datos Jet de Access a PostgreSQL para algunas empresas, hoy están satisfechos con la seguridad y agilidad sin problemas de bloqueo, comunes en Access y lo más importante algunas están en Linux y otras en la nube.
Te mando el backend, lo miras cuando puedas y me dices algo al respecto como me has indicado. He puesto en el asunto: Revisión del BACKENT
Observe lo fácil ya están sus tablas en PostgreSQL, hay que revisar unos indices, el log como es extenso se lo envío a su correo.
TABLAS EN POSTGRESQL
EJEMPLO CONSULTA A UNA TABLA
Ya sería revisar los índices que tiene repetido, el código de INSERT, DELETE, UPDATE y la conexión con el servidor, puede ser local o en la nube.
Cambiar a un gestor externo de datos (sea de pago o liberado) no eliminara los errores que tiene la programación actual (seria como pretender salvar una receta de cocina cambiando solo la cacerola por una de mayor tamaño en lugar de corregir el punto de sal).
Un cambio a un gestor externo de datos requiere cambios y cambios profundos si se quieren utilizar los recursos naturales del gestor externo (si se desea un buen 'matrimonio', esto es: 'lo mejor de cada cónyuge').
Verifica si los problemas se resuelven con una compactación (es un problema clásico de todos los gestores de bases de datos, la regeneración de sus índices) y de no resolverse revisar los procesos creados o el 'matrimonio' con otro gestor externo esta condenado al fracaso.
Las bases de datos dañadas con las que me he encontrado y las que otros programadores me han comentado (en intercambios de experiencias) han tenido como origen:.
- Problemas de hardware (sobre todo con las redes locales en mal estado)
.- Problemas de programación
(Muchos de los cuales no eran mas que falta de protección contra un 'mal uso involuntario')
No tengo noticias de que exista un gestor de bases de datos con la categoría de 'infalible' de existir seria el dueño del mercado ¿a quién se le ocurriría utilizar uno mediocre en lugar del 'divino'?.
Muchas gracias por tu comentario.
Por cierto, trabajar con diferentes versiones y tener problemas (mas bien crearlos) es tan asumible si a un vehículo en versión gasolina se le administra gasoil (y si la versión es 'full eléctrico' solo el intento ya seria digno de admiración).
Todos los programas tienen versiones y las incompatibilidades suelen darse entre las que se diferencian en varias versiones o un cambio de ciclo (algo que los fabricantes acostumbran a indican en su guía de aplicación)