Bug in SQL Server 2000 ODBC driver when inserting unicode data in a non-unicode long varchar (text) column 
Author Message
 Bug in SQL Server 2000 ODBC driver when inserting unicode data in a non-unicode long varchar (text) column

Dear All,

I think I've found a bug in the SQL Server 2000 odbc driver
(2000.81.7713.00, the latest one). Below a scenario to reproduce this
problem:

1- create a test table in a SQL Server database with just one text column
(name it Col001)
2- create one row and fill this column with a large enough value (+- 257 KB
for instance). You can achieve this using the import/export tool of MS SQL
to insert the content of a text file in this column (use nice row and column
separators so you can insert the full text file in one column)
2- create a new MS Access (I'm using Access 2002) database
3- in this access database, create a test table with only one memo column
(name it Col001)
4- in this access database, create a linked table (through ODBC) to the SQL
server table created at step 1. This table will appear as dbo_test (or
something similar).
5- in this access database, create a new query (SQL) and execute INSERT INTO
TEST (Col001) SELECT Col001 from dbo_test --> this works OK
6- in this access database, create a new query (SQL) and execute INSERT INTO
dbo_test (Col001) SELECT Col001 from test --> this fails with this error
message:

ODBC--insert on a linked table 'dbo_test' failed. [Microsoft][ODBC SQL
Server Driver]String data, length mismatch (#0)

Making further research, I've discovered that :

1- With less data in the Access Col001 column (130 KB), the scenario doesn't
fail at step 6 anymore

2- If I use another SQL Server ODBC driver (e.g. DataDirect SQL Server
4.00.00.00 from Merant) for linking the SQL Server table under Access, the
scenario doesn't fail at step 6 anymore

3- If you change the data type for Col001 from text to ntext in the SQL
Server test table, the scenario doesn't fail at step 6 anymore. I've
compared the ODBC traces generated by MS Access at step 6 (with a text and
then a ntext column). The interesting portion of these traces are :

When Step 6 fails (with a text column):

...

MSACCESS        65c-610 ENTER SQLBindParameter
  HSTMT               09552B30
  UWORD                        1
  SWORD                        1 <SQL_PARAM_INPUT>
  SWORD                       -8 <SQL_C_WCHAR>
  SWORD                       -1 <SQL_LONGVARCHAR>
  SQLULEN               524962
  SWORD                        0
  PTR                0x27A83558
  SQLLEN                     0
  SQLLEN *            0x27A81130

MSACCESS        65c-610 EXIT  SQLBindParameter  with return code 0
(SQL_SUCCESS)
  HSTMT               09552B30
  UWORD                        1
  SWORD                        1 <SQL_PARAM_INPUT>
  SWORD                       -8 <SQL_C_WCHAR>
  SWORD                       -1 <SQL_LONGVARCHAR>
  SQLULEN               524962
  SWORD                        0
  PTR                0x27A83558
  SQLLEN                     0
  SQLLEN *            0x27A81130 (-525062)

MSACCESS        65c-610 ENTER SQLExecDirectW
  HSTMT               09552B30
  WCHAR *             0x27A83148 [      -3] "INSERT INTO  "dbo"."test"
("Col001") VALUES (?)\ 0"
  SDWORD                    -3

MSACCESS        65c-610 EXIT  SQLExecDirectW  with return code 99
(SQL_NEED_DATA)
  HSTMT               09552B30
  WCHAR *             0x27A83148 [      -3] "INSERT INTO  "dbo"."test"
("Col001") VALUES (?)\ 0"
  SDWORD                    -3

MSACCESS        65c-610 ENTER SQLParamData
  HSTMT               09552B30
  PTR *              0x0012E71C

MSACCESS        65c-610 EXIT  SQLParamData  with return code 99
(SQL_NEED_DATA)
  HSTMT               09552B30
  PTR *              0x0012E71C

MSACCESS        65c-610 ENTER SQLPutData
  HSTMT               09552B30
  PTR                0x27A81134
  SQLLEN                  8188

MSACCESS        65c-610 EXIT  SQLPutData  with return code 0 (SQL_SUCCESS)
  HSTMT               09552B30
  PTR                0x27A81134
  SQLLEN                  8188

...

MSACCESS        65c-610 ENTER SQLPutData
  HSTMT               09552B30
  PTR                0x27A81134
  SQLLEN                  8188

MSACCESS        65c-610 EXIT  SQLPutData  with return code 0 (SQL_SUCCESS)
  HSTMT               09552B30
  PTR                0x27A81134
  SQLLEN                  8188

MSACCESS        65c-610 ENTER SQLPutData
  HSTMT               09552B30
  PTR                0x27A81134
  SQLLEN                   930

MSACCESS        65c-610 EXIT  SQLPutData  with return code 0 (SQL_SUCCESS)
  HSTMT               09552B30
  PTR                0x27A81134
  SQLLEN                   930
MSACCESS        65c-610 ENTER SQLParamData
  HSTMT               09552B30
  PTR *              0x0012E71C

MSACCESS        65c-610 EXIT  SQLParamData  with return code -1 (SQL_ERROR)
  HSTMT               09552B30
  PTR *              0x0012E71C

  DIAG [22026] [Microsoft][ODBC SQL Server Driver]String data, length
mismatch (0)

...

When Step 6 works (with a ntext col):

MSACCESS             654-8a8 ENTER SQLBindParameter
  HSTMT               09B51800
  UWORD                        1
  SWORD                        1 <SQL_PARAM_INPUT>
  SWORD                       -8 <SQL_C_WCHAR>
  SWORD                      -10 <SQL_WLONGVARCHAR>
  SQLULEN               524962
  SWORD                        0
  PTR                0x326E3110
  SQLLEN                     0
  SQLLEN *            0x326E1110

MSACCESS             654-8a8 EXIT  SQLBindParameter  with return code 0
(SQL_SUCCESS)
  HSTMT               09B51800
  UWORD                        1
  SWORD                        1 <SQL_PARAM_INPUT>
  SWORD                       -8 <SQL_C_WCHAR>
  SWORD                      -10 <SQL_WLONGVARCHAR>
  SQLULEN               524962
  SWORD                        0
  PTR                0x326E3110
  SQLLEN                     0
  SQLLEN *            0x326E1110 (-525062)

MSACCESS             654-8a8 ENTER SQLExecDirectW
  HSTMT               09B51800
  WCHAR *             0x326E3128 [      -3] "INSERT INTO "dbo"."test"
("Col001") VALUES (?)\ 0"
  SDWORD                    -3

MSACCESS             654-8a8 EXIT  SQLExecDirectW  with return code 99
(SQL_NEED_DATA)
  HSTMT               09B51800
  WCHAR *             0x326E3128 [      -3] "INSERT INTO  "dbo"."test"
("Col001") VALUES (?)\ 0"
  SDWORD                    -3

MSACCESS             654-8a8 ENTER SQLParamData
  HSTMT               09B51800
  PTR *              0x0012E6E4

MSACCESS             654-8a8 EXIT  SQLParamData  with return code 99
(SQL_NEED_DATA)
  HSTMT               09B51800
  PTR *              0x0012E6E4

MSACCESS             654-8a8 ENTER SQLPutData
  HSTMT               09B51800
  PTR                0x326E1114
  SQLLEN                  8188

MSACCESS             654-8a8 EXIT  SQLPutData  with return code 0
(SQL_SUCCESS)
  HSTMT               09B51800
  PTR                0x326E1114
  SQLLEN                  8188

...

MSACCESS             654-8a8 ENTER SQLPutData
  HSTMT               09B51800
  PTR                0x326E1114
  SQLLEN                  8188

MSACCESS             654-8a8 EXIT  SQLPutData  with return code 0
(SQL_SUCCESS)
  HSTMT               09B51800
  PTR                0x326E1114
  SQLLEN                  8188

MSACCESS             654-8a8 ENTER SQLPutData
  HSTMT               09B51800
  PTR                0x326E1114
  SQLLEN                   930

MSACCESS             654-8a8 EXIT  SQLPutData  with return code 0
(SQL_SUCCESS)
  HSTMT               09B51800
  PTR                0x326E1114
  SQLLEN                   930

MSACCESS             654-8a8 ENTER SQLParamData
  HSTMT               09B51800
  PTR *              0x0012E6E4

MSACCESS             654-8a8 EXIT  SQLParamData  with return code 0
(SQL_SUCCESS)
  HSTMT               09B51800
  PTR *              0x0012E6E4

...

The only (major) difference is at the SQLBindParameter level. When the
column is text, Access pass SQL_LONGVARCHAR as the 5th parameter and when it
is a ntext, Access pass SQL_WLONGVARCHAR. I can conclude that the SQL Server
driver fails at the final SQLParam call when binding a unicode buffer (e.g
an Access memo column) to a non unicode sql server column and inserting a
large enough (at least 257 kb) value in this non unicode column.

We wanted this bug to be confirmed and fixed ASAP as many of our customers
are blocked by the same scenario executed by the application we develop.

Regards,
Gaetano Di Gregorio.



Sat, 08 May 2004 23:06:18 GMT  
 Bug in SQL Server 2000 ODBC driver when inserting unicode data in a non-unicode long varchar (text) column
As a MSDN Universal subscriber, I was expecting having a reply in maximum 72
hours (see http://msdn.microsoft.com/newsgroups/ for more info). So, I'm
reposting the same question and hope to have this time an answer from MS
Support Professionals.

Thanks.



Quote:
> Dear All,

> I think I've found a bug in the SQL Server 2000 odbc driver
> (2000.81.7713.00, the latest one). Below a scenario to reproduce this
> problem:

> 1- create a test table in a SQL Server database with just one text column
> (name it Col001)
> 2- create one row and fill this column with a large enough value (+- 257
KB
> for instance). You can achieve this using the import/export tool of MS SQL
> to insert the content of a text file in this column (use nice row and
column
> separators so you can insert the full text file in one column)
> 2- create a new MS Access (I'm using Access 2002) database
> 3- in this access database, create a test table with only one memo column
> (name it Col001)
> 4- in this access database, create a linked table (through ODBC) to the
SQL
> server table created at step 1. This table will appear as dbo_test (or
> something similar).
> 5- in this access database, create a new query (SQL) and execute INSERT
INTO
> TEST (Col001) SELECT Col001 from dbo_test --> this works OK
> 6- in this access database, create a new query (SQL) and execute INSERT
INTO
> dbo_test (Col001) SELECT Col001 from test --> this fails with this error
> message:

> ODBC--insert on a linked table 'dbo_test' failed. [Microsoft][ODBC SQL
> Server Driver]String data, length mismatch (#0)

> Making further research, I've discovered that :

> 1- With less data in the Access Col001 column (130 KB), the scenario
doesn't
> fail at step 6 anymore

> 2- If I use another SQL Server ODBC driver (e.g. DataDirect SQL Server
> 4.00.00.00 from Merant) for linking the SQL Server table under Access, the
> scenario doesn't fail at step 6 anymore

> 3- If you change the data type for Col001 from text to ntext in the SQL
> Server test table, the scenario doesn't fail at step 6 anymore. I've
> compared the ODBC traces generated by MS Access at step 6 (with a text and
> then a ntext column). The interesting portion of these traces are :

> When Step 6 fails (with a text column):

> ...

> MSACCESS        65c-610 ENTER SQLBindParameter
>   HSTMT               09552B30
>   UWORD                        1
>   SWORD                        1 <SQL_PARAM_INPUT>
>   SWORD                       -8 <SQL_C_WCHAR>
>   SWORD                       -1 <SQL_LONGVARCHAR>
>   SQLULEN               524962
>   SWORD                        0
>   PTR                0x27A83558
>   SQLLEN                     0
>   SQLLEN *            0x27A81130

> MSACCESS        65c-610 EXIT  SQLBindParameter  with return code 0
> (SQL_SUCCESS)
>   HSTMT               09552B30
>   UWORD                        1
>   SWORD                        1 <SQL_PARAM_INPUT>
>   SWORD                       -8 <SQL_C_WCHAR>
>   SWORD                       -1 <SQL_LONGVARCHAR>
>   SQLULEN               524962
>   SWORD                        0
>   PTR                0x27A83558
>   SQLLEN                     0
>   SQLLEN *            0x27A81130 (-525062)

> MSACCESS        65c-610 ENTER SQLExecDirectW
>   HSTMT               09552B30
>   WCHAR *             0x27A83148 [      -3] "INSERT INTO  "dbo"."test"
> ("Col001") VALUES (?)\ 0"
>   SDWORD                    -3

> MSACCESS        65c-610 EXIT  SQLExecDirectW  with return code 99
> (SQL_NEED_DATA)
>   HSTMT               09552B30
>   WCHAR *             0x27A83148 [      -3] "INSERT INTO  "dbo"."test"
> ("Col001") VALUES (?)\ 0"
>   SDWORD                    -3

> MSACCESS        65c-610 ENTER SQLParamData
>   HSTMT               09552B30
>   PTR *              0x0012E71C

> MSACCESS        65c-610 EXIT  SQLParamData  with return code 99
> (SQL_NEED_DATA)
>   HSTMT               09552B30
>   PTR *              0x0012E71C

> MSACCESS        65c-610 ENTER SQLPutData
>   HSTMT               09552B30
>   PTR                0x27A81134
>   SQLLEN                  8188

> MSACCESS        65c-610 EXIT  SQLPutData  with return code 0 (SQL_SUCCESS)
>   HSTMT               09552B30
>   PTR                0x27A81134
>   SQLLEN                  8188

> ...

> MSACCESS        65c-610 ENTER SQLPutData
>   HSTMT               09552B30
>   PTR                0x27A81134
>   SQLLEN                  8188

> MSACCESS        65c-610 EXIT  SQLPutData  with return code 0 (SQL_SUCCESS)
>   HSTMT               09552B30
>   PTR                0x27A81134
>   SQLLEN                  8188

> MSACCESS        65c-610 ENTER SQLPutData
>   HSTMT               09552B30
>   PTR                0x27A81134
>   SQLLEN                   930

> MSACCESS        65c-610 EXIT  SQLPutData  with return code 0 (SQL_SUCCESS)
>   HSTMT               09552B30
>   PTR                0x27A81134
>   SQLLEN                   930
> MSACCESS        65c-610 ENTER SQLParamData
>   HSTMT               09552B30
>   PTR *              0x0012E71C

> MSACCESS        65c-610 EXIT  SQLParamData  with return code -1
(SQL_ERROR)
>   HSTMT               09552B30
>   PTR *              0x0012E71C

>   DIAG [22026] [Microsoft][ODBC SQL Server Driver]String data, length
> mismatch (0)

> ...

> When Step 6 works (with a ntext col):

> MSACCESS             654-8a8 ENTER SQLBindParameter
>   HSTMT               09B51800
>   UWORD                        1
>   SWORD                        1 <SQL_PARAM_INPUT>
>   SWORD                       -8 <SQL_C_WCHAR>
>   SWORD                      -10 <SQL_WLONGVARCHAR>
>   SQLULEN               524962
>   SWORD                        0
>   PTR                0x326E3110
>   SQLLEN                     0
>   SQLLEN *            0x326E1110

> MSACCESS             654-8a8 EXIT  SQLBindParameter  with return code 0
> (SQL_SUCCESS)
>   HSTMT               09B51800
>   UWORD                        1
>   SWORD                        1 <SQL_PARAM_INPUT>
>   SWORD                       -8 <SQL_C_WCHAR>
>   SWORD                      -10 <SQL_WLONGVARCHAR>
>   SQLULEN               524962
>   SWORD                        0
>   PTR                0x326E3110
>   SQLLEN                     0
>   SQLLEN *            0x326E1110 (-525062)

> MSACCESS             654-8a8 ENTER SQLExecDirectW
>   HSTMT               09B51800
>   WCHAR *             0x326E3128 [      -3] "INSERT INTO "dbo"."test"
> ("Col001") VALUES (?)\ 0"
>   SDWORD                    -3

> MSACCESS             654-8a8 EXIT  SQLExecDirectW  with return code 99
> (SQL_NEED_DATA)
>   HSTMT               09B51800
>   WCHAR *             0x326E3128 [      -3] "INSERT INTO  "dbo"."test"
> ("Col001") VALUES (?)\ 0"
>   SDWORD                    -3

> MSACCESS             654-8a8 ENTER SQLParamData
>   HSTMT               09B51800
>   PTR *              0x0012E6E4

> MSACCESS             654-8a8 EXIT  SQLParamData  with return code 99
> (SQL_NEED_DATA)
>   HSTMT               09B51800
>   PTR *              0x0012E6E4

> MSACCESS             654-8a8 ENTER SQLPutData
>   HSTMT               09B51800
>   PTR                0x326E1114
>   SQLLEN                  8188

> MSACCESS             654-8a8 EXIT  SQLPutData  with return code 0
> (SQL_SUCCESS)
>   HSTMT               09B51800
>   PTR                0x326E1114
>   SQLLEN                  8188

> ...

> MSACCESS             654-8a8 ENTER SQLPutData
>   HSTMT               09B51800
>   PTR                0x326E1114
>   SQLLEN                  8188

> MSACCESS             654-8a8 EXIT  SQLPutData  with return code 0
> (SQL_SUCCESS)
>   HSTMT               09B51800
>   PTR                0x326E1114
>   SQLLEN                  8188

> MSACCESS             654-8a8 ENTER SQLPutData
>   HSTMT               09B51800
>   PTR                0x326E1114
>   SQLLEN                   930

> MSACCESS             654-8a8 EXIT  SQLPutData  with return code 0
> (SQL_SUCCESS)
>   HSTMT               09B51800
>   PTR                0x326E1114
>   SQLLEN                   930

> MSACCESS             654-8a8 ENTER SQLParamData
>   HSTMT               09B51800
>   PTR *              0x0012E6E4

> MSACCESS             654-8a8 EXIT  SQLParamData  with return code 0
> (SQL_SUCCESS)
>   HSTMT               09B51800
>   PTR *              0x0012E6E4

> ...

> The only (major) difference is at the SQLBindParameter level. When the
> column is text, Access pass SQL_LONGVARCHAR as the 5th parameter and when
it
> is a ntext, Access pass SQL_WLONGVARCHAR. I can conclude that the SQL
Server
> driver fails at the final SQLParam call when binding a unicode buffer (e.g
> an Access memo column) to a non unicode sql server column and inserting a
> large enough (at least 257 kb) value in this non unicode column.

> We wanted this bug to be confirmed and fixed ASAP as many of our customers
> are blocked by the same scenario executed by the application we develop.

> Regards,
> Gaetano Di Gregorio.



Tue, 11 May 2004 17:19:44 GMT  
 Bug in SQL Server 2000 ODBC driver when inserting unicode data in a non-unicode long varchar (text) column



Quote:
> Dear All,

> I think I've found a bug in the SQL Server 2000 odbc driver
> (2000.81.7713.00, the latest one). Below a scenario to reproduce this
> problem:

> 1- create a test table in a SQL Server database with just one text column
> (name it Col001)
> 2- create one row and fill this column with a large enough value (+- 257
KB
> for instance). You can achieve this using the import/export tool of MS SQL
> to insert the content of a text file in this column (use nice row and
column
> separators so you can insert the full text file in one column)
> 2- create a new MS Access (I'm using Access 2002) database
> 3- in this access database, create a test table with only one memo column
> (name it Col001)
> 4- in this access database, create a linked table (through ODBC) to the
SQL
> server table created at step 1. This table will appear as dbo_test (or
> something similar).
> 5- in this access database, create a new query (SQL) and execute INSERT
INTO
> TEST (Col001) SELECT Col001 from dbo_test --> this works OK
> 6- in this access database, create a new query (SQL) and execute INSERT
INTO
> dbo_test (Col001) SELECT Col001 from test --> this fails with this error
> message:

> ODBC--insert on a linked table 'dbo_test' failed. [Microsoft][ODBC SQL
> Server Driver]String data, length mismatch (#0)

> Making further research, I've discovered that :

> 1- With less data in the Access Col001 column (130 KB), the scenario
doesn't
> fail at step 6 anymore

> 2- If I use another SQL Server ODBC driver (e.g. DataDirect SQL Server
> 4.00.00.00 from Merant) for linking the SQL Server table under Access, the
> scenario doesn't fail at step 6 anymore

> 3- If you change the data type for Col001 from text to ntext in the SQL
> Server test table, the scenario doesn't fail at step 6 anymore. I've
> compared the ODBC traces generated by MS Access at step 6 (with a text and
> then a ntext column). The interesting portion of these traces are :

> When Step 6 fails (with a text column):

> ...

> MSACCESS        65c-610 ENTER SQLBindParameter
>   HSTMT               09552B30
>   UWORD                        1
>   SWORD                        1 <SQL_PARAM_INPUT>
>   SWORD                       -8 <SQL_C_WCHAR>
>   SWORD                       -1 <SQL_LONGVARCHAR>
>   SQLULEN               524962
>   SWORD                        0
>   PTR                0x27A83558
>   SQLLEN                     0
>   SQLLEN *            0x27A81130

> MSACCESS        65c-610 EXIT  SQLBindParameter  with return code 0
> (SQL_SUCCESS)
>   HSTMT               09552B30
>   UWORD                        1
>   SWORD                        1 <SQL_PARAM_INPUT>
>   SWORD                       -8 <SQL_C_WCHAR>
>   SWORD                       -1 <SQL_LONGVARCHAR>
>   SQLULEN               524962
>   SWORD                        0
>   PTR                0x27A83558
>   SQLLEN                     0
>   SQLLEN *            0x27A81130 (-525062)

> MSACCESS        65c-610 ENTER SQLExecDirectW
>   HSTMT               09552B30
>   WCHAR *             0x27A83148 [      -3] "INSERT INTO  "dbo"."test"
> ("Col001") VALUES (?)\ 0"
>   SDWORD                    -3

> MSACCESS        65c-610 EXIT  SQLExecDirectW  with return code 99
> (SQL_NEED_DATA)
>   HSTMT               09552B30
>   WCHAR *             0x27A83148 [      -3] "INSERT INTO  "dbo"."test"
> ("Col001") VALUES (?)\ 0"
>   SDWORD                    -3

> MSACCESS        65c-610 ENTER SQLParamData
>   HSTMT               09552B30
>   PTR *              0x0012E71C

> MSACCESS        65c-610 EXIT  SQLParamData  with return code 99
> (SQL_NEED_DATA)
>   HSTMT               09552B30
>   PTR *              0x0012E71C

> MSACCESS        65c-610 ENTER SQLPutData
>   HSTMT               09552B30
>   PTR                0x27A81134
>   SQLLEN                  8188

> MSACCESS        65c-610 EXIT  SQLPutData  with return code 0 (SQL_SUCCESS)
>   HSTMT               09552B30
>   PTR                0x27A81134
>   SQLLEN                  8188

> ...

> MSACCESS        65c-610 ENTER SQLPutData
>   HSTMT               09552B30
>   PTR                0x27A81134
>   SQLLEN                  8188

> MSACCESS        65c-610 EXIT  SQLPutData  with return code 0 (SQL_SUCCESS)
>   HSTMT               09552B30
>   PTR                0x27A81134
>   SQLLEN                  8188

> MSACCESS        65c-610 ENTER SQLPutData
>   HSTMT               09552B30
>   PTR                0x27A81134
>   SQLLEN                   930

> MSACCESS        65c-610 EXIT  SQLPutData  with return code 0 (SQL_SUCCESS)
>   HSTMT               09552B30
>   PTR                0x27A81134
>   SQLLEN                   930
> MSACCESS        65c-610 ENTER SQLParamData
>   HSTMT               09552B30
>   PTR *              0x0012E71C

> MSACCESS        65c-610 EXIT  SQLParamData  with return code -1
(SQL_ERROR)
>   HSTMT               09552B30
>   PTR *              0x0012E71C

>   DIAG [22026] [Microsoft][ODBC SQL Server Driver]String data, length
> mismatch (0)

> ...

> When Step 6 works (with a ntext col):

> MSACCESS             654-8a8 ENTER SQLBindParameter
>   HSTMT               09B51800
>   UWORD                        1
>   SWORD                        1 <SQL_PARAM_INPUT>
>   SWORD                       -8 <SQL_C_WCHAR>
>   SWORD                      -10 <SQL_WLONGVARCHAR>
>   SQLULEN               524962
>   SWORD                        0
>   PTR                0x326E3110
>   SQLLEN                     0
>   SQLLEN *            0x326E1110

> MSACCESS             654-8a8 EXIT  SQLBindParameter  with return code 0
> (SQL_SUCCESS)
>   HSTMT               09B51800
>   UWORD                        1
>   SWORD                        1 <SQL_PARAM_INPUT>
>   SWORD                       -8 <SQL_C_WCHAR>
>   SWORD                      -10 <SQL_WLONGVARCHAR>
>   SQLULEN               524962
>   SWORD                        0
>   PTR                0x326E3110
>   SQLLEN                     0
>   SQLLEN *            0x326E1110 (-525062)

> MSACCESS             654-8a8 ENTER SQLExecDirectW
>   HSTMT               09B51800
>   WCHAR *             0x326E3128 [      -3] "INSERT INTO "dbo"."test"
> ("Col001") VALUES (?)\ 0"
>   SDWORD                    -3

> MSACCESS             654-8a8 EXIT  SQLExecDirectW  with return code 99
> (SQL_NEED_DATA)
>   HSTMT               09B51800
>   WCHAR *             0x326E3128 [      -3] "INSERT INTO  "dbo"."test"
> ("Col001") VALUES (?)\ 0"
>   SDWORD                    -3

> MSACCESS             654-8a8 ENTER SQLParamData
>   HSTMT               09B51800
>   PTR *              0x0012E6E4

> MSACCESS             654-8a8 EXIT  SQLParamData  with return code 99
> (SQL_NEED_DATA)
>   HSTMT               09B51800
>   PTR *              0x0012E6E4

> MSACCESS             654-8a8 ENTER SQLPutData
>   HSTMT               09B51800
>   PTR                0x326E1114
>   SQLLEN                  8188

> MSACCESS             654-8a8 EXIT  SQLPutData  with return code 0
> (SQL_SUCCESS)
>   HSTMT               09B51800
>   PTR                0x326E1114
>   SQLLEN                  8188

> ...

> MSACCESS             654-8a8 ENTER SQLPutData
>   HSTMT               09B51800
>   PTR                0x326E1114
>   SQLLEN                  8188

> MSACCESS             654-8a8 EXIT  SQLPutData  with return code 0
> (SQL_SUCCESS)
>   HSTMT               09B51800
>   PTR                0x326E1114
>   SQLLEN                  8188

> MSACCESS             654-8a8 ENTER SQLPutData
>   HSTMT               09B51800
>   PTR                0x326E1114
>   SQLLEN                   930

> MSACCESS             654-8a8 EXIT  SQLPutData  with return code 0
> (SQL_SUCCESS)
>   HSTMT               09B51800
>   PTR                0x326E1114
>   SQLLEN                   930

> MSACCESS             654-8a8 ENTER SQLParamData
>   HSTMT               09B51800
>   PTR *              0x0012E6E4

> MSACCESS             654-8a8 EXIT  SQLParamData  with return code 0
> (SQL_SUCCESS)
>   HSTMT               09B51800
>   PTR *              0x0012E6E4

> ...

> The only (major) difference is at the SQLBindParameter level. When the
> column is text, Access pass SQL_LONGVARCHAR as the 5th parameter and when
it
> is a ntext, Access pass SQL_WLONGVARCHAR. I can conclude that the SQL
Server
> driver fails at the final SQLParam call when binding a unicode buffer (e.g
> an Access memo column) to a non unicode sql server column and inserting a
> large enough (at least 257 kb) value in this non unicode column.

> We wanted this bug to be confirmed and fixed ASAP as many of our customers
> are blocked by the same scenario executed by the application we develop.

> Regards,
> Gaetano Di Gregorio.



Mon, 24 May 2004 22:37:51 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. SQL server 2000 , a bug related to ODBC DSN ADO related

2. Refresh-Posting: UNICODE via ODBC on SQL-Server???

3. Refresh-Posting: UNICODE via ODBC on SQL-Server???

4. Refresh-Posting: UNICODE via ODBC on SQL-Server???

5. Unicode Edit box in non-unicode application?

6. Using Unicode DLL in Non-Unicode Exe

7. Access SQL Server 2000 Data Analysis Services

8. Does ODBC text driver support UNICODE?

9. SQL server 2000 CE and BLOB data

10. I cant insert Unicode Data Using CDatabase.ExecuteSQL

11. DAO with SQL-Server ODBC driver

12. problem with SQL Server ODBC drivers

 

 
Powered by phpBB® Forum Software