A client is getting an "Error Code 1007: The row has been deleted since last cached for the table xxxxxx" while attempting to repair their database.

The repair is done via a script which iterates through all of the tables and repairs them one by one.  Normally this works fine.  In this case it's one particular table that is getting this error.

I have taken a copy of their database and get the same error.  

EDB Manager's repair option gets the same error. I can open the table in EDB Manager and see all of the data.

Could it be data corruption or something else?

Thanks.

= Steve

 

Steve


Never had that myself and reading the manual I have to say - how weird.

The only things I can think of to do is to export the data, empty the table and import it or reverse engineer the table with data drop the existing table and run the generated script

Roy Lambert

Steve

I did once have an error similar to this, sorry but it was years ago and I can't remember the details.

From memory I think I created a DummyTable with the same the form as the table with the error, then used EXPORT TABLE followed by IMPORT TABLE to pull the data into this.

The "re-imported table" did not exhibit the same issue.

--

Something I would also suggest is to track down the Temporary Folder for your EDB system, disconnect everyone from the database and then delete any files that are still in the temporary folder.

I have had times where these temp files have been holding locks on tables in the database which have caused issues.

Thanks Roy,

<< Never had that myself and reading the manual I have to say - how weird.

The only things I can think of to do is to export the data, empty the table and import it or reverse engineer the table with data drop the existing table and run the generated script >>

I just tried exporting the data but got the same error during export.  I don't think there is a reverse engineering option at the table level is there?

I tried reverse engineering the database but it gets the error message as well.

I'll keep playing around with it.  Maybe there's one row that's messing everything up.

= Steve

<< Something I would also suggest is to track down the Temporary Folder for your EDB system, disconnect everyone from the database and then delete any files that are still in the temporary folder.

I have had times where these temp files have been holding locks on tables in the database which have caused issues. >>

Thanks Adam, I'll give that a go.

= Steve

Steve

>I just tried exporting the data but got the same error during export. I don't think there is a reverse engineering option at the table level is there?

Sure is - open the database in EDBManager, open a new sql window drag table to blank sql window  - tell it you want the rows.

>I tried reverse engineering the database but it gets the error message as well.
>
>I'll keep playing around with it. Maybe there's one row that's messing everything up.

Does this table have BLOBs or CLOBs? I've had something similar with a table with CLOBs. Ultimately what I dis was a little Delphi program

1. copy table structure
2. oldtable.first
3. loop round old table with try except block copying data from oldtable to newtable
4. log any rows that threw an exception (at least you've something to investigate then)
5. dump oldtable rename newtable to oldtable


Roy Lambert

Steve,

<< A client is getting an "Error Code 1007: The row has been deleted since last cached for the table xxxxxx" while attempting to repair their database. >>

Can you email me the database catalog and the table files for the table that is having the issue ?  More than likely it's just something that the repair isn't trapping properly.

Tim Young
Elevate Software
www.elevatesoft.com

Hi Roy,

<< Sure is - open the database in EDBManager, open a new sql window drag table to blank sql window  - tell it you want the rows. >>

Well, well.  I didn't know you could do that.  Thank you for that.  Unfortunately it gets the same error but it's a handy thing to be able to do.

<< Does this table have BLOBs or CLOBs? I've had something similar with a table with CLOBs. Ultimately what I dis was a little Delphi program

1. copy table structure
2. oldtable.first
3. loop round old table with try except block copying data from oldtable to newtable
4. log any rows that threw an exception (at least you've something to investigate then)
5. dump oldtable rename newtable to oldtable >>

Yes it has BLOBs.  I'll give that a try.  Thanks again.

= Steve

<< Can you email me the database catalog and the table files for the table that is having the issue ?  More than likely it's just something that the repair isn't trapping properly.>>

Emailed to you.  Thanks Tim.

= Steve

Steve,

<< Emailed to you. >>

Thanks, this is now fixed.  I need to run it through the test framework first, however, before I can send you a fixed table.  There's some conditional handling in that area of the repair functionality that deals with BLOB row versions, which is where this issue is, and I need to make sure that I don't introduce a regression or have the repair introduce other issues with the row versions/BLOBs.

Tim Young
Elevate Software
www.elevatesoft.com