"Allen Browne" <AllenBrowne@SeeSig.Invalid> wrote in
news:424a3be6$0$13891$5a62ac22@per-qv1-newsreader-01.iinet.net.au:
[color=blue]
> David, thanks for sharing, and there are others (like Rog) who do
> that as well.
>
> Personally, I've never built a form like that (other than in a
> wizard-style database for novices).
>
> IMHO, the extra forms mean extra maintenance, . . .[/color]
There is no datasource, there are only 3 fields and it's a form for
a specific task. There is *no* maintenance issue involved, so far as
I can see.
[color=blue]
> . . . concurrency issues, . . .[/color]
It's unbound. There are no concurrency issues.
[color=blue]
> and inflexibility, . . . .[/color]
How is it inflexible?
[color=blue]
> . . . so I use a combination of events: the
> AfterUpdate of the control(s) involved in the index if we need
> immediate feedback, the error BeforeUpdate of the form to get a
> meaningful message, and the Error event of the form in case I
> missed something or business rules/validation/indexes are changed
> after the database is out of my hands.[/color]
I can never control the interaction of events sufficiently to not
end up with extremely Byzantine code in the form. The main reason
for that is that the user is not restricted to an order of events in
adding a record when you use the same form for both adding and
editing. Using an unbound dialog to collect the required fields and
then test them against existing data makes means you have strict
control over the fields that matter for the add record process.
Now, of course, I wouldn't create a separate form with 5 required
fields for a table that has only 6 fields total. What I'm talking
about is adding records to tables with a handful of required fields
in comparison to the total number of data controls on the main data
editing form. It's a lot easier to handle those three fields in the
add record form and then tailor the form with 35 fields and 3
subforms to do what it does best, edit existing records.
I think the main reason I approach it this way is simply because of
the cost of cancelling a record addition. If you're letting the
record be created, then you've got issues with your surrogate keys
(whether or not you're incrementing them yourself), as well as the
huge data hit of having updated indexes and then backing that out
(which requires index updates again). Using a unique index to
prevent duplicates is only possible for certain kinds of data
entities, and I'm philosophically opposed to the approach of "stick
the data in and do something about it if it throws and error"
because those errors are very expensive in terms of tying up the
database back end -- writes are more expensive than reads, and my
solution does no writing until it's already been confirmed that the
record is OK to add.
Now, all that said, I mostly only use this approach for adding
people, since that's the most common scenario where possible
duplicates are likely.
--
David W. Fenton
http://www.bway.net/~dfenton
dfenton at bway dot net
http://www.bway.net/~dfassoc 
