UPDATE 02-JUN-2010: PROBLEM RESOLVED IN 6.3.2-alpha
Found a strange problem; not sure how to fix it; would love to get some ideas from the community; but, at a minimum wanted to document the symptoms and a few data points as it appears to
mask itself as other issues.
Update: This is being addresses as Bug #54040 - code sample provided
I'm using the
mysql-connector-net-6.3.1.zip connector on a 64-bit Windows 7 machine running VS2010 using C#/.NET 3.5 SP1 and Entity Frameworks connected to a local MySQL Server, version 5.1.42-community, hosted on the same platform with a UTF8 database with very simple tables. (For business reasons, I have no flexibility changing anything other than the dot-net connector.)
A select statement that works just fine
may consistently fail for certain rows, resulting in a
SQL Execution Error from Microsoft's environments, whether running use code or even Visual Studio itself. The error looks like this:
Quote
Executed SQL statement: SELECT id, name, value FROM t
Error Source: mscorlib
Error Message: Non-negative number required.
Parameter name: count
An error occurred while reading from the store provider's data reader. See the inner exception for details.
The field of interest, "value" shown above, is a TEXT field.
Looking at the inner exception, it becomes clear that this error is not about user-level SQL problems, concurrency, or resource issues, but rather that the MySQL connector has requested an invalid byte count while reading the column value of a
text column from memory.
(BTW, the backslashes appear as shown in the development environment, preserved this way should someone Google for them.)
Quote
Non-negative number required.\r\nParameter name: count
at System.IO.MemoryStream.Read(Byte[], Int32 offset, Int32 count)
at MySql.Data.MySqlClient.MySqlPacket.ReadString(Int64 length)
at MySql.Data.Types.MySqlString.MySql.Data.Types.IMySqlValue.ReadValue(MySqlPacket packet, Int64 length, Boolean nullVal)
at MySql.Data.MySqlClient.NativeDriver.ReadColumnValue(Int32 index, MySqlField field, IMySqlValue valObject)
at MySql.Data.MySqlClient.ReadColumnData(Boolean outputParms)
at MySql.Data.MySqlClient.NextRow(CommandBehavior behavior)
at MySql.Data.MySqlClient.MySqlDataReader.Read()
at MySql.Data.Entity.EFMySqlDataReader.Read()
at System.Data.Common.Internal.Materialization.Shaper`1.StoreRead()
Target site: {Int32 Read(Byte[], Int32, Int32)}
Because the error is about Bytes, rather than
characters, I went on the assumption that perhaps this was a Unicode issue where, perhaps, there's some confusion between length (how many characters there are) and size (how big the multi-byte representation is).
UPDATE: I know know this was a plausible, but incorrect assumption; I was close, it has to do with the length of the data -- see follow up message.
So, with that guess in hand, I altered the value of my
text field to contain a Unicode string with characters found from just the 7-bit ASCII set. Instantly, I could read the row, as could the Visual Studio tools. Copying a "broken" row's value to a "working" row, via SQL commands, caused the updated row to exception on a read by identical fashion.
Evidence is pointing toward the
value in the
text field tripping the cause of this exception.
UPDATE: Turns out it was the longer values that were causing problems.
This begs the question,
How did the Unicode data get into the text field in the first place?
The answer is that it was by the very same mechanism: Entity Frameworks using the MySQL dot-net connector. Apparently write operations work just fine.
UPDATE: This is valid to ask for lengthy strings, though; same answer, Entity Frameworks.
Using the straight MySQL command line client shows the field values just fine in the database, but note at
this point the dot-net connector is not involved.
For those curious about the database and the table itself, it looks like this:
Quote
CREATE DATABASE `d` /*!40100 DEFAULT CHARACTER SET utf8 */ ;
CREATE TABLE t (
id BIGINT(20) NOT NULL AUTO_INCREMENT,
name VARCHAR(255) NOT NULL,
value TEXT,
PRIMARY KEY (id)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
As others are experiencing this problem, but seem to be going off in unfulfilling directions without resolution, has anyone else here experienced it, know what it is about the data that causes the problem, or has a suggested workaround or fix?
Thanks,
-wls
UPDATE: Found the source of the problem. See the followup message.
Edited 4 time(s). Last edit at 06/02/2010 08:30AM by Walt Stoneburner.