File Locking Error

[Ronald Frias]

I'm in the process of converting an Alpha 4 application to the current release of A5V5. The set consists of 4 DB files with cascading links. These files contain data placed by A4V6.2. After creating a new set form, I tried to edit an existing record and got an unrecoverable error.
"File locking record count exeeds max: 512". I have addressed these limitations in A4 but I can't find how to increase this limit in A5V5. Any suggestions?

[Tom Cone Jr]

Ronald, I recall a similar message thread in the Version Four forum. Here's what Dr. Wayne said over there:

Msg ID: 40652
Subject: RE: Is this a
Author: Peter Wayne
Date: 05-04-2001 6:24 AM
File:

When you change a parent record in a set with referential
integrity enforced, a5 has to lock all the child records.
you have probably run into the limit of the number of
child records that can be locked at a time.

it is rarely necessary to use referential integrity in
your sets. if you keep the user from ever changing the
linking keys then it is not necessary to use r.i. and your
application will run much faster, since you free a5 of
the overhead of locking child records.



If you're designing for a multi-user network setting you really don't want to lock all four of the tables in your set, and all the linked child records, when the user starts to edit the parent table do you? I would think your users would howl at being locked out of so many records. If you're not familiar with the collection of articles at www.learnalpha.com I recommend it to you. There's a good one on point called 'Simplify Your Application Design' which might be of much help to you.

-- tom

[Ronald Frias]

Hi Tom,

Thank you for your thorough analysis.

I have only two reasons for using referential "enforced". First one is to have the key fields fill in automatically when creating new child records. Second one is to change, in one step, all "child" key fields if I should need to change the parent's key field.

Are there other ways to accomplish the same? Do you think it is practical to turn on/off the referential setting when key field changes are needed?

Ron

[Jim Chapman]

Hello Ron,

In general you should never change the linking field of the parent. The linking field value should not be part of your data. It should be a unique value divorsed from any of your data. This is what the auto incremented field rule can be used for.

Even without referential integrity, child records added while in the set will 'inherit' the parent's linking value.

Good Luck,
Jim

[Ronald Frias]

Hi Jim,

Thank you for your interesting suggestion.

Is there a field rule that defines a child's (non-key)field value to be the same as it's parent, such that when you change the parents value, it will also change the childen's value in one step?

Ron