Cómo diagnosticar lockings de acceso a MS

Tenemos un progtwig personalizado escrito en Access que tiene lockings impares. Hemos agregado el manejo de errores que registra y envía por correo electrónico cualquier falla que ocurra dentro de nuestro propio código y que nos ha permitido corregir la mayoría de los errores que hemos generado, pero a veces los fallos ocurren fuera de nuestro código.

Un ejemplo de uno que descubrimos que surgió como nuevo en 2013 – tenemos un formulario que se bloqueará después de editar los datos en un campo determinado – la nueva entrada estaba bien, pero cualquier edición posterior al registro generaría un locking completo y cierre de MS Access. Pasamos un tiempo y, finalmente, descubrimos que algún código nuestro estaba forzando la forma de pasar al siguiente registro, este campo era el último campo en la fila, por lo que Access también estaba intentando pasar al siguiente registro. Esto había estado en el sistema desde 2007, pero comenzó a causar cierres de progtwigs en 2013.

¿Hay alguna forma de atrapar y diagnosticar lockings a nivel de progtwig dentro del acceso a MS?
El visor de eventos de Windows solo muestra lo siguiente:

Nombre de la aplicación que falla: MSACCESS.EXE, versión: 15.0.4454.1501, marca de tiempo: 0x50a35ef4 Nombre del módulo de falla: MSACCESS.EXE, versión: 15.0.4454.1501, marca de tiempo: 0x50a35ef4 Código de excepción: 0xc0000005 Desplazamiento de falla: 0x00116452 Identificación del proceso de falla: 0x1398 Fallo hora de inicio de la aplicación: 0x01ce6e665043d8be Ruta de la aplicación con errores: C: \ Archivos de progtwig (x86) \ Microsoft Office \ Office15 \ MSACCESS.EXE Ruta del módulo con errores: C: \ Archivos de progtwig (x86) \ Microsoft Office \ Office15 \ MSACCESS.EXE Id. de informe: 6cfcb0eb-da62-11e2-8966-842b2b86f028

Este es un hilo antiguo, pero apareció como uno de los mejores resultados en Google, así que pensé que iba a dar una respuesta. Qué pasos puedes seguir cuando obtienes “El acceso ha encontrado un problema y debe cerrarse”. Por lo general, en el registro de eventos, verá:

Faulting application name: MSACCESS.EXE, version: 15.0.4869.1000, time stamp: 0x57e12b41 Faulting module name: MSACCESS.EXE, version: 15.0.4869.1000, time stamp: 0x57e12b41 Exception code: 0xc0000005 

Estos pueden ser frustrantes para solucionar problemas. A continuación se muestra la lista de acciones que tomo, desde la menos invasiva hasta la más invasiva. No solo estoy inventando estas soluciones: a lo largo de los años he sido testigo de cómo cada solución resuelve el problema.

Descomstackr la base de datos

Usted indicó que es la política para descomstackr cada lanzamiento. Buena política, pero hazlo explícitamente después de CADA vez que recibas un error. La razón es porque puede que esté solucionando el problema central, pero no se da cuenta debido a un contenedor dañado.

  • Creé un acceso directo que carga la base de datos con el modificador “/ decomstackr”.
  • mantenga presionada la tecla Mayús al hacer doble clic en este acceso directo para que se omitan las ejecuciones automáticas y vaya directamente a la ventana de navegación.
  • Una vez que la base de datos esté cargada, deberá hacer clic en el botón Compactar y Reparar. Mantenga presionada la tecla shift nuevamente mientras la base de datos se recarga.
  • Ahora ve y comstack el código y guarda. Ese es el proceso que uso para descomstackr.

Prueba de memoria de la computadora

Especialmente si los lockings están restringidos a una o dos máquinas, haz esto.
Verifica el visor de eventos. ¿Hay bastantes mensajes de “Error” que describen una falla de la aplicación, y el módulo de fallas es diferente? Si es así, entonces las probabilidades son buenas de que si no es una instalación corrupta de Windows, estás viendo un problema de memoria.

Estoy seguro de que hay muchos probadores de memoria excelentes, pero los animo a que utilicen una prueba adecuada que capture los bits sueltos. MemTest86 es un viejo pero un regalo. Existe la versión actual y algunos tenedores igualmente buenos.

Comience la prueba y déjela funcionar durante las horas de trabajo. He tenido un mal poder en el edificio causando errores de memoria, así que mantenga las variables iguales.

Eliminar datos binarios del formulario

