Hi Przemek,
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.
Per thread of course. I think this is very important.
Right now we have multiple different things controlled
by this one setting, and I have to risk an index corruption
if I want to make an UPPER() call using a different CP.
Or, the CP has to be saved/set/restored when such thing
occurs, or the program has to be modified to force CP on
table opening. At least if I'm not missing anything.
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.
This is good as long as your user don't want to switch
to a different UI language, and f.e. you want to use
an UPPER() call on a UI string. Or you have any other
program parts which temporarily needs a different CP.
If you mix those parts with db operations, this is real
trouble.
Most of these could IMO be solved with such defaulting
setting as 'hb_rddInfo( RDDI_CODEPAGE, "EN" )'.
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.
I see Unicode in a much brighter shade, but surely, not
everything is solved by it, but the more worrying thing
is that many devices, file formats (like .dbf) don't
support it (well), so you still need to convert.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
