sql >> Base de Datos >  >> RDS >> Database

Solución de problemas de errores de tabla no encontrada

Recientemente, uno de nuestros clientes estaba experimentando problemas al intentar insertar algunos datos de Oracle® en una tabla de SQL Server. La inserción fallaba porque la tabla de destino en la instancia de SQL Server no estaba presente en la base de datos a la que se estaba conectando el cliente.

En última instancia, la solución a este problema fue la más simple. Este solucionador de problemas incluye esta solución y otras, en un intento de presentar una lista de soluciones potenciales para el problema en orden lógico. Aunque el solucionador de problemas se basa en un controlador ODBC de Easysoft que usa SQL Server como su base de datos de destino, muchos de los pasos son aplicables a otros controladores basados ​​en unixODBC para otras bases de datos.

  1. Verifique su fuente de datos (DSN) para su base de datos de destino.

    Esto normalmente se definirá en /etc/odbc.ini.

    Importante No omita estos pasos solo porque su DSN es una copia de una configuración de trabajo en otra máquina. Particularmente si esa configuración de trabajo está en otra plataforma y/o usa una versión diferente del controlador. Las diferentes versiones de un controlador ODBC pueden analizar el archivo odbc.ini de manera diferente, por ejemplo, algunos pueden usar la última versión de un DSN o atributo DSN que encuentran cuando hay duplicados, algunos pueden usar la última. Además, un controlador diferente en una plataforma diferente puede dejar de analizar el archivo odbc.ini si hay un carácter problemático en el archivo, como un retorno de carro.

    • Compruebe que solo haya una copia de la fuente de datos. Si hay varias versiones de la fuente de datos, cámbieles el nombre o elimine otras versiones. Es decir, quieres esto:
      [MYDSN]
      Database=MYDB
      

      —O—

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

      No

      [MYDSN]
      Database=MYDB
      
      [MYDSN]
      Database=MYDB
      
    • Cuando esté seguro de que solo tiene una copia del DSN, verifique que el DSN solo tenga una línea que especifique la base de datos de destino. Es decir, desea esto:
      [MYDSN]
      Database=MYDB
      Server=MYMACHINE
      .
      .
      .
      [ANOTHERDSN]
      

      No

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

      —O—

      [MYDSN]
      Database=MYDB
      Server=MYMACHINE
      Database=
      .
      .
      .
      [ANOTHERDSN]
      
  2. Si no especifica explícitamente una base de datos, verifique con su DBA que la base de datos predeterminada para su usuario es la que cree que es. Por ejemplo, en SQL Server es posible configurar un inicio de sesión para conectarse a una base de datos en particular, por lo que en:
    [MYDSN]
    Database=MYDB
    Server=MYMACHINE
    User=MYUSER.
    .
    .
    [ANOTHERDSN]
    

    MYUSER podría conectarse inicialmente para decir, AdventureWorks si el inicio de sesión se ha configurado para una base de datos en particular, o la base de datos Maestra si no lo ha hecho.

  3. Compruebe que se está conectando al DSN que cree que es. Incluso si ha agregado su DSN a una versión preexistente de, por ejemplo, /etc/odbc.ini, no significa que su administrador de controladores esté buscando en este archivo. Dependiendo de cómo se construya el administrador de controladores o se configure el entorno, podría estar buscando en una ubicación diferente. Para verificar, intente comentar el atributo del controlador en la fuente de datos. Si aún puede conectarse, está utilizando una versión diferente del DSN. Utilice un programa como strace o truss para averiguar qué archivo odbc.ini se está utilizando. Por ejemplo:
    $ 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 ha copiado un DSN desde otra máquina, intente repetir este proceso en esa máquina para verificar la ubicación del DSN de origen.

  4. Compruebe que se está conectando al DBMS que cree que es. Por ejemplo, si no es demasiado disruptivo, intente pausar/detener la instancia/servicio de destino para el DBMS. Si aún puede conectarse, se está conectando a un DBMS en otra máquina. Tal vez su red se haya configurado de manera que pueda parecer que otra máquina tiene la misma dirección IP que la especificada en el DSN.
  5. En isql, escriba "ayuda". En la lista de tablas devueltas, ¿qué nombre de base de datos se muestra? ¿Es el que esperas? Si no, qué sucede si escribe:
    use database
    

    Reemplazar base de datos con el nombre de la base de datos de destino. Si no puede cambiar la base de datos, verifique con su DBA si existe un activador de inicio de sesión que controle el acceso a las bases de datos por dirección IP. En SQL Server Management Studio, los activadores de inicio de sesión se encuentran en INSTANCE> Objetos del servidor> Activadores.