Force a save

[Guest]

Isn't there a docmd command that will force an edited record to be updated
(ie, changes saved)?

I have a form where a user checks off which records are to be processed,
then clicks a button to proceed with the processing. Problem is, the system
doesn't see the last box checked off as having value 'true' unless the user
clicks somewhere else that forces the edited record to be saved. I would
like to do this programmatically before the processing is kicked off.

Thanks!
Fred

 

[Guest]

DoCmd.DoMenuItem acFormBar, acRecordsMenu, acSaveRecord, , acMenuVer70

 

[Stuart McCall]

Isn't there a docmd command that will force an edited record to be updated
(ie, changes saved)?

I have a form where a user checks off which records are to be processed,
then clicks a button to proceed with the processing. Problem is, the
system
doesn't see the last box checked off as having value 'true' unless the
user
clicks somewhere else that forces the edited record to be saved. I would
like to do this programmatically before the processing is kicked off.

Thanks!
Fred

You can use either:

DoCmd.RunCommand acCmdSaveRecord

or

Me.Dirty = False

 

[Guest]

Sorry, but Lance and Stuart have both given methods that are no longer used.
They are only supported for backward compatibiity. Microsoft suggests they
not be used any longer.

The better syntax is:

If Me.Dirty Then
Me.Dirty = False
End if

 

[Stuart McCall]

Sorry, but Lance and Stuart have both given methods that are no longer
used.
They are only supported for backward compatibiity. Microsoft suggests
they
not be used any longer.

The better syntax is:

If Me.Dirty Then
Me.Dirty = False
End if

Any idea why the test is needed when Me.Dirty = False doesn't raise an error
if it's already False?

(I'm here to learn as much as to help)

 

[Guest]

Isn't really needed, but is saves an unnecessary database hit.

(I'm here to learn as much as to help)

Me, too. 90% of what I know about Access I learned in these newsgroups.

Please don't be offended, I don't mean to belittle, just trying to get the
best info to the OP. You would not believe how many times Doug Steele
corrected me.

 

[Stuart McCall]

Comments inline:

Isn't really needed, but is saves an unnecessary database hit.

Gotcha. Its so obvious now you mention it. A lesson learned. Thanks.

"For every problem, there is one solution which is simple, neat and wrong."

Me, too. 90% of what I know about Access I learned in these newsgroups.

Please don't be offended, I don't mean to belittle, just trying to get the
best info to the OP. You would not believe how many times Doug Steele
corrected me.

You'll have to try much harder than that to offend me. I'm far too long in
the tooth to be 'belittled' by a simple correction.

 

[Marshall Barton]

Isn't really needed, but is saves an unnecessary database hit.


Me, too. 90% of what I know about Access I learned in these newsgroups.

Please don't be offended, I don't mean to belittle, just trying to get the
best info to the OP. You would not believe how many times Doug Steele
corrected me.

Dave, I use the same line to save a record, but I have never
heard anyone claim that Me.Dirty=False actually tries to
save a record when Dirty is already False. I test it first,
but only because I am not sure what's really going on behind
the scenes. Obscure question: does a form's AfterUpdate
event fire when dirty was False?

In the old days ;-), that's the kind of question that
Michka would have provided us with a definitive answer, but
he's off to other areas now.

 

[Guest]

Don't do this to me. Now I will be up all weekend trying to figure it out.

One other point, however. Although I try to put efficieny at the top of my
criteria, the number two criteria for me is readablity. I try to keep my code
as easy to read as possilbe. Some other poor slob may have to work with it
in the future and I may have to go back and work with it six months from now.

 

[Stuart McCall]

Dave, I use the same line to save a record, but I have never
heard anyone claim that Me.Dirty=False actually tries to
save a record when Dirty is already False. I test it first,
but only because I am not sure what's really going on behind
the scenes. Obscure question: does a form's AfterUpdate
event fire when dirty was False?

In the old days ;-), that's the kind of question that
Michka would have provided us with a definitive answer, but
he's off to other areas now.

I was wondering if the database hit was caused by Access checking for
changes against the datasource, rather than comparing to the OldValue's...

I miss Mr Kaplan's insight too.

 

