Board index » delphi » Corrupted Paradox tables

Corrupted Paradox tables

We have a order entry program written in Delphi 2 which fills several
linked Paradox 5 tables with information and linear dimensions. We also
have a legacy Paradox 3.5 accounting package which needs information from
the order entry program for invoicing. Since both programs cannot access
the accounting tables at the same time, we use three temporary export
tables from the order entry program which are merged into the correct
tables in the accounting package at the end of the day.

Our problem is that every four to ten orders entered (never consistent),
one of the export tables (not always the same) ends up corrupted. We
rebuild it using the TUTILITY program in Paradox 3.5, but this is getting
annoying. We've tried isolating all the exporting in separate routines
using program data instead of from table to table; We've made sure all
other tables are closed before opening any of the export tables; We've
eliminated all VALCHECKS from the tables; all to no avail.

The problem is intermittent and non-reproducible, i.e., the order that
trashed the table once, will not be a problem when reentered.

Has anyone had a problem with the BDE in Delphi 2 trashing Paradox 3.5
tables and indexes? Thanks for any suggestions you may have

 

Re:Corrupted Paradox tables


Could it possibly be workstation setup ?  I've been this sort of thing
happen (not spevifically with pdos 3.5) when the workstation runs out of
file handles.  Novell is bad at this.  If you are running and old system
you may be using old novell client drivers (that is of course if you are on
Novell .....).  It was the single biggest reason for spurious data
corruption on the network when I was a techy support for a database
development product.

Re:Corrupted Paradox tables


Greg McCreath <g...@unicorn-bs.com> wrote in article
<01bd8f93$d10df800$3900a8c0@gregntserver>...

Quote
> Could it possibly be workstation setup ?   If you are running and old

system....

We have a small office and network (8 nodes), so we are using Win 95. All
computers were recently upgraded to Pentium 200 mhz with 48 MB of Ram. The
system we are using for the server is a Pentium II 233 mhz with 64 MB.

I might believe in workstation setup if the problem affected any file more
or less randomly, but it only hits the Paradox 3.5 export files. No other
data files are ever affected.

Today we hit a stretch where we entered over 40 orders without a hitch, and
thought the problem had cured itself, but then we got nailed 4 times in the
next 14 orders. It's always recoverable, with the loss of only the last
order. If we inspect the broken table before repair, the last record is
filled with garbage.

Thanks for the suggestion, though. I'll check the setup on all the nodes
tomorrow.

Re:Corrupted Paradox tables


The first question I have is why you need the temp tables, you mention that
you can't access the same table at the same time but you can in paradox.  I
would like more explanation on this and maybe I can help further.

We have a database app with over 200 paradox tables.  For the first 3 years
of our existence with did nothing but fight paradox file corruption's.  We
looked into all different avenues of replacing paradox with Interbase, SQL
Server, Oracle .... but none could compare to the raw speed of the Paradox
table accesses.  We then decided to spend more time on the application
itself learning the best methods for accessing and saving the tables.

Here is what we have learned.  First of all, with a network that has 8
systems connected and has 95 as the server you are asking for problems.
Win95 shouldn't be used for networks any larger than 4 or 5 because they
reach a point at which they can no longer handle the network requests and
instead of caching the requests they just drop them.  Dropping a Paradox
request is a sure corruption everytime.  Paradox doesn't handle any data
corruption very well at all so you have to do it for it.

The first thing we did, is we used the dbisavechanges on every table that we
saved.  This didn't work to fix the problems but it does help in the loss of
information during a power failure or something.

The next thing that we did is we try to keep tables closed that we are not
using, and the tables we do use a lot, we try to close and then reopen
during times such as closing the order form.  This insures that things are
written properly to the servers drive.

The last thing we did has more to do with your network though.  What
protocols are you using?  If your running win95 or NT you don't need IPX/SPX
which is loaded by default.  I would suggest deleting it.  The second thing
is the order of the protocols in your stack.  You need to make sure the
first protocol is NetBEUI because it is by far the fastest and cleanest and
will help the win95 server handle the request more efficiently.

You may need TCP/IP, but on a network your size your probably not doing any
routing or other such activities so I wouldn't load TCP/IP on the network
card unless you have to have it for something.  If you do load it make sure
it is loaded after NetBEUI.

