A couple of users reported being unable to use the ADO.NET destination to insert data into their mysql databases. When I
originally tried this out
, it worked, but it seems like changes made since the early 2008 CTPs have made us incompatible with MySQL. We do have a bug logged to make this more flexible, but the good news is that in the meantime there is a workaround when using the
For the ADO.NET Destination to work properly, the MySQL database needs to have the
option enabled. This option can be
, or for a particular session. To enable it for a single session:
Set the connection manager’s RetainSameConnection property to True
Add an Execute SQL Task before your data flow to set the SQL_MODE – Ex. set sql_mode='STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
Make sure that your Execute SQL Task and your ADO.NET Destination are using the same connection manager.
Setting the RetainSameConnection property to True will ensure that your Execute SQL Task and ADO.NET Destination are in the same session.
Note, I recommend using the ODBC Driver when writing to the MySQL database, because the
MySQL .NET Connector
has an additional blocking issue. If you try it out, you’ll get an error which looks something like this:
Error: 2009-01-05 12:03:47.79
Source: Data Flow Task 1 Destination - Query 
Description: An exception has occurred during data insertion, the message returned from the provider is: You have an
error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use nea
r '"name", "date", "type", "remark")
VALUES (p1, p2, p3, p4), (p1,p2,p3,p4), (p1,p2'
at line 1
Note that the “VALUES” portion has parameter names, and not the actual values. This appears to be an issue with the value the MySQL provider returns for its ParameterMarkerFormat. I did find a
bug that was opened against them
, but it looks like they decided not to fix it. I’ve heard that the
DevArt dotConnect drivers
do not have this problem, but I haven’t been able to try them out myself.