I would not use the lost focus, since that always occurs when the users
moves out of the control on the form in question.
You want to likely use the after update event (which does not fire if the
user enters..and then exits the field without any changes).
So, lets now assume we talking about the after update event.
in the after update event of the date field, you can run your processing
code.
Perhaps this code is a bunch of sql statements and updates to other tables.
Typically
you can leave the code in the forms module, or move out the processing code
into a standard code module. (this would be a good idea if you plan to
call/use the code in more then one place in the application).
> However, I need to do this for several hundred records so I want to
> automate it from a separate form.
Now you lost me? What do you mean separate form? I thought we just decided
went he user updates the date value, then we going to run some update code?
What does this have to do with another form??? (you are confusing me now).
As mentioned, you can run code that updates data..and that code does not
have to belong, or have ANY relation to a particular form. Code can well
update data...and does not have to use a form, or controls on a form to
modify data.
> I can change the value, but it
> doesn't fire the changed event.
Changing values in code does not trigger the event code (can you imagine
trying to run code that changes a bunch of values on a form???).
You might want to just explain what the update is supposed to do after the
date field is changed...
Typical to update tables via code, we use sql statements in code, or in some
cases reocrdsets. not knowing what kind of update you need here, it hard to
guess which approach is better...

Signature
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@msn.com
rrwyatt@yahoo.com - 25 Jul 2007 16:29 GMT
On Jul 24, 6:39 pm, "Albert D. Kallal" <PleaseNOOOsPAMmkal...@msn.com>
wrote:
> I would not use the lost focus, since that always occurs when the users
> moves out of the control on the form in question.
[quoted text clipped - 41 lines]
> Edmonton, Alberta Canada
> pleaseNOOSpamKal...@msn.com
I'll try to explain. In 'normal' mode everything works fine. User
selects (on form A) from a bunch of records and form B comes up. If
the user changes for B, the (you're right) after-updated event does a
ton of processing.
The trouble is I want the same processing without the user touching
anything. Esssntially emulating if a user had done this hundreds of
times. The external form is to skip form A and call form B for each
of the hundreds of records and trigger the after_update event as if a
user had entered it. Trying to emulate the code in that event would
very difficult as it is extemely funky.
Albert D. Kallal - 25 Jul 2007 23:13 GMT
Ok, so, in effect, we could launch a simple form with a button on it, and
when pressed, it would process a given set of records..and runt he code for
each record.
a typical update in code looks like:
dim strSql as string
strSql = "update tblCustomers set City = 'New York'" & _
" where city = 'N.Y.'"
currentdb.Execute strSql
So, the above would look for all records that are "N.Y.", and update them to
the full name of "New York"
So, typical the processing of data is done with sql. You can like build a
query that joins together the two tables you need, and use a single update
as above (your ability to do this is going depend on your sql skills).
Another approach (one we might have to use) is to use a reocrdset, and that
allows us to process each record by record.
Sub MyProcess()
Dim rstParent As DAO.Recordset
Dim strSql As String
Dim lngID As Long
strSql = "select * from tblMain where active = true"
Set rstpartent = CurrentDb.OpenRecordset(strSql)
Do While rstParent.EOF = False
rstParent.Edit
rstParent!Active = False
rstParent.Update
rstParent.MoveNext
Loop
rstParent.Close
End Sub
The above processing loop would take each record, and set the "active" field
to false.
The above is not the best example since we could use a single sql update
statement such as
currentdb.execute "update tblMain set active = false where active = true"
So, using sql update statements is preferred.
In your example, it seems we have a set of "main" records, and for each main
record, we need to execute a update on the child records. Hence, we could
use something like:
Sub MyProcess()
Dim rstParent As DAO.Recordset
Dim strSql As String
Dim lngID As Long
strSql = "select * from tblMain where active = true"
Set rstpartent = CurrentDb.OpenRecordset(strSql)
Do While rstParent.EOF = False
strSql = "update tblChild set somefield = somevalue " & _
" where main_id = " & rstParent!ID
CurrentDb.Execute strSql
rstParent.MoveNext
Loop
End Sub
so, you don't actualy "call" the after update code, but simply "reproduce"
the same code in the above loop to update the records in the manner in which
you need.
As a general rule, data processing code does not run, or use forms "after
update" event code. So, simply lay out the logic, and how the update is
supposed to work, and then write code as a above....
That is why I said it better to leave out the forms mumbo jumbo,a nd simple
state the problem:
eg:
for each active record in a main table, I need to update some
relented records in a child table.
Now, not being a mind reader, I don't know how you plan to select those
records that need updating..but the above gives the general idea....
If you are new to running update code, MAKE SURE you ALWAYS ALWAYS ALWAYS
make a backup..as this type of code can trash and "run over" data in a table
in a flash!!
So, in effect, the idea is not to run the after udpate code over and over,
but layout the problem at hand, and then write the code to solve that
problem...

Signature
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@msn.com