Hi Tim,

It's been a long time

Unfortunately, this is fairly urgent.

One of my olf customers running program based on dbisam 3.24 had
a power outage and then they run database repair and continued
working - after awhile they started noticing strange things
and corrupt records. They asked me to see what's up with
the database and it appears that no matter how many times I
run repair (including force rebuild indexes) it still reports
verification errors like this.

--------
Verification of table Itemlocs started at 5/12/2009 11:33:35 PM...
Indexes do not match record data and are invalid...
Verification of table Itemlocs completed at 5/12/2009 11:33:36 PM...

Verification of table Receipts started at 5/12/2009 11:33:39 PM...
Logical record ID for physical record # 89 is invalid...
Indexes do not match record data and are invalid...
Verification of table Receipts completed at 5/12/2009 11:33:39 PM...
--------

What should we do to fix this? They don't have a good backup -
since they were not aware of corruption and continued using the
software for a long time after corruption occur. Would you be
able to take a quick look at these table (they are not too large)
- it doesn't have to be free of charge, I'd gladly pay you if you
could fix it.

Thanks in advance!

Michael

Michael

I know Tim does not like this kind of support but if you could recreate the
indexes from scratch then I will delete the IDX file and create them again.

1) Delete the indexes files (*.idx)
2) Repair the tables
3) Recreate the indexes

Eduardo

Eduardo,

> 1) Delete the indexes files (*.idx)
> 2) Repair the tables
Deleted idx file, repaired - same verification error.

This does not help, alas.
--
Verification of table Timerep started at 5/13/2009 12:23:51 AM...
Indexes do not match record data and are invalid...
Verification of table Timerep completed at 5/13/2009 12:23:51 AM...
--

Sincerely,
Michael

"Michael Baytalsky" <mike@contextsoft.com> wrote in message
news:2330E147-EBC5-48F3-8B9C-41E21899AA21@news.elevatesoft.com...

Hi Michael  if new indexes did not fix it can you export the table to
CSV and make a new table and re-import. Dont go deleting things
indexes or tables just keep them isolated untill its sorted.
I bet someone has downloaded another DBsys and screwed up the
headers or somthin. They will never tell you tho.
Rita

Rita,

> Hi Michael  if new indexes did not fix it can you export the table to
> CSV and make a new table and re-import. Dont go deleting things
> indexes or tables just keep them isolated untill its sorted.
> I bet someone has downloaded another DBsys and screwed up the
> headers or somthin. They will never tell you tho.
Thanks, that's what I'm intending to do, however it's hard to tell
what's missing in a file with a corrupt data - unfortunately, it's not
the header, it's the data portion which is corrupt. I thought if
there's a chance Tim could take a look into it maybe he has a better
DAT parser, which could isolate those broken records (maybe just a few)
- my concern is one corrupt record may lead to loosing the whole
next page of data or something.

Sincerely,
Michael

In the 1980's my uncle was a great trade unionist.
He had all the Union dBase entries or edits sent
to a CSV with the days date it all went to another
pc on the lan. Then in maggie thatchers day the
office was broken into the files got wiped.
Myself and 20 other's rebuilt all them tables. 640k
was the limit then and a lot of daily business was
near that limit. I loved my uncle poor guy died to
young tho fighting for workers rights.
Good luck I hope u sort it.
Rita


"Michael Baytalsky" <mike@contextsoft.com> wrote in message
news:0E6B73ED-83C1-4699-9E45-3137BC4F0712@news.elevatesoft.com...
> Rita,
>
>> Hi Michael  if new indexes did not fix it can you export the table to
>> CSV and make a new table and re-import. Dont go deleting things
>> indexes or tables just keep them isolated untill its sorted.
>> I bet someone has downloaded another DBsys and screwed up the
>> headers or somthin. They will never tell you tho.
> Thanks, that's what I'm intending to do, however it's hard to tell
> what's missing in a file with a corrupt data - unfortunately, it's not
> the header, it's the data portion which is corrupt. I thought if
> there's a chance Tim could take a look into it maybe he has a better
> DAT parser, which could isolate those broken records (maybe just a few)
> - my concern is one corrupt record may lead to loosing the whole
> next page of data or something.
>
> Sincerely,
> Michael

Michael,

<< One of my olf customers running program based on dbisam 3.24 had a power
outage and then they run database repair and continued working - after
awhile they started noticing strange things and corrupt records. They asked
me to see what's up with
> the database and it appears that no matter how many times I run repair
> (including force rebuild indexes) it still reports verification errors
> like this. >>

Sure, just make sure that you have a current support plan and email me the
table(s).  I can make sure that they are at least structurally sound after
I'm done with them, but I can't guarantee that all of the data can be
recovered.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

> Sure, just make sure that you have a current support plan and email me the
> table(s).
Nope, I don't think we do. This is new, but it sure makes sense.

> I can make sure that they are at least structurally sound after
> I'm done with them, but I can't guarantee that all of the data can be
> recovered.
Thanks. Meanwhile, I have manually exported what seemed to be a valid subset of
data into new tables and then recreated all necessary indexes. It seems like the
loss of data is minimal somehow (still not sure, keeping fingers crossed),
probably because  most corruption occurred during checkdisk  and not caused by
dbisam itself (DAT files contained blocks of random data). We will do more
testing and if we find that the there's something I'm missing, I will then have
to renew support contract and ask for your help again.

Thanks,

Michael

Michael,

<< Nope, I don't think we do. This is new, but it sure makes sense. >>

If it were just a support question/issue, then we normally are less strict
about the support plan.  But with data recovery we have to be a little
strict due to the fact that it can sometimes take quite a bit of work to
recover the tables.

<< Thanks. Meanwhile, I have manually exported what seemed to be a valid
subset of data into new tables and then recreated all necessary indexes. It
seems like the loss of data is minimal somehow (still not sure, keeping
fingers crossed), probably because  most corruption occurred during
checkdisk  and not caused by dbisam itself (DAT files contained blocks of
random data). We will do more testing and if we find that the there's
something I'm missing, I will then have to renew support contract and ask
for your help again. >>

No problem.  Just let me know if you need any further help with this.

--
Tim Young
Elevate Software
www.elevatesoft.com