[V4RB] -39 Error

[Francois Van Lerberghe]

le 20-05-03 11:08, Ruslan Zasukhin <sunshine at public.kherson.ua> a écrit :

> on 5/20/03 11:35 AM, Francois Van Lerberghe at fvanlerberghe at freegates.be
> wrote:
> 
> Hi Francois,
> 
>> I have this error too when I have a db created/used in Windows OS and I open
>> it in MacOs. The inverse is the same. This doesn't happen before I modify
>> the DB structure.
> 
> What you mean "modify DB Structure"?
> For newer version of your app?

Yes

> 
> Is DB created for FIRST version of your app ?

Yes

> 
> Or this problem happen for FRESH db created by your App 2.0 ?

No

> Then you should be able reproduce it for me.

I can send the db to you. If you try to open in the other platform, you'll
see the corrupted table. But using it in the same platform work OK.
Export/import fix the problem, but transfer again in other OS and you see
the problem again.

> 
>> This error is related to the corruption of some String fields (containing
>> bugged values : strange characters displayed in VAPP). Fortunately, This
>> happen in only one table that have only one record.
> 
> I think for VarChar fields. String field practically cannot be corrupted.

These was String fields. No VarChar in this table.
Is it possible that the structure update has made some offset that perhaps
is not the same in Win32 and in MacOS ?
The structure update was this one :
I have decreased the length of 2 String fields (3 -> 2) in 2 tables (one
field in each table). These table was not the same as the "corrupted" table.

> 
>> To solve this, I have to :
>> - open the DB on the first OS
>> - export the record in text format on the first OS
>> - open the DB in the second OS
>> (doing a SQL select raise error -39)
>> - delete all record from this corrupted  table (one record in this case)
>> - import the file previously saved on the first OS
>> 
>> Note that for successfully open my DB in both OS,
>> - I have to transfer only the ".blb" and ".dat" files. The ".ind" must be
>> rebuild and the".vdb" must be generated in the target OS because of method
>> fields containing ASCII > 127 (due to fields name having ASCII > 127)
>> - Now (after the structure modification), I must do the export/import trick
>> at each transfer.
>> :=(
> 
> I think you have made some mistake.

my code is :

  newLength = 2
  myStringFld.maxLength = newLength

This seems to work well. No error raised

> You use RB?

Yes, RB 3.5.2

> 
> IT looks you describe 2 problems.
> 
> 1) BaseObject method with chars > 127 is not portable?

No

> why this characters here?

I have normal (not virtual) fields name with chars > 127. I have done this
because, unfortunately, I ignored the problem at the design time and I
haven't time now to change this.
These fields name are portable ("correctly translated"). But If I use one in
method, the chars are incorrect when I go to the other OS

Cheers

François Van Lerberghe
Thier Monty, 15A
B-4570 Marchin
Belgique