Fehlerbehebung bei „Tabelle nicht gefunden“-Fehlern

Kürzlich hatte einer unserer Kunden Probleme beim Versuch, einige Oracle®-Daten in eine SQL Server-Tabelle einzufügen. Die Einfügung schlug fehl, da die Zieltabelle in der SQL Server-Instanz nicht in der Datenbank vorhanden war, mit der der Kunde eine Verbindung herstellte.

Letztendlich war die Lösung für dieses Problem die einfachste. Diese Problembehandlung enthält diese Lösung und andere, um eine Liste möglicher Lösungen für das Problem in logischer Reihenfolge zu präsentieren. Obwohl die Fehlerbehebung auf einem Easysoft ODBC-Treiber basiert, der SQL Server als Zieldatenbank verwendet, sind viele der Schritte auf andere unixODBC-basierte Treiber für andere Datenbanken anwendbar.

Überprüfen Sie Ihre Datenquelle (DSN) für Ihre Zieldatenbank.
Dies wird normalerweise in /etc/odbc.ini definiert.

Wichtig Umgehen Sie diese Schritte nicht, nur weil Ihr DSN eine Kopie eines funktionierenden Setups auf einem anderen Computer ist. Insbesondere, wenn sich dieses funktionierende Setup auf einer anderen Plattform befindet und/oder eine andere Version des Treibers verwendet. Verschiedene Versionen eines ODBC-Treibers können die odbc.ini-Datei unterschiedlich parsen, einige verwenden möglicherweise die letzte Version eines DSN oder DSN-Attributs, die sie finden, wenn es Duplikate gibt, andere verwenden möglicherweise die letzte. Außerdem kann es vorkommen, dass ein anderer Treiber auf einer anderen Plattform die Analyse der Datei odbc.ini beendet, wenn die Datei ein fehlerhaftes Zeichen enthält, z. B. einen Wagenrücklauf.
- Stellen Sie sicher, dass nur eine Kopie der Datenquelle vorhanden ist. Wenn es mehrere Versionen der Datenquelle gibt, benennen Sie sie entweder um oder entfernen Sie andere Versionen. Das heißt, Sie möchten Folgendes:
```
[MYDSN]
Database=MYDB
```
  – Oder –
```
[MYDSN1]
Database=MYDB1

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

[MYDSN]
Database=MYDB
```
- Wenn Sie sicher sind, dass Sie nur eine Kopie des DSN haben, prüfen Sie, ob der DSN nur eine Zeile enthält, die die Zieldatenbank angibt. Das heißt, Sie möchten Folgendes:
```
[MYDSN]
Database=MYDB
Server=MYMACHINE
.
.
.
[ANOTHERDSN]
```
  Nicht
```
[MYDSN]
Database=MYDB
Server=MYMACHINE
Database=MYDB2
.
.
.
[ANOTHERDSN]
```
  – Oder –
```
[MYDSN]
Database=MYDB
Server=MYMACHINE
Database=
.
.
.
[ANOTHERDSN]
```
Wenn Sie keine Datenbank explizit angeben, erkundigen Sie sich bei Ihrem DBA, ob die Standarddatenbank für Ihren Benutzer diejenige ist, die Sie für richtig halten. Beispielsweise ist es in SQL Server möglich, ein Login zu konfigurieren, um eine Verbindung zu einer bestimmten Datenbank herzustellen, also in:
```
[MYDSN]
Database=MYDB
Server=MYMACHINE
User=MYUSER.
.
.
[ANOTHERDSN]
```
MYUSER stellt möglicherweise zunächst eine Verbindung her, beispielsweise zu AdventureWorks, wenn die Anmeldung für eine bestimmte Datenbank konfiguriert wurde, oder zur Master-Datenbank, wenn dies nicht der Fall ist.
Überprüfen Sie, ob Sie sich mit dem DSN verbinden, von dem Sie glauben, dass Sie es sind. Selbst wenn Sie Ihren DSN zu einer bereits vorhandenen Version von beispielsweise /etc/odbc.ini hinzugefügt haben, bedeutet dies nicht, dass Ihr Treibermanager in dieser Datei nachsieht. Je nachdem, wie der Treibermanager aufgebaut oder die Umgebung eingestellt ist, könnte er an einem anderen Ort suchen. Versuchen Sie zur Überprüfung, das Treiberattribut in der Datenquelle auszukommentieren. Wenn Sie immer noch eine Verbindung herstellen können, verwenden Sie eine andere Version des DSN. Verwenden Sie ein Programm wie strace oder truss, um herauszufinden, welche odbc.ini-Datei verwendet wird. Zum Beispiel:
```
$ 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
```
Wenn Sie einen DSN von einem anderen Computer kopiert haben, versuchen Sie, diesen Vorgang auf diesem Computer zu wiederholen, um den Speicherort des Quell-DSN zu überprüfen.
Überprüfen Sie, ob Sie sich mit dem DBMS verbinden, für das Sie sich halten. Wenn es beispielsweise nicht zu störend ist, versuchen Sie, die Zielinstanz/den Zieldienst für das DBMS anzuhalten/zu stoppen. Wenn Sie immer noch eine Verbindung herstellen können, stellen Sie eine Verbindung zu einem DBMS auf einem anderen Computer her. Möglicherweise wurde Ihr Netzwerk so konfiguriert, dass ein anderer Computer dieselbe IP-Adresse wie die im DSN angegebene zu haben scheint.
Geben Sie in isql "help" ein. Welcher Datenbankname wird in der Liste der zurückgegebenen Tabellen angezeigt? Ist es der, den Sie erwarten? Wenn nicht, was passiert, wenn Sie Folgendes eingeben:
```
use database
```
Ersetzen Sie Datenbank mit dem Namen der Zieldatenbank. Wenn Sie die Datenbank nicht ändern können, erkundigen Sie sich bei Ihrem DBA, ob es einen Anmeldeauslöser gibt, der den Zugriff auf Datenbanken nach IP-Adresse steuert. In SQL Server Management Studio befinden sich Anmeldetrigger unter INSTANCE> Serverobjekte> Trigger.