Back to the access issue with the tables, you can access the tables at the
same time you just can't modify the same order at the same time by 2
different people.  If you go back to accessing the real time tables, try
using the caching capabilities.  They have some quirks that you might have
to work around but they are not major and if implemented correctly can
improve overall performance and help to eliminate the corruption problems.

Hope this helps,

Glenn Hancock
ghanc...@softek-software.com

Quote
Jeffrey Eib wrote in message <01bd8f57$90c072a0$d8fecc98@jeffreys>...
>We have a order entry program written in Delphi 2 which fills several
>linked Paradox 5 tables with information and linear dimensions. We also
>have a legacy Paradox 3.5 accounting package which needs information from
>the order entry program for invoicing. Since both programs cannot access
>the accounting tables at the same time, we use three temporary export
>tables from the order entry program which are merged into the correct
>tables in the accounting package at the end of the day.

>Our problem is that every four to ten orders entered (never consistent),
>one of the export tables (not always the same) ends up corrupted. We
>rebuild it using the TUTILITY program in Paradox 3.5, but this is getting
>annoying. We've tried isolating all the exporting in separate routines
>using program data instead of from table to table; We've made sure all
>other tables are closed before opening any of the export tables; We've
>eliminated all VALCHECKS from the tables; all to no avail.

>The problem is intermittent and non-reproducible, i.e., the order that
>trashed the table once, will not be a problem when reentered.

>Has anyone had a problem with the BDE in Delphi 2 trashing Paradox 3.5
>tables and indexes? Thanks for any suggestions you may have

Re:Corrupted Paradox tables


Glenn <ghanc...@softek-software.com> wrote in article
<6lbtqh$1...@forums.borland.com>...

Quote
> The first question I have is why you need the temp tables, you mention

that you can't access the same table at the same time but you can in
paradox.  I would like more explanation on this and maybe I can help
further.

The legacy accounting application we are using is a commercial program
written completely as a set of Paradox 3.5 PAL scripts. It serves its
purpose for now, but eventually will be replaced. Until then we need the
export tables because Paradox 3.5 and the BDE cannot access the same tables
at the same time. Whichever ones opens first shuts out the other. Therefore
we cannot write directly to the accounting tables while the accounting
program is running.

Quote
> First of all, with a network that has 8 systems connected and has 95 as

the server you are asking for problems. Win95 shouldn't be used for
networks any larger than 4 or 5

We realize this, but this is a small company with a limited MIS budget, and
the majority of it was spent this year on production automation. So we make
do.
Also, two of the nodes in the network are CAD stations which create very
little network traffic, as they keep their drawings local. A third node is
used to run the accounting system. All of its tables are local, and the
only traffic going to or from is at the end of the day when the export
tables are merged and when backing up.

Quote
> The next thing that we did is we try to keep tables closed that we are

not using, and the tables we do use a lot, we try to close and then reopen
during times such as closing the order form.  This insures that things are
written properly to the servers drive.

This was the first thing we tried. When data is being written to the export
tables, each one is opened, written to, and closed individually. No other
tables, except the system tracking table is opened when the data is
written.

Quote
> The last thing we did has more to do with your network though.  What

protocols are you using?  If your running win95 or NT you don't need
IPX/SPX which is loaded by default.  I would suggest deleting it.  The
second thing is the order of the protocols in your stack.  You need to make
sure the first protocol is NetBEUI because it is by far the fastest and
cleanest and will help the win95 server handle the request more
efficiently.

This is something we had not thought of but will definitely check out. We
really don't have a network expert in house. We've been basically learning
on the fly. If this fixes the problem, then maybe we will be able to get
management to spring for some training courses.

The really odd thing about this, is that it is only the export tables that
get trashed. We use 25 linked paradox tables for order entry and none of
them ever has a problem. They all contain data from the last five years.
The export tables are emptied every night, so they never have more than 100
orders worth of data in them. That's what makes me think that its not
network, or workstation related, but a problem between Paradox 3.5 tables
and the BDE.

Anyway, thanks for the suggestions. I will check the network tomorrow, and
keep my fingers crossed.

Other Threads