MySql client char encoding AT DESIGN TIME

Posts   
 
    
Posts: 5
Joined: 27-Nov-2009
# Posted on: 27-Nov-2009 13:11:49   

Hi,

I use 2.6 Demo final, with devart dotConnect 5.40. I connect to a MySql 5.0 server with all default char encoding paramters set to utf8. => character set client utf8 character set connection utf8 character set database utf8 character set filesystem binary character set results utf8 character set server utf8 character set system utf8 character sets dir /usr/share/mysql/charsets/ collation connection utf8_unicode_ci (Valeur globale) utf8_general_ci collation database utf8_general_ci collation server utf8_general_ci <=

I use a catalog where some of the tables and fieldnames use non ascii characters, like 'é' or 'à' (I know this is probably not a good idea but that's legacy I have to deal with).

At runtime, I can put "Unicode=true" in the conection string and it works well.

The thing is here I need to do it at design time to prevent llblgen to put garbage chars in my tables and fields names.

How can I do that? I didn't find a place where I could customize the connection string that is used at design time.

Regards.

Manuel

daelmo avatar
daelmo
Support Team
Posts: 8245
Joined: 28-Nov-2005
# Posted on: 27-Nov-2009 19:02:28   

Hi Manuel,

This is indeed an edge case. I can reproduce it, and no, there is no an option to manually change this in LLBLGen Pro Designer. As I see, your options are:

  1. Change the names manually.

  2. Create a plugin to change all names at once.

  3. Download the drivers source code and change a little bit the MySql connection string construction. If you see it now, it is something like:

connectionString.AppendFormat("Server={0};Database={1};User ID={2};Password={3};"

you can change it by this:

connectionString.AppendFormat("Server={0};Database={1};User ID={2};Password={3};Unicode=true;"

For option 3 you need to be a customer to download the drivers sourcode (in LLBLGen Pro SDK download).

David Elizondo | LLBLGen Support Team
Otis avatar
Otis
LLBLGen Pro Team
Posts: 39908
Joined: 17-Aug-2003
# Posted on: 28-Nov-2009 12:00:21   

We'll look into adding a setting for this and will get back to you with a new build of the mysql driver, (likely on monday).

Frans Bouma | Lead developer LLBLGen Pro
Posts: 5
Joined: 27-Nov-2009
# Posted on: 28-Nov-2009 17:13:19   

Thank you guys, maybe you could introduce a textbox to let the user insert custom parameters in the connexion string, whatever the driver is.

Anyway it's always a good point to see some reactive team at work. We will really consider llblgen for our project, and we are looking forward to see v3.

For your information the best alternative we are also evaluating is Ideablade DevForce. Of course, the pricing is not the same and DevForce seems generally to be more heavy weighted.

Best regards.

Manuel

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39908
Joined: 17-Aug-2003
# Posted on: 30-Nov-2009 12:50:12   

multimediapress wrote:

Thank you guys, maybe you could introduce a textbox to let the user insert custom parameters in the connexion string, whatever the driver is.

As Corelab's driver only allows unicode specification and not specific charsets, we added a checkbox. Please copy the attached dll into the <llblgen pro installation folder>\Drivers\MySql folder and try again. It should show a Use unicode checkbox, which if checked will append "Unicode=true;" to the connectionstring used. This should solve your problem.

Anyway it's always a good point to see some reactive team at work. We will really consider llblgen for our project, and we are looking forward to see v3.

cool! simple_smile Yes, we consider support part of the overall quality of the product so we're keen on giving the best support we can

For your information the best alternative we are also evaluating is Ideablade DevForce. Of course, the pricing is not the same and DevForce seems generally to be more heavy weighted. Best regards. Manuel

I don't really see what the added value is of DevForce considering they're using entity framework and so you're paying for code on top of EF, but why that has to cost that much money is beyond me (as it's IMHO not that special at all)

Frans Bouma | Lead developer LLBLGen Pro
Posts: 5
Joined: 27-Nov-2009
# Posted on: 30-Nov-2009 18:13:27   

Hi,

It works. Great support!

Regarding DevForce we are just in the early stages of the evaluation yet (mainly on paper specs). What attracted us to it is how the n-tier model seems to be handled (poorly connected/disconnected client managment, ability to do rich query against the cache on the client). However, we are new to O/RM problematic so it's likely that we are misundestanding some aspects or misevaluating the respective impact of those aspects.

Regards.

Manuel

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39908
Joined: 17-Aug-2003
# Posted on: 01-Dec-2009 10:55:20   

multimediapress wrote:

Hi,

It works. Great support!

great! simple_smile

Regarding DevForce we are just in the early stages of the evaluation yet (mainly on paper specs). What attracted us to it is how the n-tier model seems to be handled (poorly connected/disconnected client managment, ability to do rich query against the cache on the client). However, we are new to O/RM problematic so it's likely that we are misundestanding some aspects or misevaluating the respective impact of those aspects.

that's indeed a big problem but it has a wide range of 'solutions' which all are not really great. The biggest problem you've to solve is 'what is my 'truth', the real data?'. Because if Client A modifies data locally and client B who has connection to the service, alters the same data centrally, what happens when A wants to sync the changes? This might sound easy to solve, till you realize that A might have made other changes based on the changes made earlier, which make it very difficult to reject A's earlier changes, so B's changes are overwritten, otherwise all changes made by A locally can be tossed away.

Sometimes this is solved by a local database which is then synced using synchronization services, e.g. locally a SqlCE database is used and centrally a normal sqlserver database. You can achieve that with Adapter and our system. You're using mysql, so you can use a local mysql database, and switch between which system to use by switching the connection string for example, however you still have to sync the data, which is the cumbersome part. I'm not sure if devforce has solved this properly, as there is no real solution to this: they all suck in one way or the other as syncing offline data with online databases always requires the removal of some changes made already.

Frans Bouma | Lead developer LLBLGen Pro