Database
 sql >> Database >  >> RDS >> Database

Errori della tabella di risoluzione dei problemi non trovati

Di recente, uno dei nostri clienti ha riscontrato problemi durante il tentativo di inserire alcuni dati Oracle® in una tabella di SQL Server. L'inserimento non è riuscito perché la tabella di destinazione nell'istanza di SQL Server non era presente nel database a cui si stava connettendo il cliente.

In definitiva, la soluzione a questo problema era la più semplice. Questo strumento di risoluzione dei problemi include questa soluzione e altre, nel tentativo di presentare un elenco di potenziali soluzioni per il problema in ordine logico. Sebbene lo strumento di risoluzione dei problemi sia basato su un driver ODBC Easysoft che utilizza SQL Server come database di destinazione, molti dei passaggi sono applicabili ad altri driver basati su unixODBC per altri database.

  1. Controlla la tua origine dati (DSN) per il tuo database di destinazione.

    Questo di solito sarà definito in /etc/odbc.ini.

    Importante Non ignorare questi passaggi solo perché il tuo DSN è una copia di un'installazione funzionante su un'altra macchina. In particolare se tale configurazione di lavoro si trova su un'altra piattaforma e/o utilizza una versione diversa del driver. Versioni diverse di un driver ODBC possono analizzare il file odbc.ini in modo diverso, ad esempio, alcuni potrebbero utilizzare l'ultima versione di un attributo DSN o DSN che trovano quando sono presenti duplicati, altri potrebbero utilizzare l'ultimo. Inoltre, un driver diverso su una piattaforma diversa potrebbe interrompere l'analisi del file odbc.ini se è presente un carattere problematico nel file, ad esempio un ritorno a capo.

    • Verifica che sia presente una sola copia dell'origine dati. Se sono presenti più versioni dell'origine dati, rinominale o rimuovi altre versioni. Cioè, vuoi questo:
      [MYDSN]
      Database=MYDB
      

      —Oppure—

      [MYDSN1]
      Database=MYDB1
      
      [MYDSN2]
      Database=MYDB2
      

      Non

      [MYDSN]
      Database=MYDB
      
      [MYDSN]
      Database=MYDB
      
    • Quando sei sicuro di avere solo una copia del DSN, controlla che il DSN abbia solo una riga che specifica il database di destinazione. Cioè, vuoi questo:
      [MYDSN]
      Database=MYDB
      Server=MYMACHINE
      .
      .
      .
      [ANOTHERDSN]
      

      Non

      [MYDSN]
      Database=MYDB
      Server=MYMACHINE
      Database=MYDB2
      .
      .
      .
      [ANOTHERDSN]
      

      —Oppure—

      [MYDSN]
      Database=MYDB
      Server=MYMACHINE
      Database=
      .
      .
      .
      [ANOTHERDSN]
      
  2. Se non specifichi esplicitamente un database, verifica con il tuo DBA che il database predefinito per il tuo utente sia quello che pensi che sia. Ad esempio, in SQL Server è possibile configurare un login per connettersi a un determinato database, quindi in:
    [MYDSN]
    Database=MYDB
    Server=MYMACHINE
    User=MYUSER.
    .
    .
    [ANOTHERDSN]
    

    MYUSER potrebbe inizialmente connettersi per dire AdventureWorks se l'accesso è stato configurato su un database particolare o il database Master se non lo è.

  3. Verifica di essere connesso al DSN che ritieni di essere. Anche se hai aggiunto il tuo DSN a una versione preesistente di, ad esempio /etc/odbc.ini, ciò non significa che il tuo gestore driver stia cercando in questo file. A seconda di come è stato creato il gestore driver o è impostato l'ambiente, potrebbe essere visualizzato in una posizione diversa. Per verificare, prova a commentare l'attributo Driver nell'origine dati. Se riesci ancora a connetterti, stai utilizzando una versione diversa del DSN. Utilizzare un programma come strace o truss per scoprire quale file odbc.ini viene utilizzato. Ad esempio:
    $ 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
    

    Se hai copiato un DSN da un altro computer, prova a ripetere questo processo su quel computer per verificare la posizione del DSN di origine.

  4. Verifica di essere connesso al DBMS che pensi di essere. Ad esempio, se non è troppo dirompente, prova a mettere in pausa/arrestare l'istanza/servizio di destinazione per il DBMS. Se riesci ancora a connetterti, ti stai connettendo a un DBMS su un'altra macchina. Forse la tua rete è stata configurata in modo tale che un'altra macchina possa sembrare avere lo stesso indirizzo IP di quella specificata nel DSN.
  5. In isql, digita "help". Nell'elenco delle tabelle restituite, quale nome del database viene visualizzato? È quello che ti aspetti? In caso contrario, cosa succede se digiti:
    use database
    

    Sostituisci database con il nome del database di destinazione. Se non è possibile modificare il database, verificare con il DBA se esiste un trigger di accesso che controlla l'accesso ai database in base all'indirizzo IP. In SQL Server Management Studio, i trigger di accesso si trovano in INSTANCE> Oggetti server> Trigger.