Database
 sql >> база данни >  >> RDS >> Database

Грешки за отстраняване на неизправности в таблицата не е намерена

Наскоро един от нашите клиенти изпитваше проблеми при опит да вмъкне някои данни на Oracle® в таблица на SQL Server. Вмъкването беше неуспешно, защото целевата таблица в екземпляра на SQL Server не присъстваше в базата данни, към която клиентът се свързваше.

В крайна сметка решението на този проблем беше най-простото. Този инструмент за отстраняване на неизправности включва това решение и други, в опит да представи списък с потенциални корекции на проблема в логически ред. Въпреки че инструментът за отстраняване на неизправности се базира на драйвер на Easysoft ODBC, използващ SQL Server като целева база данни, много от стъпките са приложими за други базирани на unixODBC драйвери за други бази данни.

  1. Проверете своя източник на данни (DSN) за вашата целева база данни.

    Това обикновено се дефинира в /etc/odbc.ini.

    Важно Не заобикаляйте тези стъпки само защото вашият DSN е копие от работеща настройка на друга машина. Особено ако тази работна настройка е на друга платформа и/или използва различна версия на драйвера. Различните версии на ODBC драйвер може да анализират файла odbc.ini по различен начин, например, някои могат да използват последната версия на DSN или DSN атрибут, който намерят, когато има дубликати, някои може да използват последната. Освен това, различен драйвер на различна платформа може да спре синтактичния анализ на файла odbc.ini, ако във файла има проблемен знак, като например връщане на карета.

    • Проверете дали има само едно копие на източника на данни. Ако има няколко версии на източника на данни, или ги преименувайте, или премахнете други версии. Искате това:
      [MYDSN]
      Database=MYDB
      

      —Или—

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

      Не

      [MYDSN]
      Database=MYDB
      
      [MYDSN]
      Database=MYDB
      
    • Когато сте сигурни, че имате само едно копие на DSN, проверете дали DSN има само ред, указващ целевата база данни. Т.е. искате това:
      [MYDSN]
      Database=MYDB
      Server=MYMACHINE
      .
      .
      .
      [ANOTHERDSN]
      

      Не

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

      —Или—

      [MYDSN]
      Database=MYDB
      Server=MYMACHINE
      Database=
      .
      .
      .
      [ANOTHERDSN]
      
  2. Ако не посочите изрично база данни, проверете при вашия DBA дали базата данни по подразбиране за вашия потребител е тази, която смятате, че е. Например, в SQL Server е възможно да се конфигурира вход за връзка с конкретна база данни, така че в:
    [MYDSN]
    Database=MYDB
    Server=MYMACHINE
    User=MYUSER.
    .
    .
    [ANOTHERDSN]
    

    MYUSER може първоначално да се свърже да каже AdventureWorks, ако входът е конфигуриран към конкретна база данни, или главната база данни, ако не е.

  3. Проверете дали се свързвате с DSN, който мислите, че сте. Дори ако сте добавили своя DSN към вече съществуваща версия на, да речем /etc/odbc.ini, това не означава, че вашият мениджър на драйвери търси в този файл. В зависимост от това как е изграден мениджърът на драйвери или е зададена средата, той може да търси на различно място. За да проверите, опитайте да коментирате атрибута Driver в източника на данни. Ако все още можете да се свържете, вие използвате различна версия на DSN. Използвайте програма като strace или truss, за да разберете кой файл odbc.ini се използва. Например:
    $ 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
    

    Ако сте копирали DSN от друга машина, опитайте да повторите този процес на тази машина, за да проверите местоположението на изходния DSN.

  4. Проверете дали се свързвате с СУБД, за която смятате, че сте. Например, ако не е твърде разрушително, опитайте да поставите на пауза / спрете целевия екземпляр / услуга за СУБД. Ако все още можете да се свържете, вие се свързвате към СУБД на друга машина. Вероятно вашата мрежа е конфигурирана така, че друга машина да изглежда, че има същия IP адрес като този, посочен в DSN.
  5. В isql въведете „помощ“. Какво име на базата данни се показва в списъка с върнати таблици? Това ли е, което очаквате? Ако не, какво ще се случи, ако въведете:
    use database
    

    Заменете база данни с името на целевата база данни. Ако не можете да промените базата данни, проверете с вашия DBA дали има тригер за влизане, който контролира достъпа до бази данни по IP адрес. В SQL Server Management Studio тригерите за влизане са под INSTANCE> Обекти на сървъра> Тригери.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Анализиране на данни от QuickBooks в Dundas BI

  2. Решете между базирано на агент срещу наблюдение без агент

  3. Свързване със Sage от Java

  4. Проста параметризация и тривиални планове — част 1

  5. Как да конвертирате низ в главни букви в SQL