Table repair with TUtility - a waste of time? 
Author Message
 Table repair with TUtility - a waste of time?

The other day I got into troubles with some corrupted tables, and decided to
find out how well Borland's TUtility works. I understand it's a DLL from
Borland, around which several people have built useful interfaces. I use the
Pack program from Zhang Xiaolong, which is nice, but there are others as well,
and one can easily write the needed code at home if decided.

Anyway, this DLL offers functions to check a table for problems as well as to
rebuild it. And here is my experience with it (assumed Pack it just a wrapper
for it):

- Tables that are corrupted, will usually be declared to be all right
- Tables that are fine, at least they seem fine, will be declared bad
- Some of those declared bad tables, will still be declared bad even after
several "successful" rebuilds.

Details:
I have for some reason gotten terrible problems with "corrupt index" lately.
It is not even possible to run index rebuild (dbiRebuildIndexes?), or, in some
cases, index rebuild runs but does not help.
Still the TUtility check says the tables are OK!

While in another case of mine, with a post number table, TUtility keeps
telling that the table is bad and needs rebuild. I let it rebuild, it says the
rebuild was successful, I run the check again, and guess what? Still bad,
needs rebuild....and so on, over and over. The table looks fine to me though,
although I haven't got time to check every single record.

In other cases it declares a table "bad" when I think it is good - e.g. when
the table has only one record and that record seems to be all right. It
corrects the claimed error and afterwards declares the table "good". Is it me
that does not understand when something is wrong with my tables? Poor tables.

What will be others' experience with table check and repair? From my (limited)
experience, it seems not to work at all. I know it is not always supposed to
solve one's problems, but it hasn't actually helped me, I think, a single tiny
bit yet.




Sat, 29 May 1999 03:00:00 GMT  
 Table repair with TUtility - a waste of time?


Quote:
>The other day I got into troubles with some corrupted tables, and decided to
>find out how well Borland's TUtility works. I understand it's a DLL from
>Borland, around which several people have built useful interfaces. I use the
>Pack program from Zhang Xiaolong, which is nice, but there are others as well,
>and one can easily write the needed code at home if decided.
>Anyway, this DLL offers functions to check a table for problems as well as to
>rebuild it. And here is my experience with it (assumed Pack it just a wrapper
>for it):
>- Tables that are corrupted, will usually be declared to be all right
>- Tables that are fine, at least they seem fine, will be declared bad
>- Some of those declared bad tables, will still be declared bad even after
>several "successful" rebuilds.
>Details:
>I have for some reason gotten terrible problems with "corrupt index" lately.
>It is not even possible to run index rebuild (dbiRebuildIndexes?), or, in some
>cases, index rebuild runs but does not help.
>Still the TUtility check says the tables are OK!
>While in another case of mine, with a post number table, TUtility keeps
>telling that the table is bad and needs rebuild. I let it rebuild, it says the
>rebuild was successful, I run the check again, and guess what? Still bad,
>needs rebuild....and so on, over and over. The table looks fine to me though,
>although I haven't got time to check every single record.
>In other cases it declares a table "bad" when I think it is good - e.g. when
>the table has only one record and that record seems to be all right. It
>corrects the claimed error and afterwards declares the table "good". Is it me
>that does not understand when something is wrong with my tables? Poor tables.
>What will be others' experience with table check and repair? From my (limited)
>experience, it seems not to work at all. I know it is not always supposed to
>solve one's problems, but it hasn't actually helped me, I think, a single tiny
>bit yet.


I've had similar weird behavior - after much experimentation, I came
to the conclusion that Tutility verify/rebuild is unreliable with
either
a) only 1 record in a table - altho accurate if its empty

b) less than 1 Pdox block in use

In DOS, I used Norton tools and a utility called TDR to examine the
blocks and headers and came, grudgingly to that conclusion.

Add a few records and see what tutility tells you about the tables.



Sat, 29 May 1999 03:00:00 GMT  
 Table repair with TUtility - a waste of time?

Quote:

> The other day I got into troubles with some corrupted tables, and decided to
> find out how well Borland's TUtility works. I understand it's a DLL from
> ...

