Hi. I'm writing a program to copy records from an dbf table to an elevatedb table. This is
the part of the program that has the problem:

       Tabla.FieldDefs.Update;
       while not Tabla.Eof  do begin
         TablaEd.Append;
         for g:=0 to Tabla.FieldDefs.Count -1 do begin
           try
TablaEd.fieldbyname(Tabla.FieldDefs[g].Name).AsString:=Tabla.fieldbyname(Tabla.FieldDefs[g].Name).AsString;
           except
           end;
         end;
         TablaEd.Post;
         Tabla.Next;
       end;

Tabla=Dbf table
TablaEd=ElevateDB table

the program run well but after four or five tables in a record of the middle of a table
show me the error:

ElevateDB Error #601 The table PROVEEDORES is corrupt (Invalid row number specified for
retrieval from cache)

The table PROVEEDORES is good and it has been traspased previously. At the moment of the
error the table is another one.

Sorry my "spanglish".

Thank you very muth

Francisco,

I don't know if this is the case, but if you just want to copy all the
records from dbf tables, without changes, to EDB tables you can use the
"BDE Migrator" included in ElevateDB.

Anyway, if this is not the case and you really need to write your own
conversion program, I have some previous questions:
- What EDB version are you using?
- You are using ".asstring" to read all fields.
  Are they all of some "character" type?


--
Fernando Dias
[Team Elevate]

Hi Fernando.

I'm using elevatedb 2.0 and i'm ussing .asstring for all fields but all fields are not
"character" type, there are currency, character and date types.

Francisco

>I'm using elevatedb 2.0 and i'm ussing .asstring for all fields but all fields are not
>"character" type, there are currency, character and date types.

I saw that, (personally I'd use .Assign) but I'm doubtful it can be the problem.

Re-reading your post it seems that a number of tables are processed correctly and then you have this error.  So is it always the same table being processed when the error occurs?

I also think you'd be better off altering your procedure to something like:

       Tabla.FieldDefs.Update;
OK:=True;
       while not Tabla.Eof  do begin
         TablaEd.Append;
         for g:=0 to Tabla.FieldDefs.Count -1 do begin
           try
TablaEd.fieldbyname(Tabla.FieldDefs[g].Name).AsString:=Tabla.fieldbyname(Tabla.FieldDefs[g].Name).AsString;
           except
OK := False;
           end;
         end;
if OK then          TablaEd.Post else begin
TablaEd.Cancel;
report the problem here - possibly write to a log file or showmessage
end;
         Tabla.Next;
       end;

That way if it's the conversion from/to a string that's screwing the table it will be eliminated.

Roy Lambert [Team Elevate]

Francisco,

<< the program run well but after four or five tables in a record of the
middle of a table show me the error: >>

Can you send me the source DBF table and target EDB table that is causing
this error ? (timyoung@elevatesoft.com)

Thanks,

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

<< That way if it's the conversion from/to a string that's screwing the
table it will be eliminated. >>

There really shouldn't be any way that an AsString assignment could corrupt
a table.  It's most likely something weird, like when we had an issue with
..NET whereby the Boolean value had a different binary representation (255
instead of 1 for True).

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

> I saw that, (personally I'd use .Assign) but I'm doubtful it can be the problem.

I didn't think it was the cause for the problem, too.
However, if you want to preserve NULL values you can't use .asstring, or
all NULLs in source character columns will be copied as non-null empty
strings to the target table

--
Fernando Dias
[Team Elevate]

Solved!!!

I forgot the triggers associated with the table and they don't must work in the migrate
process.

Sorry for the inconveniences and thank you for all.

Fernando

>I didn't think it was the cause for the problem, too.
>However, if you want to preserve NULL values you can't use .asstring, or
>all NULLs in source character columns will be copied as non-null empty
>strings to the target table

Please wash your mouth out, or better still slice your head off

Roy Lambert [Team Elevate]

Francisco,

<< I forgot the triggers associated with the table and they don't must work
in the migrate process. >>

Triggers shouldn't cause any corruption issues.  What were the triggers
doing that was causing this issue ?  It might be a bug.

--
Tim Young
Elevate Software
www.elevatesoft.com