A veces, los lockings se producen en una sola forma o informe. Si se trata de datos binarios corruptos, los lockings deberían producirse en diferentes computadoras, con diferentes usuarios. Si este es el caso, entonces siga estos pasos. (Usuarios avanzados solamente)

  1. En la ventana inmediata, guarde el objeto como texto.

    Application.SaveAsText acForm, “MyForm”, CurrentProject.Path y “\ MyForm.txt”

  2. Cambiar el nombre del elemento de formulario original (por ejemplo, cambiar el nombre a MyForm_Bak)

  3. Abra el archivo exportado en el bloc de notas
  4. Eliminar la línea “Checksum =” (debe estar en la línea 3)
  5. Borrar datos binarios
    • Mire a través del archivo.
    • Habrá líneas que comienzan con “Parámetro = Comenzar” y tienen líneas de datos binarios codificados, que terminan con una línea que consta de “Fin”
    • Cuando ubique una de estas líneas, deberá (inclusivamente) eliminar todas las líneas desde el principio hasta el final.
    • Los parámetros que debe eliminar son: NameMap, PrtMip, PrtDevMode, PrtDevNames, PrtDevModeW, PrtDevNamesW
    • Todos estos bloques deben aparecer ANTES de las definiciones de control de formulario
  6. Mientras tiene el archivo abierto, desplácese por el rest del archivo y busque cualquier cosa que llame su atención, especialmente en el código del módulo de VBA en la parte inferior.
  7. Guarda el archivo
  8. En Access, en la ventana inmediata, cargue el formulario nuevamente

    Application.LoadFromText acForm, “MyForm”, CurrentProject.Path y “\ MyForm.txt”

  9. Descomstackr / Reparación compacta / Recomstackr

  10. Abra el formulario y esperemos que todo esté funcionando mejor.

Deshacerse de los campos “Objeto OLE”

Si tiene imágenes u otros datos almacenados en Access, entonces debería encontrar un mejor enfoque. Cuando se almacenan los datos OLE, se almacenan de acuerdo con el software (y la versión del software) en la computadora que lo almacena. Cuando otra computadora va a mostrar los datos del Objeto OLE en el formulario, pero no tiene instalada la versión / software exacta, con bastante frecuencia terminas con un locking.

Si está almacenando datos de imágenes, entonces un mejor enfoque es almacenar el nombre de archivo y, en su lugar, guardar las imágenes en una ubicación estándar. Las versiones más nuevas de acceso tienen los controles nativos para que este sea el camino a seguir.

Reconstruir toda la base de datos

Esto es mucho trabajo, así que lo guardaría cuando haya agotado todas las demás opciones. Solo necesita hacer esto si el problema está ocurriendo para todos los usuarios. Si no está ocurriendo para todos los usuarios, entonces no es una base de datos corrupta.

De forma similar a los pasos para eliminar datos binarios, va a reconstruir su base de datos desde cero. Para cuando llego a este paso, estoy en modo totalmente paranoico. Tal vez es un poco ritualista, pero hago todo meticulosamente, sin atajos y con gran cuidado para no “preservar” la corrupción mediante la copia directa o la importación / exportación. Como mi última posición, no creo que esto haya fallado alguna vez para resolver el problema. Afortunadamente no he tenido que hacer esto desde los días de Access 2000.

  • Crea un nuevo contenedor de base de datos de acceso.
  • No use las funciones Importar / Exportar
  • Mesas:
    • Para cada tabla en el antiguo contenedor de acceso, cree una nueva tabla en el nuevo contenedor. Desde la vista de diseño, copie / pegue las definiciones de campo.
    • Exporte los datos anteriores a XML o CSV, y luego importe desde allí.
  • Consultas:
    • Vaya a la vista SQL en la consulta original, copie y pegue el texto SQL en la consulta de la nueva base de datos.
  • Formularios / Informes:
    • Use la función Application.SaveAsText para exportar los formularios / informes
    • Eliminar datos binarios de los formularios y revisarlos
    • Utilice la función Application.LoadFromText para volver a importarlos
  • Macros
    • Recreate las macros.
    • En Access 2007 y versiones posteriores, con el nuevo sistema de macros puede simplemente abrir la macro, seleccionar todo (control + A) y pegar en un documento de bloc de notas en blanco. Copie de nuevo desde el bloc de notas y pegue en una macro en blanco dentro del nuevo contenedor de acceso
  • Módulos
    • Seleccione todo el código (Control + A) y pegue (Control + V) en el nuevo contenedor de la base de datos
  • Macros de datos
    • No tuve que hacer esto desde que salieron las macros de datos, pero usaría las funciones SaveAsText / LoadFromText para exportar las macros de datos de las tablas.

