2010-08-11 14 views
5

Estoy ampliando una base de datos de acceso 2003 a SQL Server Express 2008. Parece que las tablas están bien creadas y los datos se ven bien.Advertencia de "datos de cadena, truncamiento derecho" en una instrucción de selección

Tengo una aplicación MFC que se conecta a esta base de datos. Funcionó bien al conectarse, pero cuando me conecto a SQL Server recibo el siguiente error en una declaración de selección.

DBMS: Microsoft SQL Server 
Version: 10.50.1600 
ODBC Driver Manager Version: 03.80.0000 
Warning: ODBC Success With Info on field 0. 
String data, right truncation 

State:01004,Native:0,Origin:[Microsoft][ODBC SQL Server Driver] 

Los datos que se devuelven deben tener 8 caracteres, pero solo 7 con el carácter más a la derecha truncado.

La interfaz de acceso puede leer los datos de SQL Server correctamente.

El campo de la tabla de SQL Server se define como nvarchar con una longitud de 8.

El código para leer el campo se ve algo como

CDatabase Database; 
CString sSerialNumber = "00000000"; 
CString SqlString; 

CString sDsn = "Driver={SQL Server};Server=server\\db;Database=Boards;Uid=uid;Pwd=pwd;Trusted_Connection=False"; 
Database.Open(NULL,false,false,sDsn); 

CRecordset recset(&Database); 
SqlString.Format("Select SerialNumber from boards where MACAddress = '%s'",mac); 
recset.Open(CRecordset::forwardOnly,SqlString,CRecordset::readOnly); 
recset.GetFieldValue("SerialNumber",sSerialNumber); 

Después de esto, debe ser sSerialNumber 12345678 pero su 1234567

Gracias por la ayuda

+0

¿Podemos suponer que en la base de datos, SerialNumber se está almacenando como 12345678 en la base de datos subyacente? – BIBD

+0

¿Para qué sirve la recompensa? ¿Lo hace funcionar sin el nuevo controlador? ¿Por qué alguien querría hacer eso? –

Respuesta

2

Estoy de acuerdo en que esto está relacionado con el controlador. El controlador {SQL Server} se introdujo para su uso con SQL 2000. {SQL Native Client} apareció junto con 2005. Idealmente, para su base de datos 2008, debe usar el más nuevo {SQL Server Native Client 10.0}. Los controladores más nuevos son compatibles con versiones anteriores de SQL Server.

2

Cambiar mi conductor de "Driver = {SQL Server};" a Driver = {SQL Native Client};

ha hecho desaparecer el problema, pero no estoy seguro de lo que estaba pasando. Voy a seguir investigando

+0

Lo más probable es que sea el conductor, tuve el mismo problema con CSV antes. Tenía una información, por ejemplo, 192.168.1.1 cuando se migra a SQL se convierte en 192.1681, pero cuando se actualizó para usar un controlador diferente funcionó. – Raymund

1

De un poco de Google, aprendí que aparentemente, en ocasiones, especialmente cuando se selecciona "Usar configuración regional" en el diálogo de configuración de DSN del controlador ODBC de MS SQL Server, ODBC tratará una cadena compuesta por todos los dígitos , como un número, y devolverlo como "12345678.00" que no encaja en el espacio que le ha dado. La solución es a su vez que de salir, ya sea en el cuadro de diálogo, o, de manera más permanente, en la cadena de conexión:

CString sDsn = "Driver={SQL Server};Server=server\\db;Database=Boards;" 
       +"Uid=uid;Pwd=pwd;Trusted_Connection=False;Regional=No;" 
+0

¿Ha verificado el OP si esto corrigió el problema con el controlador no nativo? –

0

Si es absolutamente necesario para cavar hasta el fondo de esto, hacer un procedimiento almacenado mínima que "seleccionará" var local definido como varchar (17) - cualquier tamaño más de 2 veces su tamaño original. Ahora llame al sproc en lugar del SQL dinámico y vea qué devuelve. Luego puede repetirlo exactamente con el mismo tamaño (nvarchar (8)). Su pequeño sproc sirve como un adaptador de datos fácil y para estabilizar el tipeo si el controlador viejo tiende a confundirse, mucho más fácil que jugar con la definición de la tabla.

Además, compruebe si hay algún parámetro/propiedad en las clases de interfaz/conexión para especificar la codificación de caracteres y asegúrese de que sea unicode (utf-16). Supongo que su código se compila para Unicode. De lo contrario, debe tomar una decisión al respecto primero (N en Nvarchar significa unicode, de lo contrario sería varchar). Definitivamente necesita una codificación de caracteres combinada en ambos lados o tendrá otros errores espurios.

Cuestiones relacionadas