Force a save

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

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
 
Fredrated said:
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
Click to expand...

You can use either:

DoCmd.RunCommand acCmdSaveRecord

or

Me.Dirty = False
 
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
 
Klatuu said:
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
Click to expand...

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)
 
Isn't really needed, but is saves an unnecessary database hit.
(I'm here to learn as much as to help)
Click to expand...

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.
 
Comments inline:

Klatuu said:
Isn't really needed, but is saves an unnecessary database hit.
Click to expand...

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.
Click to expand...

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.
 
Klatuu said:
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.
Click to expand...


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.
 
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.
 
Marshall Barton said:
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.
Click to expand...

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.
 
Klatuu said:
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.
Click to expand...


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 :-\
 
Stuart said:
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.
Click to expand...


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.
 
In
Marshall Barton said:
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.
Click to expand...

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.
 
Is there a database hit? Seem like it would only be
Click to expand...

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.
Click to expand...

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.
 
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


Stuart McCall said:
Is there a database hit? Seem like it would only be
Click to expand...

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.
Click to expand...

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.
Click to expand...
 
Klatuu said:
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
Click to expand...

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
Click to expand...

"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.
Click to expand...

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.
Click to expand...
 
Klatuu said:
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.
Click to expand...


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.
 
Stuart said:
"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 :-)
Click to expand...

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.
Click to expand...


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.
 
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.
Click to expand...

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."
 
Back
Top