MSACCESS- add 2 events: duplicatekey and validate to form ect....

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,

I develop access solutions more then decade; those in the subject events in
bound form could reduce the programming term a lot. (I had DB (in bio/medical
environment) with ~700000 records with growth of ~5000 per week (now in
transition to SQLSVR)).
1. DuplicateKey- bound form level, will fire when duplicate problem due key
problem rise, it will let u know which exact key's is cause the violation.
2. Validate: form and field level (bound and unbound), let u logically
validate the content of field/ form before try to deal with the underlying
data storing.
3. Solve the cause to problem: Other user access the DB… (When there is no
one else!) When use multiply tables in single parent child database (it
enforce rewriting the entire screen unbound= a lot of wasting programming
time).

response: (e-mail address removed) (Amichai Feigenboim)



----------------
This post is a suggestion for Microsoft, and Microsoft responds to the
suggestions with the most votes. To vote for this suggestion, click the "I
Agree" button in the message pane. If you do not see the button, follow this
link to open the suggestion in the Microsoft Web-based Newsreader and then
click "I Agree" in the message pane.

http://www.microsoft.com/office/com...31e5b3&dg=microsoft.public.access.formscoding
 
Hi,

It seems the events and the tool already exist. Maybe you disregarded them,
not fully aware of their power.

1- Use the FORM onERROR event.

2- Use the Control BeforeUpdate event to make "personal" validations. In
general, you could use table design to enforce record level validation, or
field level validation... there, at the database level, and use the Form
onError event to eventually catch the problem if is it not catch before.

3- If the problem comes for user entry, the user should be responsible for
the data correction. If the problem come from appending a batch of record,
use a transaction, "log" the new records causing a problem in a table
outside the transaction, then rollback the transaction. The data won't be
appended (since the transaction has been rolled back), but the log (being
outside the transaction) would survived the rollback and let the "authority"
be in charge to solve the conflict. If you desire something more
"automatic", take a look at Replication, that is exactly doing that.



Hoping it may help,
Vanderghast, Access MVP
 
Thank 4 your reply Vanderghast,

I'm fully aware and for years used heavily those events u suggest.
I regularly do much more with them, but with this dedicated proposed events
,u could reduced the complexity of those (and other like) events u mention.

about 3. I personally think that the problem rise due the fact that the form
was tried to contain automatic Access handling of multiple levels (5) of
parent child relationships= master form, sub form, subsub form…
(Patient->symptoms->diseases-> physical evidences->medical backgrounds))
programming time.
(I personally think that the problem rise due the fact that the form was try
to contatin was try to handle automatically multiple levels (5) of parent
child relationships= master form, sub form, subsub form…
(Patient->symptoms->diesises-> physical evidences->medical backgrounds))


A.F.
 
Michel Walsh,

I'm sorry about miss mention your name in my previous response, in my daily
use Lang (Hebrew) the writer name appeared at end of text.

A.F.
 
Back
Top