Jon, Just tought I'd mention it briefly: There is a little "issue" with Ingres' DbCommand.GetSchema() method in the original .NET Data provider. But as long as you still keep the old implementation in place, it should be fine.
I'm working on a spin-off from the original Ingres Data Provider (not the Linq plugin) that will have a proper GetSchema() implementation. Thomas On Nov 13, 2:40 pm, Jonathan Pryor <[email protected]> wrote: > I know virtually nothing about MySQL or the DbLinq.MySql provider. That > said... > > 1. I find this "interesting" (worrying?) in > src/DbLinq.MySql/MySqlChemaLoader.cs: > > protected string ParseDbType(string columnName, string dbType1) > { > //strip 'CHARSET latin1' from the end > string dbType2 = re_CHARSET.Replace(dbType1, ""); > var dataType = new DataType(); > dataType.UnpackRawDbType(dbType2); > return MapDbType(columnName, dataType).ToString(); > } > > Specifically the "strip 'CHARSET latin1' from the end" comment -- this > looks like it's stripping & ignoring character set information, which > seems...odd. > > This may mean nothing; I have no idea. > > 2. The entire thing *may* become moot. I'm currently working on > "improving" DbMetal to optionally use DbConnection.GetSchema() to get > database schema information (tables, columns, types, etc.) instead of > the mass of custom DB-specific SQL code and perpetually out-of-date type > mapping code that is currently used. (There have been two messages in > the last week about DbMetal not knowing how to translate a given SQL > type into a corresponding managed type; this is stuff that the ADO.NET > provider CAN and SHOULD be doing.) > > I'm hoping to have something suitable to commit by early next week; > perhaps you can look into migrating MySQL to that infrastructure and see > if it improves things? > > Thanks, > - Jon > > On Thu, 2009-11-12 at 14:51 -0800, Jim wrote: > > I'm running Dblinq against a Mysql 5.0 database, and used dbmetal to > > generate the wrapping class to the database. The database tables were > > created with default charset=utf8, however the strings being returned > > from varchar columns are being encoded with the latin1 (cp1252) > > encoding a opposed to utf8, so byte sequences such as 0xe2, 0x80, 0x99 > > are showing up as ’ instead of the right single quotation mark ’ . > > I've updated all the character set variables I'm aware of in MySql to > > utf8. The database itself was created with latin1 as the character > > set, but as I mentioned above, the tables themselves were created with > > default charset utf8. > > > mysql> SHOW VARIABLES LIKE '%character_set%'; > > +--------------------------+------------------- > > | Variable_name | Value > > +--------------------------+------------------- > > | character_set_client | utf8 > > | character_set_connection | utf8 > > | character_set_database | latin1 > > | character_set_results | utf8 > > | character_set_server | utf8 > > | character_set_system | utf8 > > > I'm working around the issue for now by re-encoding the strings as > > follows: > > > string sEncValue = Encoding.UTF8.GetString(Encoding.GetEncoding > > (1252).GetBytes(sOrigValue)); > > > but am wondering if there's a better, more basic solution (perhaps > > some configuration I haven't done). > > > -- > > > You received this message because you are subscribed to the Google Groups > > "DbLinq" group. > > To post to this group, send email to [email protected]. > > For more options, visit this group > > athttp://groups.google.com/group/dblinq?hl=. -- You received this message because you are subscribed to the Google Groups "DbLinq" group. To post to this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/dblinq?hl=.
