We are doing some performance tests on our website and we are getting the following error a lot:
*** 'C:inetpubfoo.plex' log message at: 2008/10/07 13:19:58
DBD::ODBC::st execute failed: [Microsoft][SQL Native Client]String data, right truncation (SQL-22001) at C:inetpubfoo.plex line 25.
Line 25 is the following:
SELECT DISTINCT top 20 ZIP_CODE, CITY, STATE FROM Zipcodes WHERE (ZIP_CODE like ?) OR (CITY like ?) ORDER BY ZIP_CODE
And lastly, this is perl code.
Any ideas?
EDIT: the issue here was that I was searching in the zip file with the string «74523%» which is too long. I ended up just not adding the % if they give five digits.
Either the parameter supplied for ZIP_CODE is larger (in length) than ZIP_CODEs column width or the parameter supplied for CITY is larger (in length) than CITYs column width.
It would be interesting to know the values supplied for the two ? placeholders.
answered Oct 8, 2008 at 15:58
Chris DriverChris Driver
2,2252 gold badges19 silver badges14 bronze badges
1
This is a known issue of the mssql ODBC driver. According to the Microsoft blog post:
The ColumnSize parameter of SQLBindParameter refers to the number of characters in the SQL type, while BufferLength is the number of bytes in the application’s buffer. However, if the SQL data type is varchar(n) or char(n), the application binds the parameter as SQL_C_CHAR or SQL_C_VARCHAR, and the character encoding of the client is UTF-8, you may get a «String data, right truncation» error from the driver even if the value of ColumnSize is aligned with the size of the data type on the server. This error occurs since conversions between character encodings may change the length of the data. For example, a right apostrophe character (U+2019) is encoded in CP-1252 as the single byte 0x92, but in UTF-8 as the 3-byte sequence 0xe2 0x80 0x99.
You can find the full article here.
1
I got around the issue by using a convert on the «?», so my code looks like convert(char(50),?) and that got rid of the truncation error.
0
I was facing the same issue. So, i created a stored Procedure and defined the size like
@FromDate datetime,
@ToDate datetime,
@BL varchar(50)
After defining the size in @BL varchar(50), i did not face any problem. Now it is working fine
If the connection is done via PHP, we solved with the connection parameter «CharacterSet»:
sqlsrv_connect(DB_PTH_HOST, array(
"Database" => ***,
"UID" => ***,
"PWD" => ***,
"CharacterSet" => "UTF-8"));
I experienced this today on an application that has been running for years. My cause was a little different, so I figured I’d share to help anyone in the future that this happens to.
For the issue I experienced, we have an application that runs on Client machines and the clients talk to the DB server via ODBC connection. For whatever reason, the ODBC driver on the client had updated to a newer version than the server had, (which usually didn’t matter in the past). The version was only 1 month apart but was the cause of the issue. I went to windows patch history and uninstalled the patch whose date most closely matched the ODBC driver date, and this resolved the issue. (to check ODBC driver version, just search for ODBC in windows start, open ODBC 32, click on the drivers tab, scroll to the driver for the connection type you use, and the date is listed far right.)
Similar to the solution provided by luca.vercelli: in R, using dbConnect from the odbc package, you can specify the encoding used by the database. My database uses the SQL_Latin1_General_CP1_CI_AS collation, and specifying the latin1 encoding in dbConnect solved the problem.
We are doing some performance tests on our website and we are getting the following error a lot:
*** 'C:inetpubfoo.plex' log message at: 2008/10/07 13:19:58
DBD::ODBC::st execute failed: [Microsoft][SQL Native Client]String data, right truncation (SQL-22001) at C:inetpubfoo.plex line 25.
Line 25 is the following:
SELECT DISTINCT top 20 ZIP_CODE, CITY, STATE FROM Zipcodes WHERE (ZIP_CODE like ?) OR (CITY like ?) ORDER BY ZIP_CODE
And lastly, this is perl code.
Any ideas?
EDIT: the issue here was that I was searching in the zip file with the string «74523%» which is too long. I ended up just not adding the % if they give five digits.
Either the parameter supplied for ZIP_CODE is larger (in length) than ZIP_CODEs column width or the parameter supplied for CITY is larger (in length) than CITYs column width.
It would be interesting to know the values supplied for the two ? placeholders.
answered Oct 8, 2008 at 15:58
Chris DriverChris Driver
2,2252 gold badges19 silver badges14 bronze badges
1
This is a known issue of the mssql ODBC driver. According to the Microsoft blog post:
The ColumnSize parameter of SQLBindParameter refers to the number of characters in the SQL type, while BufferLength is the number of bytes in the application’s buffer. However, if the SQL data type is varchar(n) or char(n), the application binds the parameter as SQL_C_CHAR or SQL_C_VARCHAR, and the character encoding of the client is UTF-8, you may get a «String data, right truncation» error from the driver even if the value of ColumnSize is aligned with the size of the data type on the server. This error occurs since conversions between character encodings may change the length of the data. For example, a right apostrophe character (U+2019) is encoded in CP-1252 as the single byte 0x92, but in UTF-8 as the 3-byte sequence 0xe2 0x80 0x99.
You can find the full article here.
1
I got around the issue by using a convert on the «?», so my code looks like convert(char(50),?) and that got rid of the truncation error.
0
I was facing the same issue. So, i created a stored Procedure and defined the size like
@FromDate datetime,
@ToDate datetime,
@BL varchar(50)
After defining the size in @BL varchar(50), i did not face any problem. Now it is working fine
If the connection is done via PHP, we solved with the connection parameter «CharacterSet»:
sqlsrv_connect(DB_PTH_HOST, array(
"Database" => ***,
"UID" => ***,
"PWD" => ***,
"CharacterSet" => "UTF-8"));
I experienced this today on an application that has been running for years. My cause was a little different, so I figured I’d share to help anyone in the future that this happens to.
For the issue I experienced, we have an application that runs on Client machines and the clients talk to the DB server via ODBC connection. For whatever reason, the ODBC driver on the client had updated to a newer version than the server had, (which usually didn’t matter in the past). The version was only 1 month apart but was the cause of the issue. I went to windows patch history and uninstalled the patch whose date most closely matched the ODBC driver date, and this resolved the issue. (to check ODBC driver version, just search for ODBC in windows start, open ODBC 32, click on the drivers tab, scroll to the driver for the connection type you use, and the date is listed far right.)
Similar to the solution provided by luca.vercelli: in R, using dbConnect from the odbc package, you can specify the encoding used by the database. My database uses the SQL_Latin1_General_CP1_CI_AS collation, and specifying the latin1 encoding in dbConnect solved the problem.
We are doing some performance tests on our website and we are getting the following error a lot:
*** 'C:inetpubfoo.plex' log message at: 2008/10/07 13:19:58
DBD::ODBC::st execute failed: [Microsoft][SQL Native Client]String data, right truncation (SQL-22001) at C:inetpubfoo.plex line 25.
Line 25 is the following:
SELECT DISTINCT top 20 ZIP_CODE, CITY, STATE FROM Zipcodes WHERE (ZIP_CODE like ?) OR (CITY like ?) ORDER BY ZIP_CODE
And lastly, this is perl code.
Any ideas?
EDIT: the issue here was that I was searching in the zip file with the string «74523%» which is too long. I ended up just not adding the % if they give five digits.
Either the parameter supplied for ZIP_CODE is larger (in length) than ZIP_CODEs column width or the parameter supplied for CITY is larger (in length) than CITYs column width.
It would be interesting to know the values supplied for the two ? placeholders.
answered Oct 8, 2008 at 15:58
Chris DriverChris Driver
2,2252 gold badges19 silver badges14 bronze badges
1
This is a known issue of the mssql ODBC driver. According to the Microsoft blog post:
The ColumnSize parameter of SQLBindParameter refers to the number of characters in the SQL type, while BufferLength is the number of bytes in the application’s buffer. However, if the SQL data type is varchar(n) or char(n), the application binds the parameter as SQL_C_CHAR or SQL_C_VARCHAR, and the character encoding of the client is UTF-8, you may get a «String data, right truncation» error from the driver even if the value of ColumnSize is aligned with the size of the data type on the server. This error occurs since conversions between character encodings may change the length of the data. For example, a right apostrophe character (U+2019) is encoded in CP-1252 as the single byte 0x92, but in UTF-8 as the 3-byte sequence 0xe2 0x80 0x99.
You can find the full article here.
1
I got around the issue by using a convert on the «?», so my code looks like convert(char(50),?) and that got rid of the truncation error.
0
I was facing the same issue. So, i created a stored Procedure and defined the size like
@FromDate datetime,
@ToDate datetime,
@BL varchar(50)
After defining the size in @BL varchar(50), i did not face any problem. Now it is working fine
If the connection is done via PHP, we solved with the connection parameter «CharacterSet»:
sqlsrv_connect(DB_PTH_HOST, array(
"Database" => ***,
"UID" => ***,
"PWD" => ***,
"CharacterSet" => "UTF-8"));
I experienced this today on an application that has been running for years. My cause was a little different, so I figured I’d share to help anyone in the future that this happens to.
For the issue I experienced, we have an application that runs on Client machines and the clients talk to the DB server via ODBC connection. For whatever reason, the ODBC driver on the client had updated to a newer version than the server had, (which usually didn’t matter in the past). The version was only 1 month apart but was the cause of the issue. I went to windows patch history and uninstalled the patch whose date most closely matched the ODBC driver date, and this resolved the issue. (to check ODBC driver version, just search for ODBC in windows start, open ODBC 32, click on the drivers tab, scroll to the driver for the connection type you use, and the date is listed far right.)
Similar to the solution provided by luca.vercelli: in R, using dbConnect from the odbc package, you can specify the encoding used by the database. My database uses the SQL_Latin1_General_CP1_CI_AS collation, and specifying the latin1 encoding in dbConnect solved the problem.
I am trying to BCP a ton of data files into a SQL 2005 database. The first row of data in one of my files looks like:
1000|100000156752|100000176409|100000000000|100000000000|9.4|M|9.4||1/22/1993||1||||100|||||||||1|1/22/1993|||||||
The error file has this:
#@ Row 1, Column 7: String data, right truncation @#
0 0 0 0 0 .00 17|27.7|M|27.7||2/2/1993||1||||100|||||||||1|2/2/1993|||||||
I’ve built a format file based on the SQL Table definitions with this command:
FOR %%f IN (*.*) DO bcp IRIS.dbo.%%f format nul -T -n -t»|» -r»n» -f%%f.format
The format file for lines 1-8 look like:
1 SQLNUMERIC 1 19 «|» 1 SITE_ID «»
2 SQLNUMERIC 1 19 «|» 2 WEL_ID «»
3 SQLNUMERIC 1 19 «|» 3 WPOO_ID «»
4 SQLNUMERIC 1 19 «|» 4 WSMP_ID «»
5 SQLNUMERIC 1 19 «|» 5 CC_ID «»
6 SQLNUMERIC 1 19 «|» 6 CORE_LENGTH «»
7 SQLCHAR 2 2 «|» 7 LENGTH_MEASM_UNIT_ID SQL_Latin1_General_CP1_CI_AS
8 SQLNUMERIC 1 19 «|» 8 LENGTH_OF_CORE_RECOVD «»
Here is the DOS command window results for this file:
F:Data>cd import
F:DataImport>FOR %f IN (CONVT_CORES.*) DO bcp IRIS.dbo.%f in %f -e..BCP_Error
%f.error -Slocalhost -Usa -Psol3admin -f..BCP_Format%f.format
F:DataImport>bcp IRIS.dbo.CONVT_CORES in CONVT_CORES -e..BCP_ErrorCONVT_CORE
S.error -Slocalhost -Usa -Psol3admin -f..BCP_FormatCONVT_CORES.format
Starting copy…
SQLState = 22001, NativeError = 0
Error = [Microsoft][ODBC SQL Server Driver]String data, right truncation
SQLState = 22001, NativeError = 0
Error = [Microsoft][ODBC SQL Server Driver]String data, right truncation
SQLState = 22001, NativeError = 0
Error = [Microsoft][ODBC SQL Server Driver]String data, right truncation
SQLState = 22003, NativeError = 0
Error = [Microsoft][ODBC SQL Server Driver]Numeric value out of range
SQLState = 22001, NativeError = 0
Error = [Microsoft][ODBC SQL Server Driver]String data, right truncation
SQLState = 22001, NativeError = 0
Error = [Microsoft][ODBC SQL Server Driver]String data, right truncation
SQLState = 22001, NativeError = 0
Error = [Microsoft][ODBC SQL Server Driver]String data, right truncation
SQLState = 22001, NativeError = 0
Error = [Microsoft][ODBC SQL Server Driver]String data, right truncation
SQLState = 22001, NativeError = 0
Error = [Microsoft][ODBC SQL Server Driver]String data, right truncation
SQLState = 22001, NativeError = 0
Error = [Microsoft][ODBC SQL Server Driver]String data, right truncation
BCP copy in failed
F:DataImport>cd..
So, what is wrong???
Hi,
I have managed to create a partially functioning heterogeneous database link to SQL Server from Oracle. In TOAD, pulling back character data errors out with the following:
Pulling back numerical data is fine.
The Oracle database version is 12.1.0.2 running on Red Hat 6.7. I have used the following Microsoft driver:
ODBC Driver 13 for SQL Server.
Can anybody point me in the right direction on how to solve this frustrating issue?
My heterogeneous initSCOM.ora file which is located under $ORACLE_HOME/hs/admin looks like this:
#
# HS init parameters
#
HS_FDS_CONNECT_INFO = SCOM
HS_FDS_TRACE_LEVEL = Debug
HS_FDS_SHAREABLE_NAME = /usr/lib64/libodbc.so
#
# ODBC specific environment variables
#
set ODBCINI=/etc/odbc.ini
#
# Environment variables required for the non-Oracle system
#
#set <envvar>=<value>
Listener.ora file looks like this:
LISTENER =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = *********)(PORT = 1521))
(ADDRESS = (PROTOCOL = IPC)(KEY = *********))
)
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = SCOM)
(ORACLE_HOME = /app/oracle/12102/db)
(PROGRAM = dg4odbc)
)
)
Tnsnames.ora entry looks like this:
SCOM =
(DESCRIPTION =
(ADDRESS_LIST=
(ADDRESS =
(PROTOCOL = TCP)
(HOST = localhost)
(PORT = 1521)
)
)
(CONNECT_DATA = (SID = SCOM))
(HS = OK)
)
Any assistance would be greatly appreciated,
Cheers
Ed