At 03:13 PM 2/06/2004 +0000, you wrote:

>Hi,
>
>I am just finishing up my application, and I have enabled pesimisstic
>locking to prevent conflicts. I have 4 tables that are related like this:
>
> ----------- ----------- -----------
>| Client | | Docket | | TimeEntry |
> ----------- ----------- -----------
>| Firsname | | Docket# |>> | Docket# |
>| Lastname | | Date | | | Date |
>| Phone | | Closed | | | Time |
>| ... | | ... | | | CostHr |
>| SocialSec |>>| SocialSec | | | ... |
> ___________ ----------- | -----------
> |
> | -----------
> | | Disburs |
> | -----------
> 1 >> many >>| Docket# |
> | Date |
> | Amount |
> | ... |
> -----------
>
>So multiple dockets can be attached to a client, and multiple
>time/disbursement entries can be on a docket. I need to stop users
>from being able to delete a docket while someone is working on a Time
>Entry or Disbursement, or stop them from deleting a client while
>someone is working on a docket.
>
>I apologize if this is an sql question.

It is, mostly. All you need is foreign keys all the way down the line and
the referential integrity of the related tables will be protected.

>I am not sure if this is
>something IBObjects would handle, or whether I would have to impose
>some relations the opposite direction to stop it?

The opposite direction to what?

If you implement regular RI, it will be impossible to delete the
higher-level rows if something at the lower level has an update
pending. It is not the client (IBO) that enforces this, but the server.

IBO *does* have its part to play. You will need statement-level (i.e.
IBO-style) pess. locking on each lower-level member to ensure that the
intention to update becomes visible to the server as soon as the
client-side goes into Edit.

Helen