Hi,

I've got an export/import utility that has been running for years - specific for one customer, and runs in an overnight batch file.

Since upgrading to 4.30b5 (and admittedly making a few changes as well) it ends up with a corrupted index on the newly created export table, but doesn't report any errors during this stage.

Running a repair in dbsys reports:
Repair of table Invm_011 started at 23/06/2011 9:31:29 p.m....
Indexes do not match record data and are invalid, starting to fix indexes...
Invalid indexes fixed...
Repair of table Invm_011 completed at 23/06/2011 9:31:29 p.m....

The code that appends the records looks like this:
     with tbExport do begin
       Append;
       FieldByName('sku').asString := sku;
       FieldByName('descr').asString := tbStock.FieldByName('descr').asString;
       FieldByName('suppcode').asString := tbStock.FieldByName('suppcode').asString;
       FieldByName('grade').asString := tbStock.FieldByName('grade').asString;
       FieldByName('dept').asString := strDept;
...
       Post;


It is a bit hard to reduce this to a sample application for submission, so I thought I'd ask if anyone has any general ideas to start with?

Using D2007 on Win XP Pro SP2

Thanks,
Steve

Further on this problem:

The table has a single primary key index on the string field SKU.

If I stop the export prior to about 4000 records it is not corrupted. Anything over that it gets corrupted.

Another function which reads this file back one record at a time, just freezes when it strikes the corruption. I have to reset the application from within the IDE.





Stephen Barker wrote:

Hi,

I've got an export/import utility that has been running for years - specific for one customer, and runs in an overnight batch file.

Since upgrading to 4.30b5 (and admittedly making a few changes as well) it ends up with a corrupted index on the newly created export table, but doesn't report any errors during this stage.

Running a repair in dbsys reports:
Repair of table Invm_011 started at 23/06/2011 9:31:29 p.m....
Indexes do not match record data and are invalid, starting to fix indexes...
Invalid indexes fixed...
Repair of table Invm_011 completed at 23/06/2011 9:31:29 p.m....

The code that appends the records looks like this:
     with tbExport do begin
       Append;
       FieldByName('sku').asString := sku;
       FieldByName('descr').asString := tbStock.FieldByName('descr').asString;
       FieldByName('suppcode').asString := tbStock.FieldByName('suppcode').asString;
       FieldByName('grade').asString := tbStock.FieldByName('grade').asString;
       FieldByName('dept').asString := strDept;
...
       Post;


It is a bit hard to reduce this to a sample application for submission, so I thought I'd ask if anyone has any general ideas to start with?

Using D2007 on Win XP Pro SP2

Thanks,
Steve

Hi, Stephen...

I have similar problems with indexes related to string fields and using 4.30
Build 5.
Read my previous post and tell me if you are experiencing something similar.





"Stephen Barker" escribió en el mensaje de
noticias:87A63310-9DAC-48EF-ADD8-F48097CF3157@news.elevatesoft.com...

Further on this problem:

The table has a single primary key index on the string field SKU.

If I stop the export prior to about 4000 records it is not corrupted.
Anything over that it gets corrupted.

Another function which reads this file back one record at a time, just
freezes when it strikes the corruption. I have to reset the application from
within the IDE.





Stephen Barker wrote:

Hi,

I've got an export/import utility that has been running for years - specific
for one customer, and runs in an overnight batch file.

Since upgrading to 4.30b5 (and admittedly making a few changes as well) it
ends up with a corrupted index on the newly created export table, but
doesn't report any errors during this stage.

Running a repair in dbsys reports:
Repair of table Invm_011 started at 23/06/2011 9:31:29 p.m....
Indexes do not match record data and are invalid, starting to fix indexes...
Invalid indexes fixed...
Repair of table Invm_011 completed at 23/06/2011 9:31:29 p.m....

The code that appends the records looks like this:
     with tbExport do begin
       Append;
       FieldByName('sku').asString := sku;
       FieldByName('descr').asString :=
tbStock.FieldByName('descr').asString;
       FieldByName('suppcode').asString :=
tbStock.FieldByName('suppcode').asString;
       FieldByName('grade').asString :=
tbStock.FieldByName('grade').asString;
       FieldByName('dept').asString := strDept;
...
       Post;


It is a bit hard to reduce this to a sample application for submission, so I
thought I'd ask if anyone has any general ideas to start with?

Using D2007 on Win XP Pro SP2

Thanks,
Steve

Stephen


There is another thread similar but different

Dave Sellers
#8963 BLOB block buffers corrupt
942FDE45-6E8C-4364-B45E-CB1F2C6CC827@news.elevatesoft.com

which may be relevant

The main thing I can suggest is adding a call to flushbuffers after post (maybe every 10th record or so).

Other problems could be an updated AV, your code and DBISAM, probably in that order. If its running over a network you can also suspect the network hardware.

If you don't get the corruption if you stop it before record 4000 what happens if you stop, close tables, reopen and continue every 3000 records?

Roy Lambert [Team Elevate]

"Luis Conception Gonzalez" wrote:

Hi, Stephen...

I have similar problems with indexes related to string fields and using 4.30
Build 5.
Read my previous post and tell me if you are experiencing something similar.
---------------

Hi Luis,
Yes it does sound the same. In my case the exported table gets created ok, but when I verify it in dbsys it detects the corruption.
I'm trying to make a new project to demonstrate the problem using some random data.
Steve

Hi,

If you already tried repairing tables, rebuilding indexes, etc and you are still having issues you should send a report to Tim along with a table.

--
Fernando Dias
[Team Elevate]

Fernando Dias wrote:

Hi,

If you already tried repairing tables, rebuilding indexes, etc and you are still having issues you should send a report to Tim along with a table.

--
Fernando Dias
[Team Elevate]

Hi Fernando,
My table is getting recreated each time. A second function that reads the table is freezing when it hits the corruption.
I have tried making a small test application and inserting random data but I can't get the corruption to appear in this. I'll continue trying to isolate a test case. Is it still worth sending one of the corrupt tables?
Steve

Steve,

You will have to ask Tim, but I think so.

--
Fernando Dias
[Team Elevate]

<Stephen Barker> wrote in message
news:7FB163F7-9A1B-4A9C-873A-D360BF502466@news.elevatesoft.com...
> My table is getting recreated each time. A second function that reads the
> table is freezing when it hits the corruption.
> I have tried making a small test application and inserting random data but
> I can't get the corruption to appear in this. I'll continue trying to
> isolate a test case. Is it still worth sending one of the corrupt tables?
> Steve
>

tell us a bit about this second function. or anybody else that might be
accessing the table. look for the non-obvious in your aplication. is some
thread mucking with the table? somebody starting and ending transactions
while the table is being updated?

robert

"Robert K" <ngsemail2005withoutthis@yahoo.com.ar> wrote in message
news:94108052-63EE-4FC7-9F6B-A93AA305B835@news.elevatesoft.com...
>
> <Stephen Barker> wrote in message
> news:7FB163F7-9A1B-4A9C-873A-D360BF502466@news.elevatesoft.com...
>> My table is getting recreated each time. A second function that reads the
>> table is freezing when it hits the corruption.
>> I have tried making a small test application and inserting random data
>> but I can't get the corruption to appear in this. I'll continue trying to
>> isolate a test case. Is it still worth sending one of the corrupt tables?
>> Steve
>>
>
> tell us a bit about this second function. or anybody else that might be
> accessing the table. look for the non-obvious in your aplication. is some
> thread mucking with the table? somebody starting and ending transactions
> while the table is being updated?
>

Some logic changing the index?

r