Upgrading from ByteFX to the .NET Connector for MySQL

Last night I made the switch from the older ByteFX Data provider for MySQL to the newer  .NET Connector for MySQL.  It required some code changes in the MySQL data layer. 

For Example, anywhere I was using parameters like @SiteID, they had to be changed to ?SiteID except in places where the parameter is not being passed in but used in SQL with a SET statement .

In this line:
SET @PageLowerBound = (?PageSize * ?PageNumber) - ?PageSize

?PageSize and ?PageNumber are passed in but @PageLowerBound is not and it wouldn't work if I used ? instead of @

Another difference is in ByteFx you have only one data type for int MySqlDbType.Int whereas in the newer .NET Connector you have MySqlDbType.Int16, MySqlDbType.Int24, MySqlDbType.Int32, and MySqlDbType.Int64 and it won't work with just MySqlDbType.Int so you have to change the code.

I wasn't having any problems with the ByteFX provider myself but a few people have posted in the forums and been unable to connect using ByteFX with their specific version of MySQL. One person tried switching to the .NET Connector and then was able to connect but of course without the code changes described above it did not work for him either.  Hopefully this change will eliminate any problems some users were having with the MySQL version of mojoPortal.  It will be included in tomorrow's release.

Another user reported problems with losing special characters when data was saved to the database.  He was working with Portuguese content and it worked correctly in Text fields populated using the FCKeditor but did not work correctly with VarChar fields populated using normal text boxes.  I don't know if this change will fix that problem but I hope so.

Other gotchas I have observed with ByteFX and .NET Connector when building on Windows and deploying on mono you get the dreaded "File Not Found error" which would more accurately be described as "Couldn't load assembly".  This is caused because these data providers are shipped with a pre-comiled version of sharpziplib that was built using incremental build.  This problem is easily overcome by obtaining the source code for sharpziplib and compiling it myself with full Re-Build.  By doing this I have no problems compiling on Windows with VS.NET and deploying on mono.