Miguel de Icaza
miguel at novell.com
Fri May 1 18:00:18 EDT 2009
> mono-devel-list context: Scott found a bug in sqlmetal today, in that it
> wouldn't connect to a MySQL database. The problem was that
> sqlmetal.exe.config is used to specify which connection type to use for
> a given /provider option, and the MySQL entry was referencing an invalid
Is it possible to load the types dynamically, so that at least if the
end-user installs MySql.Data on his own, it will work?
ByteFX is not really supported and has not been for years, we just carry
it as baggage. Maybe we should [Obsolete] all of those types and
retire it in a few releases.
Our connection string for sqlmetal for ByteFX.Data should probably be
> The fix was easy: use a valid type name. In this case, use ByteFX.Data.
> On Thu, 2009-04-30 at 19:04 -0400, Scott Peterson wrote:
> > OK, ByteFX.Data is so old, it doesn't work anymore. It generates
> > invalid SQL. So we're back to MySql.Data.
> So what's the solution here?
> 1. Stick with using ByteFX.Data.
> Pro: It actually works with a default Mono install.
> Con: It apparently doesn't work.
> 2. Use MySql.Data types.
> Pro: Actually works.
> Con: Doesn't work with a default Mono install, as the needed assembly
> isn't present --> error messages on a default Mono install.
> 3. Remove the MySQL entry from sqlmetal.exe.config.
> Pro: Since the prior two don't actually work, at least we're being
> Con: No MySQL support. :-(
> (3) Might not be _terribly_ bad; it might be possible to specify the
> DbLinqConnectionType in the connection string, which would allow things
> to Just Work without using /provider parameter. (If /provider is
> required, then we should make /provider optional so that /conn can be
> used as a fallback.)
> So we have 3 bad solutions here; I'm not sure which is worst.
> - Jon
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list