Tableau de dépannage des erreurs introuvables

Récemment, l'un de nos clients rencontrait des problèmes lorsqu'il tentait d'insérer des données Oracle® dans une table SQL Server. L'insertion échouait car la table cible de l'instance SQL Server n'était pas présente dans la base de données à laquelle le client se connectait.

En fin de compte, la solution à ce problème était la plus simple. Cet outil de dépannage inclut cette solution et d'autres, dans le but de présenter une liste de correctifs potentiels pour le problème dans un ordre logique. Bien que le dépanneur soit basé sur un pilote Easysoft ODBC utilisant SQL Server comme base de données cible, de nombreuses étapes sont applicables à d'autres pilotes basés sur unixODBC pour d'autres bases de données.

Vérifiez votre source de données (DSN) pour votre base de données cible.
Cela sera généralement défini dans /etc/odbc.ini.

Important Ne contournez pas ces étapes simplement parce que votre DSN est une copie d'une configuration de travail sur une autre machine. En particulier si cette configuration de travail se trouve sur une autre plate-forme et/ou utilise une version différente du pilote. Différentes versions d'un pilote ODBC peuvent analyser le fichier odbc.ini différemment, par exemple, certains peuvent utiliser la dernière version d'un DSN ou d'un attribut DSN qu'ils trouvent lorsqu'il y a des doublons, certains peuvent utiliser le dernier. De plus, un pilote différent sur une plate-forme différente peut cesser d'analyser le fichier odbc.ini s'il y a un problème de caractère dans le fichier tel qu'un retour chariot.
- Vérifiez qu'il n'existe qu'une seule copie de la source de données. S'il existe plusieurs versions de la source de données, renommez-les ou supprimez les autres versions. C'est-à-dire que vous voulez ceci :
```
[MYDSN]
Database=MYDB
```
  —Ou—
```
[MYDSN1]
Database=MYDB1

[MYDSN2]
Database=MYDB2
```
  Non
```
[MYDSN]
Database=MYDB

[MYDSN]
Database=MYDB
```
- Lorsque vous êtes sûr de n'avoir qu'une seule copie du DSN, vérifiez que le DSN ne comporte qu'une ligne spécifiant la base de données cible. C'est-à-dire que vous voulez ceci :
```
[MYDSN]
Database=MYDB
Server=MYMACHINE
.
.
.
[ANOTHERDSN]
```
  Non
```
[MYDSN]
Database=MYDB
Server=MYMACHINE
Database=MYDB2
.
.
.
[ANOTHERDSN]
```
  —Ou—
```
[MYDSN]
Database=MYDB
Server=MYMACHINE
Database=
.
.
.
[ANOTHERDSN]
```
Si vous ne spécifiez pas explicitement une base de données, vérifiez auprès de votre administrateur de base de données que la base de données par défaut pour votre utilisateur est celle que vous pensez qu'elle est. Par exemple, dans SQL Server, il est possible de configurer une connexion pour se connecter à une base de données particulière, donc dans :
```
[MYDSN]
Database=MYDB
Server=MYMACHINE
User=MYUSER.
.
.
[ANOTHERDSN]
```
MYUSER peut initialement se connecter pour dire, AdventureWorks si la connexion a été configurée pour une base de données particulière, ou la base de données Master si ce n'est pas le cas.
Vérifiez que vous vous connectez au DSN que vous pensez être. Même si vous avez ajouté votre DSN à une version préexistante de, par exemple /etc/odbc.ini, cela ne signifie pas que votre gestionnaire de pilotes recherche dans ce fichier. Selon la façon dont le gestionnaire de pilotes est construit ou l'environnement est défini, il peut être recherché à un endroit différent. Pour vérifier, essayez de commenter l'attribut Driver dans la source de données. Si vous pouvez toujours vous connecter, vous utilisez une version différente du DSN. Utilisez un programme tel que strace ou truss pour savoir quel fichier odbc.ini est utilisé. Par exemple :
```
$ more /etc/odbc.ini
[MYDSN]
#Driver=Easysoft ODBC-SQL Server
$ /usr/local/easysoft/unixODBC/bin/isql.sh -v MYDSN
SQL>
$ strace -o -f /tmp/odbc.log /usr/local/easysoft/unixODBC/bin/isql.sh -v MYDSN
$ grep odbc.ini /tmp/odbc.log
```
Si vous avez copié un DSN depuis une autre machine, essayez de répéter ce processus sur cette machine pour vérifier l'emplacement du DSN source.
Vérifiez que vous vous connectez au SGBD que vous pensez être. Par exemple, si ce n'est pas trop perturbateur, essayez de mettre en pause/d'arrêter l'instance/le service cible pour le SGBD. Si vous pouvez toujours vous connecter, vous vous connectez à un SGBD sur une autre machine. Peut-être que votre réseau a été configuré de telle sorte qu'une autre machine peut sembler avoir la même adresse IP que celle spécifiée dans le DSN.
Dans isql, tapez "help". Dans la liste des tables renvoyées, quel nom de base de données est affiché ? Est-ce celui que vous attendez ? Sinon, que se passe-t-il si vous tapez :
```
use database
```
Remplacer base de données avec le nom de la base de données cible. Si vous ne pouvez pas changer de base de données, vérifiez auprès de votre administrateur de base de données s'il existe un déclencheur de connexion qui contrôle l'accès aux bases de données par adresse IP. Dans SQL Server Management Studio, les déclencheurs de connexion se trouvent sous INSTANCE> Objets serveur> Déclencheurs.