The value of TUtility has been questionable - I have made the very same
observations.
Did you use the latest version (from Borland's Web Site) ?

Aage J.



Sat, 29 May 1999 03:00:00 GMT  
 Table repair with TUtility - a waste of time?

Svein:

Hope this helps:

Look in the Temple of Delphi for my article on networking if you are
running a network. Look in the Information & Tips section. Proper setup
on a network can avoid many of the situations that cause "index out of
date".

We have found TUTIL reliable in cases where the data is corrupted in the
middle of the table, or a data block is corrupted in the middle of the
index.

We have built our components around a backup copy of the structure. This
has proved very reliable for us. It takes some work to set up but the
results have been excellent. Trial versions of TProtect and TRebuilder
are available on Temple of Delphi.

Our shop floor data collection and factory scheduling runs 24hrs/day 365
days a year. Our last call for these problems was December 1995. Our
software now repairs the tables on the fly.

We recently had a problem with a customer where a file was corrupted in
the middle of the file. TUTIL did fix that problem where we cannot. So
we will add TUTIL in the very near future.

Temple of Delphi:  http://www.coast.net/~jkeller/

Plus consider these issues:
***************************

1)Call dbiSaveChanges say on the afterpost event (more info : see
Borland knowledgebase at their site )

2) Call dbiUseIdletime - so that the engine will use idle time to post
unsave records.

