Estoy trabajando con una pequeña empresa que utiliza una base de datos basada en Access para la gestión de órdenes de trabajo. El sistema existe desde hace años y tienen entre 6 y 7 PC que utilizan software personalizado de un ISV para acceder a la base de datos. Se accede a la base de datos a través de una conexión de unidad asignada (Z:).
Hace varios meses comenzaron a recibir este error de forma intermitente:
No se encontró el nombre de la fuente de datos y no se especificó ningún controlador predeterminado
Esto hace que el ISV tenga que conectarse a la base de datos y ejecutar una reparación para recuperar la base de datos. El error que ven es un poco más específico y sugiere que el formato del archivo está dañado. El técnico de soporte sugiere que el problema se debe a un error en una transacción en la red. Para ello hemos probado varias cosas.
- movió la base de datos a un host diferente en caso de que la PC "servidora" original tuviera problemas
- reemplazó el interruptor de red
- Comenzó a sacar a los clientes de la red uno por uno en un intento de aislar al niño problemático sin resultados consistentes.
Hasta ahora, no hubo suerte.
Mi(s) pregunta(s): ¿Podría una de las PC estar cerrando el mapeo de su unidad y corrompiendo la base de datos abierta? ¿Hay algo nuevo en Windows 7 que pueda estar interfiriendo? ¿Puede recomendar un mejor enfoque para aislar la causa?
Respuesta1
Es casi seguro que se trata de un problema de DSN de 32 bits frente a 64 bits. Para utilizar un DSN de 32 bits en un entorno de 64 bits, vaya aC:\Windows\SysWoW64\odbcad32.exe
Nuestra aplicación interna tiene una limitación muy similar. Para evitar el problema en el futuro, es posible que desee instalar la última versiónCliente nativo de SQL Servere implemente el DSN de 32 y 64 bits en cada máquina a través de la Política de grupo.
Respuesta2
Si asigna la unidad usando el comando SUBST.exe en lugar de "NET USE", a diferencia de "NET USE", la conexión siempre se reintentará cuando se pierda la unidad asignada. Tenga en cuenta que hacerlo de esta manera dificulta desasignar la unidad para personas que no conocen el comando SUBST.exe. Cuando una unidad está asignada de esta manera, no puedes simplemente desconectarla del Explosor de Windows... eso no funcionará.
Personalmente estoy de acuerdo en que es el tema de los 64 bits.
Tenga en cuenta que los paneles de control ODBC DSN de 32 y 64 bits, si bien es de esperar que funcionen de cierta manera, en algunos casos hacen lo contrario. Por ejemplo: cuando está en un sistema de 64 bits e intenta agregar un "DSN de usuario" de 64 bits, puede notar que su conexión falla, pero al usar un "DSN de sistema" funciona. Esto se debe a que el panel ODBC en realidad genera un "DSN de 32 bits" en la pestaña "Usuario" del panel de control ODBC de 64 bits, mientras que generará el DSN de 64 bits esperado en la pestaña "Sistema". Mientras seas consciente de la posibilidad de que los paneles de control no funcionen como se espera, no creo que ninguna configuración te deje perplejo.