[Marshall Barton]

Don't do this to me. Now I will be up all weekend trying to figure it out.

One other point, however. Although I try to put efficieny at the top of my
criteria, the number two criteria for me is readablity. I try to keep my code
as easy to read as possilbe. Some other poor slob may have to work with it
in the future and I may have to go back and work with it six months from now.

I'm sorry about your upcoming loss of sleep ;-)

Readability is probably my only good reason for using:
If Me.Dirty Then MeDirty = False
and it's only in my mind that I immediately recognize the
line as "save the record", where I have to do a double take
to get the same meaning from:
Me.Dirty = False

I don't know about others, but I have always had what I call
"mental macros" where I look at a smallish block of code,
recognize its meaning and move on without checking its
specific details. Of course this habit creates its own set
of blind spots when something doesn't work :-\

 

[Marshall Barton]

I was wondering if the database hit was caused by Access checking for
changes against the datasource, rather than comparing to the OldValue's...

I miss Mr Kaplan's insight too.

Is there a database hit? Seem like it would only be
necessary for Access to check if Dirty = False before trying
to save the record, While I have no idea what Access is
doing in its internal code, it would be logical for Access
to do the same check we normally do.

OTOH, if by "database hit", you mean the transition to an
internal property let procedure, then I doubt if it cost a
measurable amount of time over the transition to the
internal property get to test the value of Dirty.

 

[Dirk Goldgar]

In

Is there a database hit? Seem like it would only be
necessary for Access to check if Dirty = False before trying
to save the record, While I have no idea what Access is
doing in its internal code, it would be logical for Access
to do the same check we normally do.

OTOH, if by "database hit", you mean the transition to an
internal property let procedure, then I doubt if it cost a
measurable amount of time over the transition to the
internal property get to test the value of Dirty.

For what it's worth, I did benchmark test some time ago to see if it
made a difference, and I found that, if the record is not dirty,
checking the property before assigning to it (i.e., "If Me.Dirty Then
Me.Dirty = False") was marginally faster. So that's what I do, not that
it makes any significant difference.

 

[Stuart McCall]

Is there a database hit? Seem like it would only be

Don't know. Dave raised the point.

necessary for Access to check if Dirty = False before trying
to save the record, While I have no idea what Access is
doing in its internal code, it would be logical for Access
to do the same check we normally do.

OTOH, if by "database hit", you mean the transition to an
internal property let procedure, then I doubt if it cost a
measurable amount of time over the transition to the
internal property get to test the value of Dirty.

No argument there. And I don't _mean_ anything by "database hit". Again,
Dave brought it up. I was responding by thinking aloud, so to speak.

 

[Guest]

Yes I did.
What I mean when I say "database hit" might be better labled "disc access".
That is the time for the update to actually write the changes to the disc.

My thinking is that Dirty is a property of the form. So the it knows
whether there are unapplied changes to its recordset. It would seem logical
to me that explicitly writing data to the disc would be slower over all than
first checking to see if the data has changed. Of course, if the data has
changed then you loose the time to check the property (not much), but if the
data has not changed, you waste the time to do the disc write (a bit more).
So my guess would be that on average, checking first would be faster.

I would welcome comments on this.
--
Dave Hargis, Microsoft Access MVP

Is there a database hit? Seem like it would only be

Don't know. Dave raised the point.

necessary for Access to check if Dirty = False before trying
to save the record, While I have no idea what Access is
doing in its internal code, it would be logical for Access
to do the same check we normally do.

OTOH, if by "database hit", you mean the transition to an
internal property let procedure, then I doubt if it cost a
measurable amount of time over the transition to the
internal property get to test the value of Dirty.

No argument there. And I don't _mean_ anything by "database hit". Again,
Dave brought it up. I was responding by thinking aloud, so to speak.

 

[Stuart McCall]

Yes I did.
What I mean when I say "database hit" might be better labled "disc
access".
That is the time for the update to actually write the changes to the disc.

My thinking is that Dirty is a property of the form. So the it knows
whether there are unapplied changes to its recordset. It would seem
logical

Precisely. So if the command is issued, it ought to know to just ignore it,
which _seems_ to be the case. After Doug's interjection however, you would
appear to be right regarding the check (a real world test is king).

to me that explicitly writing data to the disc would be slower over all
than
first checking to see if the data has changed. Of course, if the data has
changed then you loose the time to check the property (not much), but if
the

"Not much" depending on how Access handles this internally. Does it set the
property on every keypress & mouse click, or does it run through the
OldValue's comparing them to the current text? I suspect the former, which
only serves to bolster your case

data has not changed, you waste the time to do the disc write (a bit
more).
So my guess would be that on average, checking first would be faster.

One last thing, regarding your earlier comment about code readability, it
seems a shame that RunCommand acCmdSaveRecord is being deprecated. It's
self-commenting code, and again if Access already knows there have been no
changes, it could just be ignored. That's the behaviour I'd like to see
anyway.

I would welcome comments on this.

 

[Marshall Barton]

Yes I did.
What I mean when I say "database hit" might be better labled "disc access".
That is the time for the update to actually write the changes to the disc.

My thinking is that Dirty is a property of the form. So the it knows
whether there are unapplied changes to its recordset. It would seem logical
to me that explicitly writing data to the disc would be slower over all than
first checking to see if the data has changed. Of course, if the data has
changed then you loose the time to check the property (not much), but if the
data has not changed, you waste the time to do the disc write (a bit more).
So my guess would be that on average, checking first would be faster.

I would welcome comments on this.

I seriously doubt, and I think Dirk confirmed it, that
Access will NOT write a clean record back to the table.

I think the only speed difference is whether the If Me.Dirty
is faster than the processing to transition to and execute
the internal code part of the Me.Dirty = False prior to the
record save, if needed. Dirk says it is slightly, but not
noticibly, faster.

Dirk,
Thanks for the info, at least now I can justify using the
more verbose statement ;-)

