Encoding for cross-Platform DB with V4RB 1.x

[Frank Bitterlich]

Okay, now it gets funny.

The problem is not the Encoding itself; the problem is one field.

If I search in field "ZUNAME" using non-ASCII characters, it works.  
If I search in "ADRESSE", it doesn't. "ZUNAME" is VarChar[30], and  
ADRESSE is VarChar[99]. Both are indexed. Same table. ADRESSE is the  
last field in that table.

Could this be a bug? I have re-created the database numerous times,  
same result. Happens on Windows only. Using V4RB 1.11.

Any ideas? Ruslan?

Thanks,
    Frank+++


Am 05.09.2005 um 16:57 schrieb Frank Bitterlich:

> Hi Thierry,
>
> thanks for the answer. Unfortunately, the part I'm having problems  
> with is the SQLSelect.
>
> Try this (in a DB populated with MacRoman data):
>
>
>>   curseur=db.SQLSelect( enCode("SELECT valeur FROM prefs WHERE nom  
>> ='déjà vú'"), ..., ..., ... )
>>
>
> (Sorry if I got the accents wrong :)
>
> On the Mac, it works. On Windows, it doesn't; regardless if I use  
> WindowsLatin1, MacRoman, or UTF-8 as the encoding for the SQLSelect 
> () statement. If I do a "select * from ...", I get the correct  
> results (Valentina even converts it to UTF8 or WindowsLatin1 for  
> me, even though I have added the data as MacRoman).
>
> So the real question is: Which Encoding to use for the SQLSelect()  
> statement on Windows, when the database was created on the Mac?
>
> And: has the "inNativeOS" argument of the VDatabase.Create()  
> statement something to do with this?
>
> BTW, I think you can omit the "#if TargetWin..." clause if you just  
> use Encodingss.SystemDefault (which is MacRoman on the Mac and  
> WindowsLatin1 on Win32).
...
-- 

Günter Schmidt & Co. oHG
Frank Bitterlich             eMail: bitterlich at gsco.de
Schlosserstr. 4              WWW:   http://www.gsco.de/
D-60322 Frankfurt            Tel.:  069 / 156809-29
GERMANY                      Fax:   069 / 156809-28