Debugging DAO to ADO Conversion Errors
-
I'm converting some old CDao classes to ADO (ODBC) for Access database handling. Part of my code copies a table record from one database to another. When I do the
CRecordset::UpdateI get aCDBExceptionthat completely unhelpfully tells me:m_strError "String data, right truncated
m_strStateNativeOrigin "State:22001,Native:31,Origin:[Microsoft][ODBC Microsoft Access Driver]Is there any way to get my code to tell me which field(s) is(are) causing the problem?
-
I'm converting some old CDao classes to ADO (ODBC) for Access database handling. Part of my code copies a table record from one database to another. When I do the
CRecordset::UpdateI get aCDBExceptionthat completely unhelpfully tells me:m_strError "String data, right truncated
m_strStateNativeOrigin "State:22001,Native:31,Origin:[Microsoft][ODBC Microsoft Access Driver]Is there any way to get my code to tell me which field(s) is(are) causing the problem?
Kyudos wrote:
right truncated
I would check the length of everything, data, parameter, target field in the table.
Never underestimate the power of human stupidity RAH
-
Kyudos wrote:
right truncated
I would check the length of everything, data, parameter, target field in the table.
Never underestimate the power of human stupidity RAH
-
I tried that...I can't find it! :sigh: Surely the driver must 'know' where this happens - why can't it just tell me? :rolleyes:
It is the same with SQL Server and has always been an irritant. With SQL Server you have sql profiler and you can trap the actual statement passed to the database including data. You can then manually execute the command in management studio. This gives you a more detailed error response and you can use the mark I eyeball to inspect the data. I know you can execute sql strings in Access but I do not know where to trap the command passed to the database from the client. I would strongly suggest moving the database from Access to SQL server if possible.
Never underestimate the power of human stupidity RAH
-
It is the same with SQL Server and has always been an irritant. With SQL Server you have sql profiler and you can trap the actual statement passed to the database including data. You can then manually execute the command in management studio. This gives you a more detailed error response and you can use the mark I eyeball to inspect the data. I know you can execute sql strings in Access but I do not know where to trap the command passed to the database from the client. I would strongly suggest moving the database from Access to SQL server if possible.
Never underestimate the power of human stupidity RAH
-
It is the same with SQL Server and has always been an irritant. With SQL Server you have sql profiler and you can trap the actual statement passed to the database including data. You can then manually execute the command in management studio. This gives you a more detailed error response and you can use the mark I eyeball to inspect the data. I know you can execute sql strings in Access but I do not know where to trap the command passed to the database from the client. I would strongly suggest moving the database from Access to SQL server if possible.
Never underestimate the power of human stupidity RAH
Mycroft Holmes wrote:
I would strongly suggest moving the database from Access to SQL server if possible.
That's impractical unfortunately. I've checked all the text field member lengths before and after the Update, they both match each other and the database definition. The are no problems in
DoFieldExchange. I don't know what to do next... -
It is the same with SQL Server and has always been an irritant. With SQL Server you have sql profiler and you can trap the actual statement passed to the database including data. You can then manually execute the command in management studio. This gives you a more detailed error response and you can use the mark I eyeball to inspect the data. I know you can execute sql strings in Access but I do not know where to trap the command passed to the database from the client. I would strongly suggest moving the database from Access to SQL server if possible.
Never underestimate the power of human stupidity RAH
-
Hah! :-O My fault of course - I was checking the wrong database definition - I had a field the wrong length! oops!
Yah, done that well... yesterday actually!
Never underestimate the power of human stupidity RAH