On Mon, 03 Nov 2008, Szak�ts Viktor wrote: Hi Viktor,
> Shouldn't we add a way to set the default > codepage for RDD operations? It will be very danger option. The online CP translations are not revertible and break binary data stored in DBF fields. If someone does not use binary data then it's safe but if we make it global (thread) option then it may cause unitnetional data corruption. > Right now I could pass it to each RDD function > call (like dbCreate()) but that needs touching > all such possible calls (which is error prone), > moreover using a "dirty" parameter extension. > Also, usually the RDD CP is global to an app's > database. I always set HVM codepage by HB_SETCODEPAGE() to my source code encoding which is also encoding of my database files and use CODEPAGE in RDD only when I want to import/export data with different then default encoding. > Right now I'm using hb_setcodepage(), but this > may not be enough given that it could depend on > UI/app language, so it may be bit different than > db cp (which is not ideal, but may happen). HVM codepage always have to be set if you want to have working <, >, <=, >= operators and it should be the same as your source code encoding if you have some literal strings with national characters. Then if you want to exchange data with any other external objects like database files, input/output system or other socket connections then you have to make necesary translations between HVM CP and forign CP. Now we added support for automatic translations to native RDDs and most of GT drivers (HB_SETTERMCP(), HB_SETDISPCP(), HB_SETKEYCP()). We do not have any support yet for file name translations. But please remember that these translations means different internal operations. In indexing RDDs it's also collation order not only character translation. DBF header has a field to store CP ID. It's enough for character translation but does not give any valuable information for national sorting so it's not usable for us. When application is executed the character fields have to be translated to HVM CP so later they can be compared using common rules. It's necessary to make SET FILTER and other operations working correctly. When HVM CP and table CP is the same then translation is skipped. The translation is usually not revertible so it's not safe to enable it for tables holding binary data in character fields. And to clarify. Using UNICODE does not resolve the problem. In some cases it even introduce new ones much harder to manage and resolve then in CP oriented applications. It helps in translations (as long as you do not touch binary data) but does not give anything for collation orders. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
