Board index » delphi » Table repair with TUtility - a waste of time?

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.

Svein Olav Mytting, Rosendalsv 7A, 0166 Oslo Norway. E-mail bolle...@telepost.no

 

Re:Table repair with TUtility - a waste of time?


bolle...@telepost.no (Svein Olav Mytting) wrote:

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.
>Svein Olav Mytting, Rosendalsv 7A, 0166 Oslo Norway. E-mail bolle...@telepost.no

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.

Re:Table repair with TUtility - a waste of time?


Quote
Svein Olav Mytting wrote:
> 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.

Re: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
Svein Olav Mytting wrote:

> 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.

> Svein Olav Mytting, Rosendalsv 7A, 0166 Oslo Norway. E-mail bolle...@telepost.no

--
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.

Re: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.

Re: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.

Svein Olav Mytting <bolle...@telepost.no> wrote in article
<58joni$jc...@o.online.no>...

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.

Re:Table repair with TUtility - a waste of time?


On 12 Dec 1996 16:47:25 GMT, "Noah Osnos" <Noah_Os...@TommyBoy.com>
wrote:

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, ??)

Re:Table repair with TUtility - a waste of time?


Quote
Mark Williamson wrote:

> 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

Re: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
Mark Williamson wrote:

> On 12 Dec 1996 16:47:25 GMT, "Noah Osnos" <Noah_Os...@TommyBoy.com>
> wrote:

> >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.

Other Threads