2009-10-05 72 views
5

¿Alguien tiene una idea de lo que significa este error o cómo solucionarlo? Estoy usando Access 2003 y SQL2005. Aparece cuando intentas agregar un registro en un subformulario en particular.Error de MS Access "ODBC: error de llamada. Valor de caracteres no válido para la especificación de conversión (# 0)"

[Microsoft] [SQL Native Client] valor de carácter no válido para la especificación de conversión (# 0)

This MS bug report describe el mismo mensaje, pero es un error en SQL Server 6.5 que ya ha sido resuelto.

Resuelto: Al parecer, al no tener PK en la tabla de destino estaba causando esto, no tenía nada que ver con el subformulario o la consulta de Access. Ni siquiera sabía que había tablas en esta base de datos sin PK. Agregar PK a la tabla de destino lo resolvió. Lo extraño es la misma cadena de consulta que tuvo errores cuando se ejecutó a través del cliente nativo de SQL, ejecutado a través de SSMS sin errores. Espero que esto ayude a cualquier otra persona que haya encontrado ese extraño mensaje.

Respuesta

6

Hum, yo verificaría el cuadro de texto predeterminado en el lado de acceso. También mostraría la tabla vinculada en modo de diseño, y desea verificar el tipo de datos que ms-access asume aquí. Para tipos de datos no compatibles, ms-access generalmente usará una cadena, y el servidor sql podría querer algo más.

Por lo tanto, compruebe la clave primaria (PK) en la tabla principal y luego verifique el tipo de datos utilizado (asumido) en la tabla secundaria para la columna de clave externa (FK). Mientras estamos en esto, verifique las expresiones utilizadas para la configuración de enlace principal/secundario en el control de subformulario (no el formulario, ni el subformulario, sino el control de subformulario utilizado en su formulario que vincula estas dos tablas)

Los formularios secundarios en el acceso son confidenciales si no tiene una columna de marca de tiempo en la tabla del servidor sql. Como se mencionó, compruebe los tipos de datos PK y FK y asegúrese de que coincidan (solo abra las tablas en modo diseño en ms-access) aparece un mensaje de error sobre el modo de diseño de solo lectura, pero continúe para que pueda puede verificar/ver para asegurar que los tipos de datos coinciden).

Por lo tanto, para la tabla secundaria, necesita un PK, un FK y también una columna de marca de tiempo (no es necesario que muestre la columna TS en el formulario secundario, pero lo necesita en la tabla).

Los subformularios en ms-access son confidenciales y suelen fallar si no se incluye una columna de marca de tiempo en la tabla sql. (Access utiliza estas columnas de versión de fila para determinar si los datos se han cambiado).

+2

Tenías razón ... 2 horas después ... fue porque la mesa de niños no tenía PK ... ¡grr! –

+0

Para seducir a la buena respuesta de Albert, permítame decir que acabo de convertir en práctica en SQL Server incluir un campo de marca de tiempo en cada tabla como rutina, simplemente hace las cosas más fáciles. Nunca tendría una tabla sin PK en ningún motor de db, ¡así que esa no es una regla que deba obligarme a seguir! –

+0

buena deducción +1 –

3

¿Uno de sus campos en la vista se calcula/construye con la función CAST? En este caso, es posible que no tenga derecho a actualizar/agregar un valor para ese campo.

¿Puede ejecutar su vista en la interfaz de MS SQL Studio e intentar insertar un registro?

+0

Hola, no sé qué se está ejecutando en realidad. Insertar un registro en el formulario en sí funciona bien, pero intentar insertarlo cuando ese formulario es un subform causa este error. El subformulario simplemente inserta un solo valor de texto, sin funciones, sin vba. –

+0

en mi opinión, el mensaje que recibe significa que la vista utiliza la función CAST en algún lugar para calcular un valor en un campo, por lo que no se puede actualizar el campo correspondiente. Si el problema es específico del subformulario, entonces el vínculo entre el formulario y el subformulario, o la clave primaria del conjunto de registros de subformulario, se puede construir en este valor calculado. –

+0

Estoy viendo lo que está sucediendo actualmente con el Analizador de SQL ahora, gracias por contarme sobre él, no puedo creer que ni siquiera lo sabía antes. –

0

Basado únicamente en el mensaje que proporcionó anteriormente, parece que está tratando de establecer un valor no válido para algún campo o parámetro, etc. El mensaje le indica que está tratando de convertir un valor en un específico tipo de datos pero el valor no es válido para ese tipo de datos ... ¿tiene sentido?

Agregue más detalles para que podamos ayudarlo mejor.

1

Otra causa de este problema es que si cambia el nombre de una tabla sin alterar la vista, las "Dependencias" de esa vista seguirán apareciendo con el nombre anterior de la tabla.

Digamos que tengo una tabla 'A' y una vista 'Av' que deriva de 'A', y creé una nueva tabla que se llamará 'A' y cambié el nombre 'A' a 'A_old' pero No ejecuté ALTER VIEW, por lo que las dependencias de 'Av' permanecen en 'A_old' pero la vista es derivada de 'A' y está duplicando este error en Access cuando intenta abrir la vista como una tabla vinculada

1

Acabo de pasar un día luchando contra esto con un proyecto Access ADP que se importó en un nuevo archivo ACCDB de Access 2016. Inicialmente pensé que era un problema con el código de la aplicación, pero estaba obteniendo estos registros directamente en la tabla. Curiosamente, los registros siempre se escribieron, parecía ser la respuesta que desencadenaba el error. Perfilar el insert sql y ejecutarlo desde SQL Management Studio funcionó sin problemas.

La tabla que estaba causando los problemas tenía una Clave principal de GUID. Cambiar eso a una columna int resolvió el problema.

La base de datos SQL también estaba llena de miles de propiedades extendidas que eliminé antes de cambiar el PK. Hubo una fuerte sugerencia de la web que estos causan problemas. La fuente de ese proceso está documentada aquí: Remove All SQL Extended Properties

1

Tuve este problema con Access 2016 tratando de actualizar una base de datos de servidor de SQL Server enlazado de ODBC. El problema fue un valor nulo en el campo utilizado para unir las dos tablas. La eliminación del valor nulo resolvió el problema

Cuestiones relacionadas