MySQL Bugs: #6155: ODBC: SQLExecute hangs and does not return

Bug #6155	ODBC: SQLExecute hangs and does not return
Submitted:	19 Oct 2004 9:41	Modified:	3 Nov 2004 14:00
Reporter:	Michael Ziehensack	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MaxDB	Severity:	S2 (Serious)
Version:	7.5.00.18	OS:	Windows (Windows 2000)
Assigned to:	Ulf Wendel	CPU Architecture:	Any

Description:
ODBC-Problem:

SQLExecute hangs and does not return, data volumes of MaxDB database are written until full, when inserting a "long" unicode (UCS-2 format) string (e.g., length 20.000) bound to a SQL_C_WCHAR buffer into a table-column of type "long unicode". Problem occurs when length indicator is not given explicit but only as SQL_NTS.

How to repeat:
How to repeat:

- MaxDB 7.5.00.18 installation on Windows 2000 SP, 4 32-Bit
- Unicode-enabled database (i.e., _UNICODE = YES)
- Database default code set to unicode (i.e., DEFAULT_CODE = UNICODE)
- Table with column of type "long unicode" (i.e.,
  "CREATE TABLE test (val long unicode)"
- (Local) ODBC-datasource with sqlod32w.dll "MaxDB (Unicode)" ODBC-driver,
   version 7.5.00.18
- _PACKAGE_SIZE parameter of database has default value of MaxDB "small database"-template (i.e., 36864)

See attached sample code in "LongUnicodeStrValErrApp.cpp". Inserting a "small" value (in the example length 5.000) works fine, inserting "long" value (in example length 25.000) fails as described above.

I found a "fixed bug" entry in the document "changes_7.5.00.16.html" which refers to a quite similar problem, but reported for 64-bit systems.
Anyway, the problem described here still occurs with 7.5.00.18 on a 32-bit system. Workaround described for the fixed bug also seems to work for this problem (i.e., increasing _PACKAGE_SIZE), but _PACKAGE_SIZE has an upper limit of 131072 KB...

Sample application to demonstrate the bug

Attachment: LongUnicodeStrValErrApp.cpp (application/octet-stream, text), 3.31 KiB.

Michael,

thank you for the information! I could reproduce the problem on a XP Professional box. It seems to be a new bug. 

Your message has been forwarded to the ODBC developers. I will keep you up to date with progress informations.

Best regards,
Ulf Wendel

Ahoy,

the reason has been found for this bug: an internal offset calculation did not take the charset into account. 

Build 19 will be released very soon, build 20 is almost closed. Do not expect a fix before build 21 (7.5.00.21). Sorry, I can not give you a timeframe for build 21.

Best regards,
Ulf Wendel

Let me close this one also. It has been passed to the developers and will be handled. Very likely build 21 will come up with a solution.

Best regards,
Ulf Wendel