Paradox Corruption and lock outs 1

[tbclbd]

I have inherited a Paradox 10 Application that is having some problems. I do not know anything about Paradox, so please bear with me. The files keep getting corrupted, and when they are not corrupt, the response time is slow.

My questions
The application is set up on a server, and all users use the main form from the server. Is there a way to create a project(?) which could be loaded on the local machines, and tied to the data on the server?

Would this approach cut down on some of the file corruptton?

Also, if one person's machine locks up (power surge, etc), Paradox has to be reloaded on their machine before they can get back into the program. Is there a way around this?

Thanks in advance for any help.

 

[TonyMcGuire]

First: Power surge. EVERY system that runs a database type application should NEVER be started without a UPS. NEVER EVER!

Corruption: NOT normal. There are several things that could be the source.
First, OPLOCKS. Set the server and workstations to turn oplocks **OFF**.

http://www.tonymcguire.com/oplocks-nt.htm

http://www.tonymcguire.com/oplocks-2000.htm

Next, Write-cache. Not all hard drives allow it, but if possible turn write caching **OFF**.
Next, if you don't have power management turned **OFF** on the network cards on ALL systems, do so immediately.

And if you don't have a UPS on EVERY system, shut them off until you go purchase UPSs for EVERY system.

And that includes any hubs/switches/routers/etc!!

Moving forms/reports/libraries to the local workstations, and keeping only the data on the server, will speed up loading by a *bunch*, and cut down the overhead going across the network. This is the normal configuration. If aliases are used then it *probably* isn't a lot of work to move to this type of configuration. If your app doesn't use aliases, it'll take some time to change things. But well worth it in the long run.

Tony McGuire

http://www.thedbcommunity.com

"It's not about having enough time. It's about priorities

 

[TonyMcGuire]

For corruption, you should also check EVERY machine with Paradox has LOCAL SHARE = TRUE in the BDE Configuration Utility.

Tony McGuire

http://www.thedbcommunity.com

"It's not about having enough time. It's about priorities

 

[TonyMcGuire]

Lockup & reload.

Are you saying they have to have Paradox *reinstalled* ?? Or just exited and restarted?

Way wacky if reinstalled. Have you tried simply rebooting?

If rebooting does it, likely Paradox is just held in memory (see pdxwin32.exe in the Task Manager list) and needs to be shut down before that computer can start it again.

When are the lockups occurring? Is Paradox and/or Paradox objects left onscreen when the lockup occurs?

Tony McGuire

http://www.thedbcommunity.com

"It's not about having enough time. It's about priorities.

 

[tbclbd]

Tony

Thank you for your reply. i will certainly try your suggestions.

As to the lockup and reload - rebooting does not fix the problem, we have to delete entries in the registry, and then reload Paradox on the machine.

The problem starts when there is a power surge, and whoever has Paradox open at the time, can not get back in until it's reloaded on their machine.

Again, thanks for any help you can offer.

 

[TonyMcGuire]

'can not get back in until...'

What does the user experience when trying to restart Paradox on that machine?

Tony McGuire

http://www.thedbcommunity.com

"It's not about having enough time. It's about priorities.

 

[TonyMcGuire]

'can not get back in until...'

What does the user experience when trying to restart Paradox on that machine?

The more complete description you can give, the more likely someone here can make useful suggestions.

Tony McGuire

http://www.thedbcommunity.com

"It's not about having enough time. It's about priorities.

 

[tbclbd]

Hi Tony,

I believe they were getting an error message - Unrecognized Database format.

Thanks

 

[TonyMcGuire]

If that happens again, you might try:

Search & delete ALL pdx*.cfg files - these are the toolbar files - before reinstalling.

Tony McGuire

http://www.thedbcommunity.com

"It's not about having enough time. It's about priorities.

 

[tbclbd]

Thank you, will certainly give it a try