0

tengo una conexion ODBC desde mariaDB a SQLSERVER.

Al realizar una consulta where de este tipo:

SELECT * FROM `Pedidos` WHERE Número = "0001";

Me retorna el siguiente error:

#1296 - Got error 174 'Get result size: SQLExecDirect: [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]Invalid column name 'Número'. (rc=-1)' from CONNECT

El problema que observo es que: AL hacer la consulta con con la columna Número con acento, ODBC lo envia asi:

Número

Esto solo ocurre con esta columna, las demas consultas por otras columnas no pasa lo mismo.

Datos extras:

La base de datos sql server tiene el siguiente intercalacion de charset:

SQL_Latin1_General_CP1_CI_AS

En maria DB en cambio, he probado cambiar tanto la DB, como las tablas y las columnas a:

latin1, utf8 en diferentes charset cada uno, pero aun asi, sigue enviando mal la columna numero.

¿Qué se podría hacer en este caso? alguno le ha pasado?

Datos adicionales: La consulta da error haciendo la consulta desde el phpmyadmin, incluso da el mismo error usando el terminal sql.

En laravel, que es donde tengo el sistema da el mismo error, pero en la respuesta, puedo observar que la consulta que hace en el mismo laravel no hay problema, pues en el error se ve bien la consulta con acento. El error lo da es el ODBC igual que las consultas que hago en phpmyadmin.

Y como ya he dicho, en laravel he probado varias charset.

latin1 utf8 utf8mb4

he probado diferentes variaciones unicode, general_ci, bin, spanish configurando tanto el texto en el codigo antes de enviar, la conexion hacia el mysql en el database.php de laravel y los charset en la base de datos, las tablas y las columnas.

He probado casi todo en cuanto a los charset, o por lo menos lo que conozco.

Adicional 1 Jul 2021

Código de conexión odbc:
CREATE TABLE Pedidos (
    Número nvarchar(100) NOT NULL,
    Cliente nvarchar(50) NOT NULL,
    Referencia nvarchar(50) NOT NULL,
    Cantidad int NULL,
    Fecha datetime NULL,
    Hora datetime NULL,
    PVP real NULL,
    Vendedor nvarchar(10) NULL,
    Observaciones nvarchar(255) NULL,
    Procesado nvarchar(1) NULL,
    TipoPrecio tinyint NULL
) 
engine=connect 
table_type=ODBC 
tabname='dbo.Pedidos' 
connection='DSN=MSSQLServer;uid=nombre-db;pwd=xxxxxxxxx'
option_list ='Memory=2'
CHARSET=utf8 DATA_CHARSET=utf8;
Susje
  • 406
  • 5
  • 18
  • Nunca fue una buena idea usar acentos o caracteres especiales para nombrar tablas, columnas o variables, porque si no tienes bien configurado el entorno habrá problemas, como ocurre aquí de hecho. El nombre de la columna se está interpretando como `Número` y esto puede deberse a varios motivos. Pon codificación `utf-8` en todo: documento HTML, servidor, conexión a la base de datos, etc y prueba de nuevo. – A. Cedano Jun 30 '21 at 18:27
  • Estoy de acuerdo contigo, lamentablemente no fui yo el que hizo la base de datos sql server. Y ya hice todas las configuraciones en cuanto a UTF se refiere desde mi lado. Mas que todo en mariadb. Pero no se si con ODBC se podria manejar alguna otra opcion... porque creo que al final el error lo produce cuando se envia de mariadb al sqlserver, es decir, mediante el ODBC. – Susje Jun 30 '21 at 19:43
  • Indica en la pregunta qué código usas para conectar a la BD, así podremos indicarte el modo correcto de configurar el charset. Dinos también si en el entorno PHP has configurado adecuadamente el charset. Para más detalles revisa [esta respuesta](https://es.stackoverflow.com/a/59510/29967) donde he tratado de explicar este asunto de un modo general. – A. Cedano Jun 30 '21 at 21:48
  • Gracias por responder @A.Cedano si probe lo que comentaste en el post, pero sigo sin efecto. El problema aqui creo que es el ODBC o algo en el servidor SQL (sacando el hecho de que colocaron una columna con acento... ya esto se escapa de mis manos.) El asunto seria que en mariadb existe algun charset sensible a acentos en los nombres de las columnas, asi como lo tiene sqlserver... que hasta donde he investigado no existe... – Susje Jun 30 '21 at 22:08
  • ¿Puedes mostrar el código de conexión? – A. Cedano Jun 30 '21 at 23:40
  • Listo, ya coloque el script que uso para crear la tabla y conectar a ODBC. @A.Cedano – Susje Jul 01 '21 at 13:07
  • El código no está completo. Pon el código PHP que usas para conectar. – A. Cedano Jul 01 '21 at 13:38
  • El codigo php no importa en esta consulta que hago, porque lo que quiero probar es la consulta desde el manejador mariadb hacia sql-server. El problema no esta en el codigo del sistema, sino en el odbc. – Susje Jul 01 '21 at 14:04
  • Estamos ante un error relativo al charset, y ese error puede estar en cualquier nivel, como te comenté antes, por eso conviene que muestres en la pregunta todo el recorrido de tu programa para poder detectar dónde está el error. Si no estás conectado desde PHP dinos desde dónde lo haces y muestra la forma de conectarte. – A. Cedano Jul 01 '21 at 14:13
  • 1
    Prueba por ejemplo a indicar el charset en la cadena de conexión: `connection='DSN=MSSQLServer;uid=nombre-db;pwd=xxxxxxxxx;charset=UTF-8'` – A. Cedano Jul 01 '21 at 14:19
  • Ya comente que da en todas las capas, desde el phpmyadmin por ejemplo cuando hago consulta o desde el mismo terminal por consola, por eso descarto que sea el laravel. osea que el problema no esta en laravel sino en la conexion y ya probe agregar el charset en la conexion odbc y nada. – Susje Jul 01 '21 at 14:35
  • 1
    Pues no sé qué más decirte. [Revisa lo que dice la documentación sobre los nombres de columna](https://docs.microsoft.com/es-es/sql/odbc/microsoft/column-name-limitations?view=sql-server-ver15). Prueba a poner el nombre de la columna entre comillas, o entre [] o entre backticks. – A. Cedano Jul 01 '21 at 14:51
  • De verdad que he probado diversas formas y entiendo lo que comentas, pero bueno, pense que alguien habria pasado por esto... La verdad es que el problema es la codigificacion de sql-server que es diferente a la mariadb, pues no hay una codificacion AS que sea especialmente para manejar acentos... Pero bueno, seguire investigando y si alguien mas tiene informacion agradeceria mucho el apoyo. – Susje Jul 01 '21 at 17:24
  • Yo no tengo entorno de prueba para reproducir tu escenario o poder verificar cuál pueda ser el problema. Sin duda alguien que trabaje con esas herramientas o haya pasado por algo parecido podrá ayudarte con más certeza. Espero que puedas resolver esto y que la solución sea compartida para que sirva en un futuro. – A. Cedano Jul 01 '21 at 17:30

0 Answers0