Index Corruption!!!

Sundial Servic

Delphi Developer

Wed, 18 Jun 1902 08:00:00 GMT

The Curse of Table/Index Corruption!!!

Quote

In article <61jr9o$ql...@reader1.reader.news.ozemail.net> aj...@ozemail.com.au (Adam Johnston) writes:
>What happens when you have been writing records to a table and indexes
>have been updated and suddenly there is a power failure or Windows
>locks up completely and you have to reset - Table/Index corruption
>and/or all posts made since the file was open are lost.
>How do you ensure that when you post a record that it actually goes to
>disk and that its not sitting in memory other than closing the files
>and reopening them?

Surf to http:///www.dejanews.com and search on "DbiUseIdleTime" for more
postings on this subject than you possibly care to read.

Steve Garla

Delphi Developer

Wed, 18 Jun 1902 08:00:00 GMT

Re:The Curse of Table/Index Corruption!!!

Quote

>What happens when you have been writing records to a table and indexes
>have been updated and suddenly there is a power failure or Windows
>locks up completely and you have to reset

Get a UPS on each work station and make sure your network is working
properly (cables, nic's etc).

If you are really serious, get SQL Anywhere which is true client
server. What you are talking about will happen with all file server
based systems. Go to client server if you absolutely need 7X24
reliability.

Hey, I sell a shareware product to Fix Paradox Indexes, Paradox
Infirmary & Resort and I can't wait till all my projects are client
server also<g>.

E-mail from: Steve Garland,Hyper Logic Resource Group http://netnow.micron.net/~sgarland
Hyper Bill of Materials (HBOM), Paradox Infirmary & Resort (fix paradox files and more!)
Delphi Corel Visual CADD (tm)Component (HVCADD)- View and Manipulate AutoCAD (c) DWG Files

Chuck Ga

Delphi Developer

Tue, 28 Mar 2000 03:00:00 GMT

Re:The Curse of Table/Index Corruption!!!

On Fri, 10 Oct 1997 17:02:58 GMT, aj...@ozemail.com.au (Adam Johnston)
wrote:

Quote

>What happens when you have been writing records to a table and indexes
>have been updated and suddenly there is a power failure or Windows
>locks up completely and you have to reset - Table/Index corruption
>and/or all posts made since the file was open are lost.

>How do you ensure that when you post a record that it actually goes to
>disk and that its not sitting in memory other than closing the files
>and reopening them?

Go to a client/server database.

Quote

>under Win 95 and occassionally everything locks up and they have to
>reset. Sometimes this is OK but usually it screws the files up big

>What causes the lockups anyway?

That's what you need to find out. What else is running on that
machine? Have you looked into running WinNT instead of 95? It's
stability is much better.

Is your application leaking memory somewhere?

Quote

> Will converting to D3 correct these problems and/or is it more robust?

No. If Win95 is locking up, either the machine is flaky, or the app
has a bug in it somewhere.

Chuck Gadd
Director of Software Development, {*word*104} FX Communications.
e-mail:cgadd-NOS...@{*word*104}-fx.com http://www.csd.net/~cgadd
Remove the -NOSPAM from my email address to send me e-mail.
*** I boycott businesses that send me unsolicited email adverti{*word*224}ts ***

Garry Kerna

Delphi Developer

Tue, 28 Mar 2000 03:00:00 GMT

Re:The Curse of Table/Index Corruption!!!

Adam,

Btrieve makes a very complete low level solid file manager / database
manager / SQL manager. Btrieve along with Titan's btrieve aware delphi
data controls will give you the power you are looking for.

You have Transaction processing to guarentee that all or nothing gets
posted. During a transaction all appends, deletes and edits get posted
assuming correctness. If there is a power failure or you issue an abort
then next time the system powers up the data files are automatically
returned to the condition prior to the power out / begin transaction.

Garry Kernan

Quote

Adam Johnston wrote:

> G'Day,

> This is a problem that has been pissing me off for years in other
> database languages as well as Delphi and I still don't know a way
> around it.

> What happens when you have been writing records to a table and indexes
> have been updated and suddenly there is a power failure or Windows
> locks up completely and you have to reset - Table/Index corruption
> and/or all posts made since the file was open are lost.

> How do you ensure that when you post a record that it actually goes to
> disk and that its not sitting in memory other than closing the files
> and reopening them?

> Currently I am having this problem with a mission critical D1
> application that must run all day long without fail. It is running
> under Win 95 and occassionally everything locks up and they have to
> reset. Sometimes this is OK but usually it screws the files up big
> time!

> What causes the lockups anyway? Will converting to D3 correct these
> problems and/or is it more robust?

> Any help appreciated.

> Regards
> Adam Johnston

Bjorn Heidar

Delphi Developer

Wed, 29 Mar 2000 03:00:00 GMT

Re:The Curse of Table/Index Corruption!!!

Hi Chuck & Adam!

I have tried using Borland's Paradox...:o(
If that's what you are using, I am not the least surprised....

Here is my view:
It should NOT be so *natural* that a Database goes down destroyed
like the Paradox tables so often do. Sometimes I find that people think
this is the most natural thing, but it is NOT. Paradox is simply a BAD
PRODUCT. It is to risky to use simply because of the fact that it's tables
so often crash. There is absolutely nothing that may happen to the system
without the tables being corrupted and most of the time so bad that they
are irrecoverable. A database system should act correctly and not destroy
it's data in spite of the fact that it is a local base and not a
Client/Server based one.
On top on that, a number of requests here to this thread and the
.databases thread, are from programmers asking for utilities for building
up the PDX databases - so well is this utility hidden...

Well - this was just my hat into this ring.
I am using Btrieve as the local base and various other Client/Server
bases, like Progress, Oracle and other stuff, and with all those we have
quite the opposite story to tell!

Regards,
Bjorn, TransSoft

Quote

> >What happens when you have been writing records to a table and indexes
> >have been updated and suddenly there is a power failure or Windows
> >locks up completely and you have to reset - Table/Index corruption
> >and/or all posts made since the file was open are lost.

> >How do you ensure that when you post a record that it actually goes to
> >disk and that its not sitting in memory other than closing the files
> >and reopening them?

> Go to a client/server database.

> >under Win 95 and occassionally everything locks up and they have to
> >reset. Sometimes this is OK but usually it screws the files up big

> >What causes the lockups anyway?

> That's what you need to find out. What else is running on that
> machine? Have you looked into running WinNT instead of 95? It's
> stability is much better.

> Is your application leaking memory somewhere?

> > Will converting to D3 correct these problems and/or is it more robust?

> No. If Win95 is locking up, either the machine is flaky, or the app
> has a bug in it somewhere.

> Chuck Gadd
> Director of Software Development, {*word*104} FX Communications.
> e-mail:cgadd-NOS...@{*word*104}-fx.com http://www.csd.net/~cgadd
> Remove the -NOSPAM from my email address to send me e-mail.
> *** I boycott businesses that send me unsolicited email adverti{*word*224}ts
***

--
--
__ __/ _/
/ /__
/ /
_/ /___/

=======================================================================
TransSoft Ltd - http://www.transsoft.com
"TransSoft's Mail Control - The Multiple Award Winning Email Client..."
=======================================================================

A. Sari

Delphi Developer

Wed, 29 Mar 2000 03:00:00 GMT

Re:The Curse of Table/Index Corruption!!!

If you don't want to go client-server, or can't, here is the ONLY way you
can avoid this:

After EVERY WRITE to the database, flush all your buffers by issue
Table1.close; Table1.open. it is like flush(MyTextFile); command for text
output or printer files.
This is not perfect and will cost you run time. But your stuff will be as
problem-free as non client-server application can be. Don't forget that
closing and reopening will set your table cursor to the top.

Quote

Adam Johnston wrote:
> G'Day,

> This is a problem that has been pissing me off for years in other
> database languages as well as Delphi and I still don't know a way
> around it.

> What happens when you have been writing records to a table and indexes
> have been updated and suddenly there is a power failure or Windows
> locks up completely and you have to reset - Table/Index corruption
> and/or all posts made since the file was open are lost.

> How do you ensure that when you post a record that it actually goes to
> disk and that its not sitting in memory other than closing the files
> and reopening them?

> Currently I am having this problem with a mission critical D1
> application that must run all day long without fail. It is running
> under Win 95 and occassionally everything locks up and they have to
> reset. Sometimes this is OK but usually it screws the files up big
> time!

> What causes the lockups anyway? Will converting to D3 correct these
> problems and/or is it more robust?

> Any help appreciated.

> Regards
> Adam Johnston

Robert Kapla

Delphi Developer

Thu, 30 Mar 2000 03:00:00 GMT

Re:The Curse of Table/Index Corruption!!!

Amen! I've been apalled at the casual acceptance of the destruction of
data in Paradox. Some folks simply take it for granted that a DB will
get trashed every few days, and instead of questioning why they are
putting up with this garbage in the first place, look for better fixit
tools, programming workarounds, etc.

The fact that Delphi and Paradox were developed by the same company
makes it even more irritating. But it should come as no suprise. For all
of Borland's talents, one had only to look at the DB support in D1 to
know that these guys never had to deal with real life large DB
development. Shure, they can display a fish out of a little 10 fishes
table. Put it in production!

Robert

Quote

Bjorn Heidarr wrote:

> Hi Chuck & Adam!

> I have tried using Borland's Paradox...:o(
> If that's what you are using, I am not the least surprised....

> Here is my view:
> It should NOT be so *natural* that a Database goes down destroyed
> like the Paradox tables so often do. Sometimes I find that people think
> this is the most natural thing, but it is NOT. Paradox is simply a BAD
> PRODUCT. It is to risky to use simply because of the fact that it's tables
> so often crash. There is absolutely nothing that may happen to the system
> without the tables being corrupted and most of the time so bad that they
> are irrecoverable. A database system should act correctly and not destroy
> it's data in spite of the fact that it is a local base and not a
> Client/Server based one.
> On top on that, a number of requests here to this thread and the
> .databases thread, are from programmers asking for utilities for building
> up the PDX databases - so well is this utility hidden...

> Well - this was just my hat into this ring.
> I am using Btrieve as the local base and various other Client/Server
> bases, like Progress, Oracle and other stuff, and with all those we have
> quite the opposite story to tell!

> Regards,
> Bjorn, TransSoft

> > >What happens when you have been writing records to a table and indexes
> > >have been updated and suddenly there is a power failure or Windows
> > >locks up completely and you have to reset - Table/Index corruption
> > >and/or all posts made since the file was open are lost.

> > >How do you ensure that when you post a record that it actually goes to
> > >disk and that its not sitting in memory other than closing the files
> > >and reopening them?

> > Go to a client/server database.

> > >under Win 95 and occassionally everything locks up and they have to
> > >reset. Sometimes this is OK but usually it screws the files up big

> > >What causes the lockups anyway?

> > That's what you need to find out. What else is running on that
> > machine? Have you looked into running WinNT instead of 95? It's
> > stability is much better.

> > Is your application leaking memory somewhere?

> > > Will converting to D3 correct these problems and/or is it more robust?

> > No. If Win95 is locking up, either the machine is flaky, or the app
> > has a bug in it somewhere.

> > Chuck Gadd
> > Director of Software Development, {*word*104} FX Communications.
> > e-mail:cgadd-NOS...@{*word*104}-fx.com http://www.csd.net/~cgadd
> > Remove the -NOSPAM from my email address to send me e-mail.
> > *** I boycott businesses that send me unsolicited email adverti{*word*224}ts
> ***

> --
> --
> __ __/ _/
> / /__
> / /
> _/ /___/

> =======================================================================
> TransSoft Ltd - http://www.transsoft.com
> "TransSoft's Mail Control - The Multiple Award Winning Email Client..."
> =======================================================================

Sundial Servic

Delphi Developer

Thu, 30 Mar 2000 03:00:00 GMT

Re:The Curse of Table/Index Corruption!!!

Quote

In article <01bcd66e$8c4e7570$a0f104c1@intelpro> "Bjorn Heidarr" <b...@centrum.is> writes:
> Here is my view:
> It should NOT be so *natural* that a Database goes down destroyed
>like the Paradox tables so often do. Sometimes I find that people think
>this is the most natural thing, but it is NOT. Paradox is simply a BAD
>PRODUCT. It is to risky to use simply because of the fact that it's tables
>so often crash. There is absolutely nothing that may happen to the system
>without the tables being corrupted and most of the time so bad that they
>are irrecoverable. A database system should act correctly and not destroy
>it's data in spite of the fact that it is a local base and not a
>Client/Server based one.
> On top on that, a number of requests here to this thread and the
>.databases thread, are from programmers asking for utilities for building
>up the PDX databases - so well is this utility hidden...

Hmm... I've been running my business on Paradox tables for the past six years
and somehow I think the patient is not quite as dead as you may think.

If you are interested in this issue, surf to http://www.dejanews.com and
search for the key "DbiUseIdleTime."

You will find there several threads of articles describing how Delphi-1
applications fail to write pending updates to disk in a timely manner unless
this routine is called regularly. You will find source-code describing
exactly how to do it. This source code works just fine.

If you want to find a tool that will put your table-troubles to bed with a
single click of the mouse, surf to our site: http://www.sundialservices.com/

When any of our apps have table malfunctions we no longer hear about it.
Users simply double-click on an icon and the custom ChimneySweep jobs we have
issued to them correct their troubles, generally in a matter of a minute or
less. And because we have coded our D1 applications as described in these
posts, the tables run just as reliably for us as they do with Paradox for
Windows.

Sundial Servic

Delphi Developer

Wed, 18 Jun 1902 08:00:00 GMT

Re:The Curse of Table/Index Corruption!!!

Quote

In article <34405DC1....@iamerica.net> Robert Kaplan <rkap...@iamerica.net> writes:
>Amen! I've been apalled at the casual acceptance of the destruction of
>data in Paradox. Some folks simply take it for granted that a DB will
>get trashed every few days, and instead of questioning why they are
>putting up with this garbage in the first place, look for better fixit
>tools, programming workarounds, etc.
>The fact that Delphi and Paradox were developed by the same company
>makes it even more irritating. But it should come as no suprise. For all
>of Borland's talents, one had only to look at the DB support in D1 to
>know that these guys never had to deal with real life large DB
>development. Shure, they can display a fish out of a little 10 fishes
>table. Put it in production!

Robert, put the following code in your application (as Borland itself
described) and the problems you are experiencing will go away:

(1) In the Application.OnIdle routine:
DbiUseIdleTime;

(2) In a timer that is set to go off every second after the database is open:
DbiUseIdleTime;

Steve Garla

Delphi Developer

Wed, 18 Jun 1902 08:00:00 GMT

Re:The Curse of Table/Index Corruption!!!

Quote

>After EVERY WRITE to the database, flush all your buffers by issue
>Table1.close; Table1.open.

Eek! That's a bit much.

1. In the bde config set local share to true.
2. Override your table post method and call dbisavechanges(handle).
That'll do the same as closing the table without all the overhead of
opening and closing it. More better<g> and faster!!

Bjorn Heidar

Delphi Developer

Fri, 31 Mar 2000 03:00:00 GMT

Re:The Curse of Table/Index Corruption!!!

Hmm...

Hello "Sundial"... (You have got to pick a name...;o)

When experienced programmers are having such difficulties with paradox
and are not able to find the solution in another manner than surfing the
'Net, crying on the news-groups, looking for tools or tips for stopping the
data-crashes; something is definitely wrong. Wouldn't you agree on that?
While other database tools are allowing us to install and start the work
without any problems. It does strike me as a more reliable tool to use for
something as valuable as the data being worked on and with.... The default
setting for ALL databases should be "SAVE THE DATA"! Other measures for
speedup and manipulation should be the ones so well hidden!

A question is: Why do we need such tools and add-ons or locate some
hidden procedures that are not defined in the VCL's documentation, yet are
NEEDED for successful database work!

As is (as you can read...) I am not a PDX lover! I had some long and
frustrating weeks of testing, crashing and bad experiences with PDX and you
can NOT depend on Borland's support. Their support is nothing to be
cheerful about!

Cheers!
Regards,
Bjorn
--
--
__ __/ _/
/ /__
/ /
_/ /___/

Sundial Services <news-re...@sundialservices.com> wrote in article
<news-reply.6367.003A8...@sundialservices.com>...

Quote

> In article <01bcd66e$8c4e7570$a0f104c1@intelpro> "Bjorn Heidarr"
<b...@centrum.is> writes:

> > Here is my view:
> > It should NOT be so *natural* that a Database goes down destroyed
> >like the Paradox tables so often do. Sometimes I find that people think
> >this is the most natural thing, but it is NOT. Paradox is simply a BAD
> >PRODUCT. It is to risky to use simply because of the fact that it's
tables
> >so often crash. There is absolutely nothing that may happen to the
system
> >without the tables being corrupted and most of the time so bad that they
> >are irrecoverable. A database system should act correctly and not
destroy
> >it's data in spite of the fact that it is a local base and not a
> >Client/Server based one.
> > On top on that, a number of requests here to this thread and the
> >.databases thread, are from programmers asking for utilities for
building
> >up the PDX databases - so well is this utility hidden...

> Hmm... I've been running my business on Paradox tables for the past six
years
> and somehow I think the patient is not quite as dead as you may think.

> If you are interested in this issue, surf to http://www.dejanews.com and
> search for the key "DbiUseIdleTime."

> You will find there several threads of articles describing how Delphi-1
> applications fail to write pending updates to disk in a timely manner
unless
> this routine is called regularly. You will find source-code describing
> exactly how to do it. This source code works just fine.

> If you want to find a tool that will put your table-troubles to bed with
a
> single click of the mouse, surf to our site:

http://www.sundialservices.com/

- Show quoted text -

Quote

> When any of our apps have table malfunctions we no longer hear about it.
> Users simply double-click on an icon and the custom ChimneySweep jobs we
have
> issued to them correct their troubles, generally in a matter of a minute
or
> less. And because we have coded our D1 applications as described in
these
> posts, the tables run just as reliably for us as they do with Paradox for
> Windows.

Markku Nevalaine

Delphi Developer

Wed, 18 Jun 1902 08:00:00 GMT

Re:The Curse of Table/Index Corruption!!!

Quote

Steve Garland wrote:

> 1. In the bde config set local share to true.
> 2. Override your table post method and call dbisavechanges(handle).
> That'll do the same as closing the table without all the overhead of
> opening and closing it. More better<g> and faster!!

You say, to override Post totally? Could you please put here some lines
(at least 20+ lines, to make it clear) of code, how should one do this
in the right way?

Markku Nevalainen

Bryan Valenci

Delphi Developer

Fri, 31 Mar 2000 03:00:00 GMT

Re:The Curse of Table/Index Corruption!!!

Quote

Adam Johnston wrote:
> G'Day,

> This is a problem that has been pissing me off for years in other
> database languages as well as Delphi and I still don't know a way
> around it.

> What happens when you have been writing records to a table and indexes

> have been updated and suddenly there is a power failure or Windows
> locks up completely and you have to reset - Table/Index corruption
> and/or all posts made since the file was open are lost.

> How do you ensure that when you post a record that it actually goes to

> disk and that its not sitting in memory other than closing the files
> and reopening them?

> Currently I am having this problem with a mission critical D1
> application that must run all day long without fail. It is running
> under Win 95 and occassionally everything locks up and they have to
> reset. Sometimes this is OK but usually it screws the files up big
> time!

> What causes the lockups anyway? Will converting to D3 correct these
> problems and/or is it more robust?

> Any help appreciated.

Look, I have seen this from time to time as well. Here are the
approaches I have seen.

1. Tight Save Code. Make the save routine post as quickly as possible.
Don't allow users to lock records while they are editing.
2. UPSs. If your app is really mission critical, get a UPS
(Uninteruptable Power Supply) for all your computers and servers.
3. Use stored procedures to encapsulate saves...

--
"The sooner you fall behind, the more time you'll have to catch up."

Bryan Valencia
Software Services - Making Windows Scream
http://www.thevision.net/softserv/

John Randa

Delphi Developer

Sat, 01 Apr 2000 03:00:00 GMT

Re:The Curse of Table/Index Corruption!!!

Quote

In article <61v0bf$gv...@reader1.reader.news.ozemail.net> aj...@ozemail.com.au (Adam Johnston) writes:
>From: aj...@ozemail.com.au (Adam Johnston)
>Subject: Re: The Curse of Table/Index Corruption!!!
>Date: Tue, 14 Oct 1997 22:40:36 GMT
> I have not tried this with local share set TRUE however.

Adam, You MUST set local share to true if you are using Win95 peer-to-peer
networking. I'm told you don't have to if you are using Novell. I struggled
for ages with a database (Delphi app controlling a Paradox db) which refused
to stay uncorrupted. Then I tried doing as I'd been told (but not listened
because of the statements in the help file re local shareing). I found (for
example) that Table.Exclusive DOES NOT WORK if local share is set to false.
Set it to true and explicit locking works. If explicit locking is not
working, implicit locking is presumably also not working!

I hope I've helped,
John.

John Randa

Delphi Developer

Wed, 18 Jun 1902 08:00:00 GMT

Re:The Curse of Table/Index Corruption!!!

Quote

In article <61v0bf$gv...@reader1.reader.news.ozemail.net> aj...@ozemail.com.au (Adam Johnston) writes:
>From: aj...@ozemail.com.au (Adam Johnston)
>Subject: Re: The Curse of Table/Index Corruption!!!
>Date: Tue, 14 Oct 1997 22:40:36 GMT
> I have not tried this with local share set TRUE however.

I hope I've helped,
John.

Go to page: [1] [2]

Other Threads

1. The Curse of Table/Index Corruption!!!

2. Index corruption on paradox tables

3. Index corruption on Paradox table

4. Table (index-file) corruption or bug in environment?

5. Index corruption on dBase tables

6. Create index of Paradox table -- Table is not indexed

7. Table Corruption and Repair for Paradox Tables

8. Opinions sought on database/index corruption

9. international drivers with secondary index-> corruption

10. Apollo/Delphi: Clipper Index Corruption Problem