BD Access en red se daña

[cchaparro]

Saludos.

Tenemos una base de datos de Access en un servidor, al que ingresan 4 computadores que están a cada segundo ingresando factura tras factura, son 4 cajas de punto de venta.

El caso es que la base de datos aparentemente no presenta daños, pero cuando se repara y compacta, empiezan a aparecer facturas duplicadas y otros errores en tablas relacionadas. El problema está en la parte de facturación, justo cuando se generan desde el POS. Lo extraño es que no aparecen en "tiempo real".

Se ha revisado la red haciendo ping desde cada caja durante 3 días sin que existan errores, pero persistieron después. Se retiró un computador y parece que hubo alguna mejora, pero al tiempo volvieron los mismos errores.

La base de datos ocupa unos 100Mb, tiene alrededor de unos 10.000 registros en facturas. Leimos la opción Dividir Base de Datos de Microsoft para mejorar el rendimiento, pero podría aumentar los problemas. También se está revisando el código fuente en VB6, por si esto pudiera estar siendo provocado por un recordset mal gestionado; la base de datos permanece siempre abierta.

Es casi contínuo el problema y está complicado reproducir y encontrar el problema, quería preguntarles si se les ocurre algo que pudiéramos hacer o una pista de cómo proceder.

Muchas gracias.

Edito: El programa se encuentra en otros negocios funcionando y tiene este mismo fallo pero muy ocasionalmente, y se arregla el daño con facilidad. En este caso, es digamos muy de seguido. Por si este dato puede orientar más en posibles pistas a seguir. Gracias.

[Libras]

cambia tu motor de base de datos :P

[gnzsoloyo]

Coincido con Libras.
Access no es una aplicación para un sistema concurrente. Es una muy mala idea, aunque parezca funcionar. No se diseñó para eso.

[cchaparro]

Lo se, y estoy de acuerdo con ustedes, el problema es que no se puede desarrollar el software de nuevo, y necesitamos alguna posible solución.

He pensado la posiblidad de hacer un "clon" en MySQL de las tablas, cambiando la conexión de VB6 de Access a MySQL por ODBC. Pero sería algo...... estratosférico, son muchas tablas y gran cantidad de campos.

Digamos que ya lo hecho pecho, Access no funciona bien concurrentemente, pero al menos alguna salida posible a este problema y en adelante intentar cambiar el motor de bd de la aplicación, por MySQL a ser posible.

No depende de mí definirlo, sólo puedo recomendar, si no, hace rato habría cambiado la BD.

Por cierto les pregunto, en los tiempos que se utilizaba Access como motor de BD para usuarios concurrentes en red local (entre otras cosas porque no existía quizás otro motor reconocido comercialmente, estaba DBase), ¿que se hacía en un caso así en grandes empresas que lo utilizaban?.

Gracias por sus comentarios.

[Libras]

Analizemos, tienes una base de datos en Access correcto? Access es de Microsoft,hasta ahi vamos bien verdad? usas VB6 que tambien es de microsoft entonces porque migrar a MySQL? porque mejor no ves la opcion de migrar tu base de datos a MSSQL Server? lo cual no seria una tarea estratosferica como mencionas sino que SQL server tiene la compatibilidad de migrar tu base de datos de access en pocos pasos......

[cchaparro]

Sí, podría ser una posibilidad mucho mejor, MySQL lo mencionaba por los costos para el cliente, MSSQL cobra por licencias. Además, MySQL es más rápido y liviano, hace tiempo realicé conectividad VB6 con MySQL y funciona bien, pero claro que no lo he probado en red.

Creo que esa es la mejor opción, MSSQL, tienes mucha razón y lógica, portando la BD Access quizás por completo sin problemas. Lo importante es dar una solución, la que sea más apropiada y que le brinde solución al cliente.

Si con MSSQL no funcionase, bueno, ya miraríamos por dónde más mirar, supuestamente el código fuente y revisar de nuevo la red.

Gracias por la recomendación.

[Libras]

Aqui te dejo un link para que realices una auditoria de tus tablas para que veas donde se afectan los duplicados :)

http://forums.devarticles.com/micros...ase-22382.html

Y migrar una base de datos de access a mysql tampoco seria mucho trabajo acabo de migrar una base de datos de sql server a mysql con creo 30-50 registros y no fue mucho problema ;)

[cchaparro]

Lol, no había pensado en ello, MSSQL a MySQL, interesante, pensaba que Microsoft no haría expotraciones a la competencia :), lo tendré muy en cuenta.

Voy a revisar el enlace.

[cchaparro]

Edito: Está muy interesante ese código del enlace, se lo pasaré al programador a ver si puede hacer seguimiento y les cuento qué tal, si es que hacen caso de mi recomendación, claro.

