Hi Przemek,
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
I think that you still do not understand that _THEY_ always
will be controlled by this setting and you will only introduce
additional risk for data corruption by enabling unintentional
translation.
Hm, I mean the RDD to be a different setting obviously.
One CP for HVM, one CP for RDD.
So this (BTW):
hb_setrddcp( "HU" )
hb_sethvmcp( "SK" )
dbAppend() ; FIELD->NAME := "á" // will be put in HU order
? Upper( "<slovak lower case char>" ) // -> <slovak uppercase char>
I suppose there already must be some sort of logic to
achieve this, as dbUseArea() has a CP parameter already.
All I'm trying to say, is that it would be useful to have
a setting controlling the _default_ of this parameter.
According to what you say, this parameter is pointless
and/or dangerous. So I'm not sure why we have it there, then.
(well, this I'm not sure anyway, since being a dirty extension,
but that's a different story).
if I want to make an UPPER() call using a different CP.
Nothing will be changed by adding default RDD CP because
all expressions will be still evaluated with HVM CP. You
will only enable possibly danger translation.
Okay, we'd need a HVM CP context then, which we already
have AFAIK.
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.
You missed the most important thing that all expressions
have to be executed using current HVM CP because they can
use data with national characters or call UDFs which uses
data with national characters or even compare data with
different WAs which uses internally different encoding
and need to be unified before comparison. The CODEPAGE
clause makes only one thing here. It enables automatic translation
between HVM and table encoding when field is accessed/assign.
It can be used only between the same languages using the
same collation rules and only different encoding.
Then what controls the behavior of UPPER() for example?
(in my tests it was hb_setcodepage())
BTW I understand the problem of index callbacks, but HVM/RDD
should make sure to execute these in the RDDs CP context.
If what you say is true, it's not possible to write a
multi language program, unless the language (CP) is fixed
at install time once and for all for both the UI and
the RDD (but lets forget about the high level problem).
Maybe I'm not seeing all the details that comes with it,
especially when it comes to implementation details, but
there must be some ways to ask Harbour to uppercase me a
simple string according to CP 'n', while using CP 'm'
for the RDDs.
In particular I don't understand why can we do this:
---
hb_setcodepage( "CP_ZZ" )
dbUseArea( ..., "CP_XX" )
dbUseArea( ..., "CP_XX" )
---
But we cannot do this:
---
hb_setcodepage( "CP_ZZ" )
hb_dbcodepage( "CP_XX" )
dbUseArea( ... )
dbUseArea( ... )
---
Set and restore HVM CP only for this operation and be sure
that other code will not be executed inside.
But it has nothing to default RDD CP. You will still have
the same problem.
That's exactly what I'd expect from the RDD, done automatically.
And the <codepage> option in dbUseArea() (and friends)
suggest this is already implemented.
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" )'.
It will not be solved.
In the moment when you are changing HVM CP you are changing
the behavior of string comparison operations what will effect
all existing RDD expressions when they will be evaluated.
Default RDD CP does not change anything here.
You probably didn't understand me, I'm afraid, probably I
wasn't clear, or I'm missing something. Anyhow, I can continue
to use my own CP system and string manipulation, which solves
to problem adequately.
BTW, such similar 'CP context' methodology is implemented
in C#, where certain functions can have such a context
passed as an option, plus there are probably ways to control
the defaults, too, but don't ask me about the precise
details.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
