[ODBC-46] MicroFocus COBOL and MariaDB 31 bit ODBC - FETCH returns corrupt data Created: 2016-07-20  Updated: 2018-05-21  Resolved: 2018-05-21

Status: Closed
Project: MariaDB Connector/ODBC
Component/s: General
Affects Version/s: 2.0.11
Fix Version/s: N/A

Type: Bug Priority: Critical
Reporter: David Assignee: Lawrin Novitsky
Resolution: Not a Bug Votes: 0
Labels: None
Environment:

Windows 10, Microfocus Visual COBOL - Eclipse version MariaDB 10 and ODBC 31 bit driver

Attachments: Text File MYSQL.LOG     Text File SQL.LOG    

 Description   

simple table called 'family' with 1 column - 'name' defined as char(20)

COBOL source:
EXEC SQL BEGIN DECLARE SECTION END-EXEC
01 ws-name pic x(20).
EXEC SQL END DECLARE SECTION END-EXEC.

exec sql
DECLARE mycursor cursor for
SELECT name
FROM family
end-exec
exec SQL open cursor mycursor end-exec
perform until sqlstate = 02000
exec sql
fetch from mycursor into :ws-name
end-exec
display ws-name <---- displays garbage
end-perform

when I run the MicroFocus debugger the first value fetched contains this corruption:
Richard Sh peare
Hex:
56666762561000766762
29381240380000051250

for some reason x'100000' is overlaid in the char string. We are also seeing a SQLCODE = 1 suggesting a truncation of some sort.

If I run the select and specify INTO OUTFILE 'debug'
The name values are correctly saved - so the problem seems to be in the FETCH process into the program variable.

Recreated this using different tables and columns - same corruption occurs.

We have confirmed that this same program works fine when run against SQL Server.

I then installed the MYSQL 31 bit ODBC driver version 5.3.6 and used that instead of the Maria DB 31 bit ODBC driver -and the MYSQL connector works fine.
So this would seem to suggest that the MariaDB ODBC driver has a bug.

 Comments   
Comment by Lawrin Novitsky [ 2016-07-21 ]

Could you please provide ODBC trace for your testcase? Unfortunately we don't have MS Visual Cobol by hand to re-create your bug.

Comment by Lawrin Novitsky [ 2016-07-21 ]

I don't say "there is no bug". But I do need more info to be able to find where is the bug and eventually fix it. For that I asked you ODBC trace for your COBOL testcase run(https://support.microsoft.com/en-us/kb/274551)

Comment by David [ 2016-07-21 ]

I ran the ODBC tracing as requested. The DSN in use is daviddsn.
Attached is the log file.
SQL.LOG

Comment by David [ 2016-07-21 ]

if it helps, I also ran the ODBC trace using the MYSQL ODBC connector that works - the DSN is 'mysql31BitA' .
I attach the trace of that one working. - MYSQL.LOG

Comment by Lawrin Novitsky [ 2018-03-30 ]

Hello David,

I know it's been quite a while, I am sorry for that. But the thing is that we could't find error based on your trace files, and we don't have other ways to approach the problem.
Would it be possible to re-iterate with latest c/odbc versions? many things has been fixed since then, that could also cause your problem.

Otherwise we will close the issue.

Comment by Lawrin Novitsky [ 2018-05-21 ]

I am closing this bug. You are free to re-open it, if the problem persist with latest versions.
I guess the problems, that caused it, have been already fixed.
Trace file analysis and comparison with other connector's trace do not give much. I've noticed 2 problems - 1st is not supporting SQL_SCROLL_CONCURRENCY info type, that has been fixed with the patch for ODBC-71.
The other problem, is seemingly negative length value returned for SQL_DBMS_VER, which apparently also has been already fixed. I have extended one testcase to ensure that. But I don't think those could be the reason of the problem.
The problem itself cannot be seen from the trace file. After fetch of the 1st rowset, SQLNumResultCols is called (successfully) 5 times, and statement handler is closed.

Generated at Thu Feb 08 03:25:50 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.