Muchas gracias.

[Libras]

Iniciado por cchaparro

Lol, no había pensado en ello, MSSQL a MySQL, interesante, pensaba que Microsoft no haría expotraciones a la competencia :), lo tendré muy en cuenta.

Voy a revisar el enlace.

No fue una exportacion directa, sino que fue exportar los datos a archivos separados por comas y de ahi insertarlos a MySql :S

[cchaparro]

Ya veo ya, echarle imaginación al asunto de las exportaciones e importaciones. :). Muchas gracias por el dato, si llegan a implementar algún arreglo lo posteo :). Gracias.

Edito: Por cierto, siento hablar de "ex-potraciones" en lugar de ex-portaciones, ¿hablaba de caballos? :).

[MainBoard]

en que version de access esta la BD? yo he visto 2007 pero mas 2010 y me parece y espero que no sea asi, las transacciones de negocio la esta haciendo en la aplicacion VB6, access 2007 en adelante soporta procesos almacenados (como MSSQL y cualquier otro SGBD parecido) a lo cual seria una solucion que para determinar cual factura corresponde insertar o el dato que se esta duplicando ya que con los procesos almacenados es el SGBD quien determina que peticion atiende primero y pone en cola las demas.

[haggenx]

yo he visto 2007 pero mas 2010 y me parece y espero que no sea asi

Sin ofender, pero access 2003, 2007 y 2010 es lo mismo, igual de chafa el uso de mdb. En el trabajo tenemos una base hecha con access 2003 (mdb - pero tenemos instalado office 2010), tiene formularios y se usa en una red, también es un dolor de cabeza, a cada rato falla, dice que el usuario "fulanito" tiene bloqueada la base y no se puede abrir, que no se encuentra tal módulo, etc, etc, etc. Se compacta la base y funciona por un tiempo y luego lo mismo de nuevo .

Yo también estoy de acuerdo, cambia esa base por otra, hace tiempo desarrollo un sistema para una empresa (freelancer), estubo en php y mysql (captura, reportes, etc) con un servidor interno y nunca ha dado problemas (salvo una vez que una utilería que instalaron cicló todo windows server se tuvo que reiniciar, pero es todo), nunca he recibido un aviso de que no podemos entrar, que me sale tal o cual error, todo muy bien. Así que como consejo deshazte de access. (consejo para cchaparro)

Lo malo es que en mi trabajo si puedo migrar el sistema para separar la base de los formularios y resolver muchísimos de los problemas que hay, lo tengo que hacer porque es una calamidad, pero no tengo acceso físico al servidor, solo tenemos accesos para subir archivos, no para instalar nada, ¿existe alguna base de datos que se pueda usar de forma concurrente y que no requiera un servidor para funcionar?, les agradezco cualquier pista, saludos.

[cchaparro]

Nada ofende al hablar de Access.

Todos sabemos qué significa Access, aun cuando supongo habrá casos en que funcionará bien, de no ser así no creo que Microsoft haya seguido con un desperpento tan tremendo durante tantos años. Supongo que para una agenda personal servirá bien.

Les agradezco mucho todos los comentarios.

En realidad, estamos de acuerdo en utilizar SQL, en mi caso concretamente MySQL, que es la que usualmente utilizo junto a PHP para entornos web y VB6 para entornos de escritorio, aunque las instalaciones distribuibles VB6+MySQL son bastante complicadas, y por ahora no dispongo tiempo para hacerlo, así que "temporalmente" retorné con Access para un par de aplicaciones propias, que por cierto no generan problemas.

No es decisión mia, y el software que tienen "no pueden" migrarlo a SQL, van "aguantando" los problemas ahí como vengan, ya les dí mis mejores recomendaciones pero no es decisión propia, lo cual es un poco triste para mi como técnico, pero nadie obliga a nadie a hacer lo correcto.

El objetivo entonces es ayudar en lo posible a que no se dañe mucho y "tapar" el problema e irle dando como quien dice "una pastillita" que no arregla el problema pero va calmando el "dolor".

No se preocupen por ello, yo tampoco lo voy a hacer, les agradezco de todo corazón los consejos y comentarios, ya que servirán para que no sólo mi opinión sea tenida en cuenta, sino que vean que muchos estamos de acuerdo en que Access no es lo más idóneo para entornos de trabajo concurrente.

Un saludo y muchas gracias. Dios los bendiga.

P.D.: Por cierto, a su consulta sobre base de datos concurrente sin servidor, quizás esto le pueda ayudar:
http://garabatoslinux.net/sqlite-una...-servidor.html
http://www.sqlite.org/

[haggenx]

Te agradezco lo de sqllite, la he usado para algunos pequeños proyectos, el único problema es que no es multiusuario (para escritura).