MySQL Bugs: #3293: Bugs with C functions reported last year

Bug #3293	Bugs with C functions reported last year
Submitted:	25 Mar 2004 11:00	Modified:	30 Jun 2004 2:21
Reporter:	John Mallery	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	Connector / ODBC	Severity:	S1 (Critical)
Version:	MyODBC 3.51.06	OS:	MacOS (Mac OS X 10.3.3)
Assigned to:	Timothy Smith	CPU Architecture:	Any

Description:
I trying to bring up an application under Mac OS X using MySQL & MyODBC, and
I have run across some bugs in MyODBC.

Below is the report from the technical guru for the vendor which supplies my
programming environment. At the end is the recipe for the  installation of
MySQL and  MyOBDC that I am running.

Fixes to these long standing bugs in the MyOBDC driver (not to mention
a MySQL compiled version of the driver) would be greatly appreciated. (BTW,
this all worked fine on LINUX Redhat 8.0 and MySQL 3...)

John Mallery, MIT CSAIL

-----

From: Martin Simmons <martin@xanalys.com>
Date: Thu, 25 Mar 2004 18:28:00 GMT
Subject: Re: (Lisp Support Call #26813)  Common SQL query Bug on LW 4.3.6 MacOS X 10.3.3

SQLColAttributes() is returning the wrong value
(VALUE-1 is 0) for the SQL_COLUMN_TYPE attribute (5) in the cursor generated
by SQLTables().  This is probably a bug in the MyODBC.

We did try to get these problems with SQLGetTypeInfo(), SQLTables() and 
SQLColumns() fixed last year, but without much confirmed success:

http://makeashorterlink.com/?W1B2127D7

The initialize-odbc-database patch I sent you for the "0 is not of type
SEQUENCE." but actually removes the call to SQLGetTypeInfo() that was
returning 0, so it looks like they failed to fix any of it :-(

Regards,

Martin Simmons			martin@xanalys.com
Xanalys Technical Support 	
http://www.lispworks.com/support/

-------------

MySQL 4.0.18 was installed from: 

		http://www.mysql.com/downloads/index.html

	MyODBC 3.51.06 was installed by running the driver installer from: 

		http://www.serverlogistics.com/mysql.php

	ODBC Administrator was used to configure the drivers and DSN following 
	instructions in steps 4-9 in: 

		http://members.aol.com/_ht_a/bergert/osx/tip09.htm

	Testing with the mysql client reveals that the database works.

	Testing with odbctest revealed that ODBC was working.

How to repeat:
Call C code and look at incorrect returns.

Suggested fix:
Fix C code to return correct values.

Thanks for the bug report, and sorry for the delay in responding; we're slowly digging out from under a hill of MyODBC bugs.

I tried to repeat this on Darwin 7.3:

$ uname -a
Darwin powermacg5.mysql.com 7.4.0 Darwin Kernel Version 7.4.0: Wed May 12 16:58:24 PDT 2004; root:xnu/xnu-517.7.7.obj~7/RELEASE_PPC  Power Macintosh powerpc

I'm using gcc3 that comes with the OS:

$ gcc -v
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1640)

I'm using the iodbc from /usr, and I built myodbc-3.51.07 from source.  I had to follow the instructions on creating a .so that are in the ODBC faq.

I'm linking against the lib/libmysqlclient.a that is in mysql-standard-4.0.20-apple-darwin7.3.0-powerpc.tar.gz.  (See the GNUmakefile for details.)

I'm attaching my GNUmakefile and the test program I used (see the Files link on this bug).

This is the output I get from my test program:

$ ./colattr
Connecting (DSN='test', USER='<default>')
Table attributes comes in 18 columns
Column 01: (varchar)    [12]
Column 02: (varchar)    [12]
Column 03: (varchar)    [12]
Column 04: (varchar)    [12]
Column 05: (smallint)   [5]
Column 06: (varchar)    [12]
Column 07: (integer)    [4]
Column 08: (integer)    [4]
Column 09: (smallint)   [5]
Column 10: (smallint)   [5]
Column 11: (smallint)   [5]
Column 12: (varchar)    [12]
Column 13: (varchar)    [12]
Column 14: (smallint)   [5]
Column 15: (smallint)   [5]
Column 16: (integer)    [4]
Column 17: (integer)    [4]
Column 18: (varchar)    [12]
$ 

It seems that the SQL_DESC_TYPE attribute is coming back fine at this point.

Can you please test this program on your system?  And modify it so that it demonstrates this bug, and then attach the modified program to this issue.  Also let me know if there are any other things you had to modify to show up the problem.  My goal is to reproduce the problem, and then our ODBC developers will have a fighting chance at squashing the bug.

Thanks a lot!

Timothy

test program - please modify it so that it causes the problem

Attachment: colattr.c (application/octet-stream, text), 6.18 KiB.

GNUmakefile - the commands I use to make the program

Attachment: GNUmakefile (application/octet-stream, text), 286 bytes.