1 votes

Quelle peut être la cause d'une connexion ODBC au rapport Nom de la source de données introuvable ?

Je travaille avec une petite entreprise qui utilise une base de données Access pour la gestion des ordres de travail. Le système existe depuis des années et ils ont 6-7 PC qui utilisent un logiciel personnalisé d'un ISV pour accéder à la base de données. L'accès à la base de données se fait par le biais d'un lecteur mappé (Z :).

Il y a plusieurs mois, ils ont commencé à obtenir cette erreur par intermittence :

Le nom de la source de données n'a pas été trouvé et aucun pilote par défaut n'a été spécifié.

L'ISV doit alors se connecter à la base de données et exécuter une réparation afin de récupérer la base de données. L'erreur qu'ils voient est un peu plus spécifique et suggère que le format du fichier est corrompu. Le technicien d'assistance suggère que le problème est dû à l'échec d'une transaction sur le réseau. À cette fin, nous avons essayé plusieurs choses

  • déplacement de la base de données vers un autre hôte au cas où le PC "serveur" d'origine aurait des problèmes
  • a remplacé le commutateur de réseau
  • a commencé à retirer les clients du réseau un par un pour tenter d'isoler le problème enfant, sans résultat cohérent

Jusqu'à présent, rien n'a été fait.

Ma (mes) question(s) - L'un des PC pourrait-il fermer son mappage de lecteur et corrompre la base de données ouverte ? - Y a-t-il quelque chose de nouveau dans Windows 7 qui pourrait faire obstacle ? - Pouvez-vous recommander une meilleure approche pour isoler la cause.

1voto

Joel E Salas Points 5542

Il s'agit très certainement d'un problème de DSN 32 bits ou 64 bits. Pour utiliser un DSN 32 bits dans un environnement 64 bits, rendez-vous à l'adresse suivante C:\Windows\SysWoW64\odbcad32.exe

Notre application interne présente une limitation très similaire. Pour éviter ce problème à l'avenir, vous pouvez installer la dernière version de l'application SQL Server Native Client et déployer les DSN 32 bits et 64 bits sur chaque machine via la stratégie de groupe.

0voto

djangofan Points 4152

Si vous mappez le lecteur à l'aide de la commande SUBST.exe au lieu de "NET USE", contrairement à "NET USE", la connexion sera toujours réessayée lorsque le lecteur mappé est perdu. Gardez à l'esprit qu'en procédant de cette manière, il est difficile de démapper le lecteur pour les personnes qui ne connaissent pas la commande SUBST.exe. Lorsqu'un lecteur est mappé de cette manière, vous ne pouvez pas simplement le déconnecter de Windows Exploder... cela ne fonctionnera pas.

Personnellement, je pense qu'il s'agit d'un problème de 64 bits.

Gardez à l'esprit que les panneaux de contrôle ODBC DSN 32 bits et 64 bits, alors que vous vous attendez à ce qu'ils fonctionnent d'une certaine manière, font parfois le contraire. Par exemple : lorsque vous êtes sur un système 64 bits et que vous essayez d'ajouter un "DSN utilisateur" 64 bits, vous pouvez remarquer que votre connexion échoue, alors qu'en utilisant un "DSN système", elle fonctionne. Cela est dû au fait que le panneau ODBC génère en fait un "DSN 32 bits" dans l'onglet "Utilisateur" du panneau de contrôle ODBC 64 bits, alors qu'il génère le DSN 64 bits attendu dans l'onglet "Système". Tant que vous êtes conscient de la possibilité que les panneaux de contrôle ne fonctionnent pas comme prévu, je ne pense pas qu'une configuration quelconque puisse vous faire échouer.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X