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

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.


"Michel Walsh" wrote:

> 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
>
> "A.F." <A.F.@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> news:C98B944D-2CBF-4541-A7C1-B6648F31E5B3@xxxxxxxxxxxxxxxx
> > 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: fgnbmcs@xxxxxxxxxxxxxxxxxxxxxxxx (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/community/en-us/default.mspx?mid=c98b944d-2cbf-4541-a7c1-b6648f31e5b3&dg=microsoft.public.access.formscoding
>
>
>
.