Hi Przemek, >> 2009-12-06 19:59 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) >> * src/vm/set.c >> * src/rdd/dbcmd.c >> * include/set.ch >> * include/hbset.h >> + Added support for SET( _SET_DBCODEPAGE ). This will set the >> default codepage for RDD operation. It affects following >> functions and everything which is based on them: >> DBUSEAREA() >> DBCREATE() >> HB_DBCREATETEMP() >> __DBOPENSDF() > > This setting should be moved from above functions to hb_rddOpenTable(), > hb_rddCreateTable and hb_rddCreateTableTemp() or you should update > other code which should respect it. > Personally I prefer to moving it to above functions because in such > case it will work also for existing code without updating each function > which may call above functions directly or indirectly. > It will also fix few places in current core code which now do not > respect above setting yet, i.e. some versions of APPEND FROM / COPY TO. > I guess that you chose above functions because they set default value > for shared/exclusive mode using _SET_EXCLUSIVE but this set is used
No, I tried to locate "cCodePage", "cpid", such clues, but anyway thanks for above suggestion. It's not very easy job to find these extended parameters (one reason I call them "dirty"), and our docs is lacking. I'll try to make this modification, and I'd like to ask you to review it. > to control different things and I do not think it's necessary to > replicate the position of this set for other things. > >> IOW every function which accepts current "dirty" Harbour >> extension <cCodePage>. > > I do not see anything "dirty" in writing code like: > > USE table CODEPAGE "PLISO" I don't use commands (at all), so for me it looks like: dbCreate( a, s,,,,, "PLISO" ), etc. I don't have too many of these, but enough to allow for errors. > instead of: > > LOCAL cPrecCP > [...] > cPrevCP := Set( _SET_DBCODEPAGE, "PLISO" ) > USE table > Set( _SET_DBCODEPAGE, cPrevCP ) > > and for sure I will prefer the 1-st version against the second one. I call SET( _SET_DBCODEPAGE ) only _once_ in the app, since I use the same CP for all tables that belong to the database it handles. I assume this is quite a common layout in apps. I know Clipper doesn't know the notion of "database" (only tables), but such CP setting nevertheless belongs to the database and not to distinct tables in most cases. In case I need some tables in different CP, I can do the above trick or rather pass CP directly via "dirty" parameter. You know well why I call it dirty. Some other implementations may use these parameter positions for different things. We're not doing that sort of extension in whole Harbour except here. If possible, I prefer not to use it. Anyway, this is just the smaller issue here. >> This new SET() is useful if someone wants to use a different >> than app codepage in tables, without modifying every above >> calls to pass the db CP as extra parameter (plus maintaining >> this global setting in app code). > > With this I can agree and I think that in some cases it may be useful. > Anyhow all users should not forget that enabling any automatic code page > translation it's possible for tables containing text data only. Using > codepage translation for standard Clipper DBF tables used to store > binary data directly in table or in memo files will corrupt this data > so it should be used very carefully when user exactly knows what he > does and what it stored in used tables. Exactly. I had some fields encoded as binary data, and in last year I had cleaned all of them to use ASCII chars only. This was part of the CP migration move. Anyhow - and I don't know, but guess - that in Harbour we have some "binary" kind of field types, too, and these should not make any CP conversion, so it's still safe to store binary data in them, regardless of CP settings. (am I guessing right?) Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
