Re: Migrating en_US.819 to en_US.utf8 in INFORMIX 10.00.FC4

Hi Anand, I would have expected that dbload would produce an error, when rows where not loaded, If it did you should include it in your post. Q. Do I have to define NVARCHAR ?" Are you using GL_USEGLU=1? if NO, the answer is no, there is no difference between VARCHAR and NVARCHAR for utf8 databases without this setting. if YES, the answer is still no, but you may change "only" the fields that contain data that you wish to sort using the 'unicode collation' Q. 819 database does have just pure English data set. I don't understand what this means, the following assumes that the data is "pure 819" for want of a better term. Q. However, I notice during dbload to utf8, some of the rows where where column(s) data are VARCHAR(...) Also remember that whatever type of (N)(VAR)CHAR field that you use the length of these strings are specified in bytes (not characters), and that as utf8 is a multi-byte encoding Strings in utf8 my be longer than the 819 strings. What settings of DB_LOCALE and CLIENT_LOCALE are used for load and unload. I recommend for unloading DB_LOCALE=CLIENT_LOCALE=en_us.819 and for loading DB_LOCALE=en_us.utf8 CLIENT_LOCALE=en_us.819 Gerry.

Thanks a lot Gerry: I know where was my mistabke after reading your suggestion, mistake was my CLIENT_LOCALE was also set at en_US.utf8 due to which dbload was not uploading certain data set. After I changed as per your suggestion of en_US.819, wolla, things are working. THANKS A MIL and this is truely NEW YEAR Gift. Rgds Chetan On Jan 3, 8:21 pm, gerry_cous...@hotmail.com wrote: > Hi Anand, > > I would have expected that dbload would produce an error, when rows > where not loaded, If it did you should include it in your post. > > Q. Do I have to define NVARCHAR ?" > > Are you using GL_USEGLU=1? > if NO, the answer is no, > there is no difference between VARCHAR and NVARCHAR forutf8 > databases without this setting. > > if YES, the answer is still no, but you may change "only" the > fields that contain data that you wish to sort using the 'unicode > collation' > > Q. 819 database does have just pure English data set. > > I don't understand what this means, the following assumes that the data > is "pure 819" for want of a better term. > > Q. However, I notice during dbload toutf8, some of the rows where > where column(s) data are VARCHAR(...) > > Also remember that whatever type of (N)(VAR)CHAR field that you use the > length of these strings are specified in bytes (not characters), and > that asutf8is a multi-byte encoding > Strings inutf8my be longer than the 819 strings. > > What settings of DB_LOCALE and CLIENT_LOCALE are used for load and > unload. > I recommend > for unloading > DB_LOCALE=CLIENT_LOCALE=en_us.819> and for loading > DB_LOCALE=en_us.utf8 > CLIENT_LOCALE=en_us.819> > Gerry.