Re: Bug or not about ASCII and Multi-Byte character set
От | Joel Fradkin |
---|---|
Тема | Re: Bug or not about ASCII and Multi-Byte character set |
Дата | |
Msg-id | 000e01c5a4bb$26f2c090$797ba8c0@jfradkin обсуждение исходный текст |
Ответ на | Re: Bug or not about ASCII and Multi-Byte character set (Marc Herbert <Marc.Herbert@emicnetworks.com>) |
Список | pgsql-odbc |
Looks like a lot of thoughts on this. I would just like to say (as one who had to convert their data) thank so much to every one who has worked so hard on the current driver. I understand if folks are upset because of change, but keep in mind this is an open source effort and my hat goes off to the accomplishment. The old driver may of handles aschii in a less imposing way, but it also did not work. Maybe one of those needing a plain aschii odbc driver that deals with encoding (or doesn't depending on the point of view) can make a version of the current driver that will allow the user to not need specify and give it a name like genericaschii or something (or add it as a connect string param?). I for one am very happy the work was done and seems to be working well. I did have a major error occur during my conversion (because of human error doing a backup restore at midnight), but it was still worth the end result. You can not expect everyone to agree (any change is always hard to accept). My users hate change even if it is more flexibility. I can agree it was a major hassle for me to have to deal with a change, but we have been told the driver functionality changed, if you want to use the driver on non aschii then make sure the data base reflects the proper coding. I provided examples of how to convert from one to the other, so bite the bullet and fix your issues. In the end having upper etc working will and should be the way you want it. Joel Fradkin
В списке pgsql-odbc по дате отправления: