MySQL Bugs: #28013: Records containing a "LONG"FIELD not updatable via ODBC

Bug #28013	Records containing a "LONG"FIELD not updatable via ODBC
Submitted:	22 Apr 2007 10:45	Modified:	10 May 2007 9:51
Reporter:	Louis Breda van	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	Connector / ODBC	Severity:	S1 (Critical)
Version:	3.51.14	OS:	Windows (VISTA64)
Assigned to:		CPU Architecture:	Any
Tags:	BLOB, Bug #13776, longtext, ODBC

Description:
Hello,

I just ran into the same problem as described in bug report #13776 , using 3.51.14 and 5117. 

Perhaps I am wrong, but I feel this bug is clossed before the problem is fixed. If so please explain.

The MigrationTool did convert a MS-ACCESS memo-field to a MySQL LONGTEXT. That is of course correct (but in my case a bit exaggerated).

However updating a record from access using an ODBC-connection to mysql turend out to be impossible.

In my case I could easily bypass the problem by changing the LONGTEXT to a TEXT, but in other cases that option is not available !!

So I do not feel comfortable with this problem. I would like to see a working solution, for the case there is a filled up LONGTEXT / BLOB in the table.

Sincerely,

Louis 

Bug #13776

How to repeat:
Just define a table containing somefields among them e.g. LONGTEXT.

Try to update that record using an odbc-connection from within ms-access. 

Suggested fix:
The sugested fix on the forum to use compression, is not a fix IMHO, at best a workarround, for cases where the field is not realy filled up.

Hi Louis and thanks for your report. Please do not open new one when there is a report describing your problem...

Now, I can't repeat your problem with 3.51.15 and MS Access 2003 on WinXP Pro SP2 localhost running MySQL 5.0.38BK:
1) mysql> create table bug28013 (
    -> Id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    -> FldLT LONGTEXT) ENGINE=MyISAM DEFAULT CHARSET=latin1;
Query OK, 0 rows affected (0.06 sec)
2) Link table to MS Access via file DSN
3) Add record to table
+----+-------+
| Id | FldLT |
+----+-------+
|  1 | Munja |
+----+-------+
1 row in set (0.00 sec)

If you can't provide me with more info / test case I will have to close this report as "Can't repeat"...

Hello, tonci

Sorry I have understanding for the fact that you can only limmited time on a problem. So have I. I simple do not have the time to test a couple of situations and make exact testcases.

However one thing in your responce did catch my eye, you are using the isam engine where I standard use the inodb engine (almost always). That makes a difference of course

Sincerely,

Louis

Louis, no one is limiting my time but I have to be fair to others... In any case, no problem, will test with InnoDB. In the meantime, you can try 3.51.15.

Same test repeated with MySQL server 5.0.38Enterprise on WinXP x64 localhost. I used 3.51.14GA and Access 2003SP2 on InnoDB table with same structure.

No problems detected probably due to correct metadata provided by server, ie. BINARY flag is not set:
Type:       BLOB
Flags:      BLOB

You may also test metadata retrieved like this:
mysql -uuser -p -hxxxx -T test
SELECT * FROM bug28013;