Cuando todo esté dicho y hecho, debería tener un contenedor de base de datos muy limpio.

Eliminar otras variables de la prueba

Corrupción de red

No cargue al cliente fuera de una red. Colócalo en el disco local y ejecútalo desde allí.

Desarrollos corporativos

Si se encuentra en un entorno corporativo que usa “comstackciones de computadora” y no ha tenido éxito con Descomstackción, Prueba de memoria y eliminación de datos binarios, entonces, evite hacer más pruebas hasta que el equipo de TI pueda proporcionarle al usuario una máquina de prueba que tenga solo Windows, Office y Service Packs instalados. Por lo general, prefiero hacer la instalación yo mismo, así que sé que puedo confiar en ella. Todo el software y las actualizaciones deben instalarse a mano sin utilizar instalaciones desatendidas. No instale antivirus en esta máquina.

Los departamentos de TI me lo han negado por puro FUD y falta de razonamiento: si esto es lo que te encuentras, lávate las manos del problema en el contexto “Ayúdame a ayudarte”.

Mal poder

Como se menciona en la sección de memoria, las fluctuaciones de energía pueden causar errores en la computadora. Si la base de datos se encuentra en un edificio industrial, intente poner sus manos en un acondicionador de energía o un UPS que proporcione energía limpia (fuera de la batería, no en el paso principal a través de un varistor de rust de metal)

Además, verifique el cable de la fuente de alimentación que se conecta a la barra o toma de stream. Asegúrese de que las especificaciones del medidor y voltaje sean suficientes. Digo esto porque los departamentos de TI a menudo dejan los cables de alimentación enchufados en la estación y simplemente retiran la máquina. Después de muchos años, usan fonts de alimentación más robustas, pero no han desconectado el cable. Hace una diferencia. En caso de duda, traiga un cable nuevo y más grueso.

Apéndice

Desde que originalmente publiqué esto, me encontré con algunos nuevos. Uno que me ha golpeado varias veces es el de los controladores ODBC cuando se mueve a Access 2016. Si tiene una base de datos que funciona bien en Access 2013, pero se bloquea de manera confiable en Access 2016, entonces el problema puede ser el controlador ODBC. Fuera del salto, intente averiguar si hay un controlador actualizado. Si no tiene éxito allí, confirme si se trata del controlador ODBC creando una nueva base de datos y realizando una llamada ODBC en VBS. Si obtiene el mismo choque, es el controlador. Sin un controlador actualizado, solo tendrá que mantenerlo en 2013. Lo encontré con el controlador ODBC PostGreSQL con algunas bases de datos.

Cada función individual en cada formulario en cada base de datos de Access debe tener un flujo que se ve así:

 Private Sub btnMyButton_Click() Dim MyVar as String On Error GoTo ErrorHappened 'Do some stuff here... ExitNow: Exit Sub ErrorHappened: MsgBox Err.Description Resume ExitNow End Sub 

En la sección ErrorHappened, puede hacer que escriba en su tabla que rastrea los errores. Si cambia todos sus Subs y funciones para que fluyan de esta manera, debería poder atrapar cada problema que tenga su base de datos. Quizás escriba Err.Number así como Err.Description.

Para cualquier otra persona que tropiece con este hilo en Google aquí hay otro par de causas de accidentes de acceso aleatorio:

Solo por antecedentes, tengo un formulario con un subformulario, cargando datos de tablas vinculadas en un servidor.

  • Si tiene eventos “_Enter” en los campos en el formulario principal, esto puede hacer que Access entre en un bucle sin fin, activando estos eventos repetidamente. Esto ocurrió cuando estaba en el subformulario y presioné un botón en el formulario principal. En su lugar, los reemplacé por eventos “_GotFocus” que corrigieron el problema.

  • No haga referencia al subformulario en onload ni en el formulario principal. Este fue aleatorio, el formulario se cargaría bien y, luego, la próxima vez que ingresara en el mismo formulario, con el mismo registro, ocasionaría que Access se bloquee. Así que eliminé todas las referencias al subformulario en el evento onLoad del formulario principal y ahora parece funcionar bien. Me di cuenta especialmente de que cuando mi conexión a Internet era lenta, parecía que el formulario principal se estaba cargando antes que el subformulario, por lo que cuando lo referenciaba no se había cargado y causaba todo tipo de problemas con Access, que invariablemente terminaba en un locking aleatorio. de acceso.