Access Forms & control focus

[mdmilner]

I'm working on a small project that uses 4 tables to hold all records related to a specific event. Two (#2 #3) are in a direct Cascade Update/Delete relationship with the primary(#1). The last (#4) is in a Cascade Update/Delete relationship with one of those two (#2).

#1 one-to-many #3
#1 one-to-many #2
#2 one-to-many #4

All four tables are similary linked into a primary Data Entry form/subforms.
#2 and #3 are subforms of #1
#4 is a subform of #2

While testing, I've determined that should I move from Form #1 to Subform #4, the Keyfield does not update to Table #4. If I first focus on form #2 then move to form #4, the keyfield cascades down properly.

What is the best way to ensure that the keyfield values cascade down to #4 everytime?

Is my arrangement the best/easiest way to handle this?
-
Slightly different question.
It is my intention to use the above database as a client that passes data up to a shared network mdb file. I've written two different versions of a Public Function to pass the data to it. The first is basically walking the recordsets (DAO), while the second uses UPDATE(append) queries to do the same thing.

While I don't have any problem trapping key violation errors on the first method (walking recordset) - the Append queries are producing the standard "one was not updated) message and I'm not clear how to trap that at this point. The user can just answer the prompt, but I'd rather not leave it there. I'm going to push the client piece into a runtime and noticed how the documentation clearly warns you 'unhandled errors crash'.

Can the append (key violations) message be suspended? Should I?
If necessary, I could make the mdb available for a look (Access2K) but I'm just looking for advice.

Mike

 

[mdmilner]

Had some time to think about it today. For the first issue, I'm thinking about locking the controls on form/table#4 until some condition is met on form/table #2 (data-present which allows the cascade updates to occur)

For the second piece, even though it's slower, walking the recordset is going to probably be my choice. More control, and since the actual use will never involve huge amounts of data, nobody is really going to notice whether it takes .1 vs .2 seconds to update.

I'm still curious if I've done this right. Really, I've spent remarkably little time working with forms and all the various controls.

Mike