The original script had a schema with CHAR(46) and a 'convert' in the SELECT to CHAR(23).
That should have worked.
Timestamps are fixed length CHAR fields, not VARCHAR.
The fact that the original job did not run concerns me because it should have run fine.
The conversion of DateTime using code 121 converts to a 23-byte string.
With a client session character set of UTF16, the resultant string should have been 46 bytes.
That is what I see in my SQL Server test (not run with the ODBC operator yet).
Thus, I am wondering if the ODBC operator has a bug somewhere.
The fact that converting to VARCHAR did not issue an error is probably due to the operator binding the column as CHAR (since the schema indicated CHAR) and the ODBC driver converting from VARCHAR to CHAR.
The original script had a schema with CHAR(46) and a 'convert' in the SELECT to CHAR(23).
That should have worked.
Timestamps are fixed length CHAR fields, not VARCHAR.
The fact that the original job did not run concerns me because it should have run fine.
The conversion of DateTime using code 121 converts to a 23-byte string.
With a client session character set of UTF16, the resultant string should have been 46 bytes.
That is what I see in my SQL Server test (not run with the ODBC operator yet).
Thus, I am wondering if the ODBC operator has a bug somewhere.
The fact that converting to VARCHAR did not issue an error is probably due to the operator binding the column as CHAR (since the schema indicated CHAR) and the ODBC driver converting from VARCHAR to CHAR.