For those that prefer the more concise statement, I think
the small fraction of a microsecond that might have been
saved is unimportant.

 

[Marshall Barton]

"Klatuu" wrote

Precisely. So if the command is issued, it ought to know to just ignore it,
which _seems_ to be the case. After Doug's interjection however, you would
appear to be right regarding the check (a real world test is king).


"Not much" depending on how Access handles this internally. Does it set the
property on every keypress & mouse click, or does it run through the
OldValue's comparing them to the current text? I suspect the former, which
only serves to bolster your case

AFAIK, the record's original data is only used during the
save operation to determine if another user edited the same
record.

One last thing, regarding your earlier comment about code readability, it
seems a shame that RunCommand acCmdSaveRecord is being deprecated. It's
self-commenting code, and again if Access already knows there have been no
changes, it could just be ignored. That's the behaviour I'd like to see
anyway.

The BIG problem with the RunCommand (and many other DoCmd
methods) is that you can not specify which object you want
it to operate on. Impatient users randomly clicking and
Timer event are notorious for changing the current object
out from under your code.

IMO, these operations should be methods of the objects, not
something that simulates a user mouse click. The
intoduction of Me.Dirty = False, while an obscure syntax,
was definitely a step in the right direction.

 

[Stuart McCall]

Sorry Dirk for calling you Doug. Must have been having a senior moment.

 

[Stuart McCall]

The BIG problem with the RunCommand (and many other DoCmd
methods) is that you can not specify which object you want
it to operate on. Impatient users randomly clicking and
Timer event are notorious for changing the current object
out from under your code.

IMO, these operations should be methods of the objects, not
something that simulates a user mouse click. The
intoduction of Me.Dirty = False, while an obscure syntax,
was definitely a step in the right direction.

I agree (when I mentioned it I had intended to add "or something like it").
Me.RecordSave and Me.RecordChanged would have suited me better.

One of the Basic language's best points IMO is to be readable without dozens
of comments. With careful use of variable and method names, it can almost be
made to read like English (of a sort

Getting code to execute properly is only half the battle. Maintainability
later is the other half. If I use:

If Me.Dirty Then Me.Dirty = False

I am compelled to add the comment "If record changed, save it" (but maybe
that's just me).

As Dijkstra said, "The tools we use have a profound (and devious!) influence
on our thinking habits, and therefore, on our thinking abilities."