Description:
Database Context:
Involved Table description:
Elements (FP INTEGER, NType TINYINT, Layer SMALLINT, DbId INTEGER, MinX BIGINT, MinY BIGINT, MinZ BIGINT, MaxX BIGINT, MaxY BIGINT, MaxZ BIGINT,
Info1 varbinary(30000), Info2 varbinary(30000))
holding 1,273,706 rows, stored in myISAM, in a mySQL server version 5.1.21, and with a total size of 153.2MB Data and 46.8 MB Index (by FP, by DbId and by MinX)
Bug Context:
Using .NET Connector, version 5.1.4.0 (but verified also with 5.0.8.1), and trying to execute the following statement from a VStudio 2005 C# project:
DataReader dr = cmd.ExecuteReader();
with a CommandText of:
select FP, NType, Layer, LtnId, MinX, MinY
from Elements
where (MinX <= 595115790) and (MinY <= 1348581818) and (MaxX >= 566177330) and (MaxY >= 1325791672) and
(MaxX - MinX < 29560) and (MaxY - MinY < 29560) and (NType <> 5) and (NType <> 10)
order by FP
I always got the following exception:
MySql.Data.MySqlClient.MySqlException: "Sort aborted"
Stack Trace:
at MySql.Data.MySqlClient.MySqlStream.OpenPacket()
at MySql.Data.MySqlClient.NativeDriver.ReadResult(UInt64& affectedRows, Int64& lastInsertId)
at MySql.Data.MySqlClient.MySqlDataReader.GetResultSet()
at MySql.Data.MySqlClient.MySqlDataReader.NextResult()
at MySql.Data.MySqlClient.MySqlCommand.ExecuteReader(CommandBehavior behavior)
at MySql.Data.MySqlClient.MySqlCommand.ExecuteDbDataReader(CommandBehavior behavior)
at System.Data.Common.DbCommand.ExecuteReader()
at myApp.Provider.ProviderDDBB._ReadWinForView(BinaryWriter bw) in C:\projects\myApp\myProviderddbb\ProviderDDBB.cs:line 777
with a _COMPlusExceptionCode of -532459699
Any time I try to execute such a command against the Elements table I got the same exception. However if I execute the command from "MySQL Query Browser" the query executes without any problem.
Executing the same command against a smaller table (65000 rows), everything goes fine.
If I modify the command, deleting the "ORDER BY" clause, then it works fine, but for us this is not an acceptable solution, because the after-command process depends on the preset order of the recovered elements
How to repeat:
Always happens, I tried the same several times, using versions 5.0.8.1 or 5.1.4.1 of the connector, executing against the server locally or remotely in my LAN, and always got the same behaviour.
Suggested fix:
none