OS Error .db table lost 1

[Guest_imported]

We had a problem last week while verifying a table (that did need a rebuild, but that's now beside the point) a message came up OS ERROR. The table was gone from the server. The indexes remained. I was on a Win 95 computer. Data resides on an NT server. Does anyone have any ideas on how to avoid table loss during rebuild? I'm guessing maybe there was a power fluctuation.

 

[footpad]

Have you disabled the optimistic locking on the NT server? If not, that probably explains it. OS Error, as you might expect, is an untrapped error from the operating system.

If you still have optimistic lockinh enabled on the NT server, it's likely that the partially rebuilt (or even backup) table was not written to disk when the error happened. You can't find the file because it never physically existed, NT was just saying that it did while retaining the unwritten portion in memory.

For more information and ideas, you might check out the FAQ called "TIPdoxWin:NT Configuration:2000.06.09" on corelsupport.faqs.paradox. It's a newgroup hosted by Corel and the most active of their FAQ groups.

Hope this helps...

-- Lance

 

[Guest_imported]

Interesting because I have been checking on ways to speed up paradox and I thought that ENABLING opportunistic locks and setting the system refresh rate to 20 were among the top picks. Do I have that backwards?

 

[footpad]

Yes, you do.

Optimistic locks will eventually destroy your Paradox data. Remember, BDE assumes that an unlocked record has been completely written out.

Think of it as an example of just because you can do something, you really don't want to.

There are many other ways to improve overall performance; the most dramatic improvements can be gained by replacing queries and filters with aproaches using the tCursor setRange() method.

As an example, one user I know of used to use simple Checkmark queries to locate individual records. the table in question contained ~250,000 records and was located on a server that was 10 miles from the workstation. It normally took seven minutes to return the results.

As a test, we created a secondary index on the field being searched, mocked up a quick form combining tCursor.setRange() with UIObject.resynch() and ran a simple test. The record was located in 0.91 seconds. (And that's not a misprint. We tested is several times.)

It also helps to make sure your data models are as relational as possible. Paradox responds more esily to sets of records than sets of fields.

Hope this helps...

-- Lance

 

[Miros]

Could you clarify the statement, "Paradox responds more esily to sets of records than sets of fields."?

Thanks,
Rosalie Dieteman
miros1@iwon.com

 

[footpad]

Rosalie,

Sure. Consider the classic address book problem.

Most beginning data designers create something along these lines:

ContactID
LastName
FirstName
Initial
; yadda, yadda, yadda
HomeAddr
HomeCity
HomeState
; yadda, yada, yadda
WorkAddr
WorkCity
WorkState
; etc...

While this serves for a time, you eventually run into a third address ("Oh, this is my place in the Hamptons. Can you overnight it?&quot or a fourth.

Paradox doesn't respond well to this.

Instead, Paradox prefers it if you break repeating data elements into separate tables.

In this case:

NAMES -->> ADDRESSES

In other words, the NAMES table contains just the data required to uniquely identify an individual whereas the ADDRESSES table tracks all addresses. This lets you have as many addresses as needed without wasting space. For example, if your friend in the Hamptons decides to take a place in the Smokey Mtns, you can overnight him a package there, too...without a lot of extra efforts or overhead.

Paradox handles relationships between tables very well and it's designed to he4lp you drill down to the specific data you need. Oftne, this means taking extra care to ensure that your data models are as relational as is reasonable (there are reasons to break Codd's original rules) and it also means that your data structure can either make your like very easy or very difficult.

Hope this helps...if not, please, ask for more details...

-- Lance

 

[Miros]

Ah, perfectly clear...

Yet another application of the rules I learned last semester in the DataBase design course I took.

Rose/Miros