3) there's a bug in in windows (3.11 and 95?) VCache.  Disable 32-bits
in Win3.11 and use the old smartdrv instead.
( see:   http://catless.ncl.ac.uk/Risks/17.80.html )

Quote:

> The other day I got into troubles with some corrupted tables, and decided to
> find out how well Borland's TUtility works. I understand it's a DLL from
> Borland, around which several people have built useful interfaces. I use the
> Pack program from Zhang Xiaolong, which is nice, but there are others as well,
> and one can easily write the needed code at home if decided.

> Anyway, this DLL offers functions to check a table for problems as well as to
> rebuild it. And here is my experience with it (assumed Pack it just a wrapper
> for it):

> - Tables that are corrupted, will usually be declared to be all right
> - Tables that are fine, at least they seem fine, will be declared bad
> - Some of those declared bad tables, will still be declared bad even after
> several "successful" rebuilds.

> Details:
> I have for some reason gotten terrible problems with "corrupt index" lately.
> It is not even possible to run index rebuild (dbiRebuildIndexes?), or, in some
> cases, index rebuild runs but does not help.
> Still the TUtility check says the tables are OK!

> While in another case of mine, with a post number table, TUtility keeps
> telling that the table is bad and needs rebuild. I let it rebuild, it says the
> rebuild was successful, I run the check again, and guess what? Still bad,
> needs rebuild....and so on, over and over. The table looks fine to me though,
> although I haven't got time to check every single record.

> In other cases it declares a table "bad" when I think it is good - e.g. when
> the table has only one record and that record seems to be all right. It
> corrects the claimed error and afterwards declares the table "good". Is it me
> that does not understand when something is wrong with my tables? Poor tables.

> What will be others' experience with table check and repair? From my (limited)
> experience, it seems not to work at all. I know it is not always supposed to
> solve one's problems, but it hasn't actually helped me, I think, a single tiny
> bit yet.



--
Regards,
Dave Robinson, VP Development
Amber Computer Systems Inc.

WEBB page: http://mindlink.net/amber_computer/
ASAP-RTS Manufacturing Scheduling and shop floor data collection with
bar coding, and product tagging.  
Databases from directories - an OCR and Scanning system to create
marketing databases from directories.



Sat, 29 May 1999 03:00:00 GMT  
 Table repair with TUtility - a waste of time?

        I use it only as a last resort, it works ~70% of the time
in my experience. My web site has pointers on recovering when tutil
doesn't work under the Tips Area

--
Paradox and Delphi Consultant. Member: Borland Delphi Technical Support
             Most small questions answered for free!

                 http://www.pagescape.com/fire/dbtech/
          My words are my own, I don't speak for Borland.



Sat, 29 May 1999 03:00:00 GMT  
 Table repair with TUtility - a waste of time?

I, too, have hade this problem.  I usually export my data to ASCII (or
somesuch), and re-import to a new "clean" copy of the table.  It's ugly,
but sometimes this is the only way.



Quote:
> The other day I got into troubles with some corrupted tables, and decided
to
> find out how well Borland's TUtility works. I understand it's a DLL from
> Borland, around which several people have built useful interfaces. I use
the
> Pack program from Zhang Xiaolong, which is nice, but there are others as
well,
> and one can easily write the needed code at home if decided.



Mon, 31 May 1999 03:00:00 GMT  
 Table repair with TUtility - a waste of time?



Quote:
>I, too, have hade this problem.  I usually export my data to ASCII (or
>somesuch), and re-import to a new "clean" copy of the table.  It's ugly,
>but sometimes this is the only way.

My contribution to this thread is this:

Why are these tables getting corrupted in the first place?  Are they
paradox tables?  Are paradox tables more susceptible to corruption
than dbase?

Can anyone compare the following tables styles and tell me which is
more stable?

MS Access (.MDB)
Paradox
Dbase (3, 4, Visual, ??)



Wed, 23 Jun 1999 03:00:00 GMT  
 Table repair with TUtility - a waste of time?

Quote:

> My contribution to this thread is this:

> Why are these tables getting corrupted in the first place?  Are they
> paradox tables?  Are paradox tables more susceptible to corruption
> than dbase?

> Can anyone compare the following tables styles and tell me which is
> more stable?

> MS Access (.MDB)
> Paradox
> Dbase (3, 4, Visual, ??)

I haven't done any clinical tests. Just a couple of notations, one from
ready made Access application (haven't seen the code) and another from
Paradox.

1. Visual Basic + Access application for invoicing, accounting etc.
   The users have to run quite often (weekly) a 'Database Maintenence'
routine
   to get the Access database to work again.
   Anyway it seems that Access dB gets very seldom totally stuck, so
that
   you have to go and dig the Back Up tapes.

2. Delphi + Paradox does get stuck! So tight that TUTILITY.DLL wont
help. This
   happens sometimes when you change table structure, or just when you
get totally
   jammed (need boot up) with D1 during development time.

Markku Nevalainen



Thu, 24 Jun 1999 03:00:00 GMT  
 Table repair with TUtility - a waste of time?

Mark:

Grab two articles from our Components page. One is on "Delphi &
Networks" - a lot of people have found the information to be useful for
*preventing* problems. (You may already know the stuff there - but what
the heck.) The other notation refers to a "Risks" article we published
in Feb, 96.

We identified a problem with Windows for Workgroups caching. I suspect
that we still have some type of caching & data consistency bug when a
*Win 95 station is used for a server and a client simultaneously*.
Despite our best efforts with Windows based servers we still have
problems. Our Novell servers have significantly fewer problems - almost
non-existant.

We test our products on Win95, Windows NT 3.51, Windows 4.0x and Novel
4.1x servers. The win NT 3.51 or 4.0 station, with the Novel Server
seems to be the most reliable. Windows 95 is OK but....

We went so far as to design automated repair & recovery procedures for
our distributed database system. You can find information on that page
as well.

They can be found at:
http://mindlink.net/amber_computer/comp01.htm

Quote:



> >I, too, have hade this problem.  I usually export my data to ASCII (or
> >somesuch), and re-import to a new "clean" copy of the table.  It's ugly,
> >but sometimes this is the only way.

> My contribution to this thread is this:

> Why are these tables getting corrupted in the first place?  Are they
> paradox tables?  Are paradox tables more susceptible to corruption
> than dbase?

> Can anyone compare the following tables styles and tell me which is
> more stable?

> MS Access (.MDB)
> Paradox
> Dbase (3, 4, Visual, ??)

--
Regards,
Dave Robinson, VP Development
Amber Computer Systems Inc.

WEBB page: http://mindlink.net/amber_computer/
ASAP-RTS Manufacturing Scheduling and shop floor data collection with
bar coding, and product tagging.  
Databases from directories - an OCR and Scanning system to create
marketing databases from directories.



Thu, 24 Jun 1999 03:00:00 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. Pascal a waste of time?

2. BDE Table Repair completely erases tables ?

3. Table repair utility error table not found

4. Table Corruption and Repair for Paradox Tables

5. ReIndex Table (or Paradox 5.0 TUTILITY?)

6. Tutility 2.52 deletes table

7. Using TUtility on Paradox tables

8. Corruptet Paradox table / TUtility

9. Q : Table Repair - tutil32.dll usage details available ?

10. ADV: ChimneySweep = Paradox table-repair taken to its fullest extent

11. Indexes are lost on table repair !

12. Repair DBAse - tables and indexes....

 

 
Powered by phpBB® Forum Software