This is the final release of the 6.6.x branch.
While
MySqlDateTime.Millisecond
already allowed a value between 0 and 999 (3 digit precision), a newMySqlDateTime.Microsecond
property was added to handle microseconds (6 digit precision) onDateTime
values. (Bug #20019257)The fluent API DbModelBuilder.HasColumnType had no effect in Entity Framework 6. (Bug #19476922, Bug #19456229, Bug #19462808)
-
Setting a Primary Key GUID identity in "Code First" in Entity Framework 6 did not function with MySQL server 5.7. Inserting a row with a valid value for the GUID generated an error, even when it had a trigger set to the correct value.
As a workaround, it was necessary to redeclare the column definition to accept a dummy default, such as "default ''". (Bug #19456452, Bug #19462811, Bug #19476995)
Non Primary Keys declared as "Identity GUID" did not have their GUID's automatically generated. (Bug #19456415, Bug #19461919, Bug #19477029)
Creating a "Model First" or "Database First" model using MySQL 5.7 would set ProviderManifestToken to 5.6. (Bug #19453814, Bug #19475012)
-
When using Entity Framework 4.3 Code first Identifiers for Migrations and Entity Framework 6, generated foreign key identifiers could be longer than 64 characters, causing
MySQLException
errors. The fix renames any too-long identifiers using the name formatFK_
, whereguid
guid
is a global unique identifier generated at runtime. (Bug #19211564, Bug #19483128)References: This issue is a regression of: Bug #67285.
When trying to alter a stored procedure or trigger that included references to session variables, an error occurred and the changes were not saved, unless "Allow User Variables=true" was set in the connection settings. An error is no longer generated, and similar issues with renaming stored procedures or triggers using Alter Routine were also fixed. (Bug #19211432)
In Visual Studio, Connector/NET did not read the millisecond portion of a time value for a field of type TIME(3). (Bug #19211409, Bug #18111085)
The MySQL parser did not recognize the full string literal syntax of
[
as supported by the MySQL Server. This fix makes Connector/NET and MySQL for Visual Studio recognize the string literal syntax as specified in the specified in Character String Literal Character Set and Collation, in the MySQL Server manual. (Bug #19211249, Bug #18169145)_charset_name
]'string
' [COLLATEcollation_name
]When the connection limit was exceeded,
MySqlConnection.Open()
would leave the TCP connections in aCLOSE_WAIT
state, but now closes them. (Bug #18665388, Bug #72025)When a client refreshed a web page associated with an expired session and if the ASP.NET project was using <SessionState ... regenerateExpiredSessionId="true" ...>, a "duplicate entry" exception was generated from the
MySqlSessionProvider
. (Bug #18657550, Bug #19783515, Bug #70409)Entity Framework threw a
NullReferenceException
on insertion of a record into tables that had an auto-increment, unsigned, bigint primary key. (Bug #18189217, Bug #19211404, Bug #71242)In Visual Studio, the stored procedure debugger did not evaluate the
last_insert_id()
function in a watch expression correctly. This fix also corrects similar issues for two other information functions that query the debug data table:row_count()
andfound_row()
. (Bug #18111085)When Connector/NET's SQL generator emitted code for the LINQ
Union()
orConcat()
operator, parentheses were not applied around the individualSELECT
statements. That could cause a change of meaning for the query when aTake()
operator (thus aLIMIT
clause in the SQL code) was applied to the lastSELECT
statement. With this fix, parentheses were put around individual SELECT statements, so that theLIMIT
clause will not be applied to the entire result of theUNION
operation. (Bug #18049691, Bug #19211182, Bug #19483110, Bug #70828)The MySQL parser could not parse an
if
statement when there were any spaces before the parenthesis for the arguments (for example, “if (1,1, 1)”). Besidesif
, the same issue occurred for a number of other functions likerow_count
,ifnull
,mod
,repeat
, and so on, and this fix corrects the problem for all of them. (Bug #17981407, Bug #19211240)The value for the
Keepalive
option in the connection string was interpreted by Connector/NET to be in milliseconds. This fix makes it to be interpreted as number of seconds, as specified in the documentation. (Bug #17981275, Bug #19211293, Bug #69484)A MySQL-session-state-enabled web application threw exceptions for referencing the wrong table name
my_aspnet_Sessions
(instead of the correct namemy_aspnet_sessions
). This was due to the incorrect case handling of the SQL queries forMySqlSessionStateStore
. (Bug #17960855, Bug #19211384, Bug #69652)The
RenameColumn
operation in an Entity Framework migration threw an “Unknown column 'no' in the 'field list'” error whenUpdate-Database
was applied. (Bug #17959787, Bug #71102)In Visual Studio, Intellisense did not treat the keywords “describe” and “desc” as synonyms of “explain”. (Bug #17956087, Bug #19211401)
In Visual Studio, Intellisense showed views from all databases, instead of just the current one. (Bug #17954412, Bug #19211338)
Connector/NET did not add the
AUTO_INCREMENT
property to a primary key column of typeBIGINT
when creating a model in Entity Framework. (Bug #17924407, Bug #17937401, Bug #70602)Fractional part of a value read by
MySqlDataReadeer.GetTimeSpan()
from aTIME(3)
-typed field was dropped. (Bug #17923814, Bug #70377)When opening or creating a
.mysql
file, trying to invoke Intellisense caused an error in some cases. (Bug #17890216)Sometimes invoking the IntelliSense code completion (Control + J) on a MySQL file would emit an error. (Bug #17890216)
Connector/NET threw a
NullReferenceException
when trying to save an entity into a table with atinyint
orbigint
auto-incremented primary key. (Bug #17866076, Bug #70888)Debugger failed to debug a routine correctly when it had two functions in a single expression. That was due to an error in handling the scope of the second function, which has been fixed. (Bug #17865915)
In Visual Studio, the debugger failed with parser errors when debugging stored procedures with a
Leave
statement. (Bug #17616344)When debugging a stored routine in Visual Studio with the debugger, long identifiers caused the error "data too long for column 'pvarname'" to be thrown. That was because the SQL script of the debugger did not support the same lengths for identifier names as the MySQL server does. This fix matches the debugger with the MySQL server on the maximum lengths supported for identifier names. (Bug #17568158, Bug #70159)
When using the Code First approach in Entity Framework 5, a LINQ query that checked whether a nullable column was null resulted in a faulty SQL query being generated. (Bug #17285548, Bug #69922)