Strangest Paradox Related Problem 1

[SuperG]

Though this may be a bold statement I think my problem it may take the cake.

On seemingly random records paradox closes and goes back to the desktop. No error message, no log file only lock files.

Heres as many details as I can think of

WinXP Pro. Workstations
Win2k Server
Paradox 10 Runtime
12-16 concurrent users
Tables are OK and Packed on a regular basis.

code executes to re-calculate rates for social assistance clients based on familysize etc. when this is done sometimes it will close paradox and go back to the desktop.

There was no problems with this in Paradox 8 at all and it happened rarely in the full version of Paradox 10. Some users never seem to get this others it happens very frequently.

All computers are identical hardware and software.

Going back to Paradox 8 or full paradox 10 for the workstations is not an option IT department will even consider. They insist it is a programming issue and that I rewrite the section of offending code.

However I don't want to recreate the code if I don't have to.

Any ideas would be greatly appreciated.

Glenn

 

[footpad]

Glenn,

Clearly, this isn't normal behavior.

I suspect there's a configuration or environmental condition that's causing Paradox to abruptly terminate. Here's a list of things to check:

1. Verify that all your forms and reports are using valid stylesheets--even if you don't use stylesheets yourself. (See

http://techtricks.com/paradox/interpret.php

for one of several related articles on the site).

2. Verify that all forms do not have any saved filter settings. You'll need to open each in a Design window and then check Format | Filter.

3. Verify that all users have the appropriate Windows and BDE configuration settings. See

http://bdesupport.com/stability.htm

for details on this one, especially the opportunitic locking stuff.

4. Verify that your *indexes* aren't corrupted. Sadly, the only way to do this is to delete the existing ones and then regenerate them with Restructure.

BTW, packing may occasionally fail without a message if the table is already corrupted. The only way I know to verify this is to rebuild the table without verifying it.

I have seen cases with older versions of Paradox and/or BDE where adding fields to a table's structure after it's been in use for a time will slightly corrupt the table. You can still use it, but pack() doesn't do anything. you might be able to detect this if the table's disk size doesn't change after packing; I haven't verified this for myself.

Hope this helps...

-- Lance

 

[SuperG]

I hope I am not speaking to soon but the problem appears to be fixed. Thank you for the advice Lance it seems it was filters saved in forms that had done it.

I removed the filters from the forms and added them in the open method of the objects being filtered in ObjectPal like so:

Var
FilterSpec dynArray[] AnyType
EndVar

FilterSpec[&quot;LinkRelationship&quot;] = &quot; <> Applicant&quot;

self.setGenFilter(FilterSpec)

Thank you for the assistance.

Glenn

 

[footpad]

Glenn,

Glad to hear it worked.

If possible, you may wish to explore replacing your setGenFilter() calls with setRange(). This will require a secondary index containing your linking field as the first field, but it will dramatically improve performance, especially in a multi-user environment.

The reason for the improved performance stems from the fact that filters do not use indexes to locate records. Instead, they're equivelent to running separate queries for each record in the table. In multi-user environments, this takes a lot more time than setRange()--especially when you have a lot of records in the table.

As an example, I once worked on an application that originally used ranges to locate records in a table contains 250K records. It took roughly seven minutes for the form to open. When we redesigned the application to use ranges instead, the form opened in less than one second. Yes, this is an extreme example, but I've regularly noticed performance increases ranging from 10 to fifty times the original performance.

Filters are fine for single user environments using small datasets, but performance quickly becomes unbearable as the database grows.

Hope this helps...

-- Lance