Saving changes to current record before printing

  • Thread starter Thread starter hughess7
  • Start date Start date
H

hughess7

Hi all

I have a button to preview a report but when the user changes a record and
presses the button, the changes are not shown on the report. I know this is
because the record has not been saved yet but forcing a save in the code
before the preview command does not work. Is it because the button is in the
footer of a continuous form?
Thanks in advance for any help.
Sue
 
Add either of these lines to your button's Click event procedure code:

If Me.Dirty Then Me.Dirty = False

If Me.dirty Then RunCommand acCmdSaveRecord

Here's an example that checks for that and other issues:
Print the record in the form
at:
http://allenbrowne.com/casu-15.html
 
Thanks this is what I had but it wasn't working, I just realised why though
sorry! It was because I had a call to another routine creating my report and
it needed to be placed before this line and not after it. Sorry, thanks Allen
anyway. As ever a prompt efficient working solution presented :-).

Sue
 
Add either of these lines to your button's Click event procedure
code:

If Me.Dirty Then Me.Dirty = False

If Me.dirty Then RunCommand acCmdSaveRecord
Click to expand...

Are there situations where the latter will not work but the former
will?

[and it should be:

If Me.dirty Then DoCmd.RunCommand acCmdSaveRecord]

I'm asking because RunCommand is a programmatic interface to the
actions available from the Access menu (I think it runs the same
"macros" as the menu commands do), so if the menu command is not
available, then the RunCommand will fail. I don't know for certain
if Me.Dirty = False can be called in circumstances where commands
for saving a record are not available from the default menus.
 
The later won't save the record if the form does not have focus.

I think you'll find that RunCommand will work will work okay without DoCmd.

AFAIK, testing a form's Dirty property should work any time (assuming it's a
bound form.)

--
Allen Browne - Microsoft MVP. Perth, Western Australia

Reply to group, rather than allenbrowne at mvps dot org.

David W. Fenton said:
Add either of these lines to your button's Click event procedure
code:

If Me.Dirty Then Me.Dirty = False

If Me.dirty Then RunCommand acCmdSaveRecord
Click to expand...

Are there situations where the latter will not work but the former
will?

[and it should be:

If Me.dirty Then DoCmd.RunCommand acCmdSaveRecord]

I'm asking because RunCommand is a programmatic interface to the
actions available from the Access menu (I think it runs the same
"macros" as the menu commands do), so if the menu command is not
available, then the RunCommand will fail. I don't know for certain
if Me.Dirty = False can be called in circumstances where commands
for saving a record are not available from the default menus.
Click to expand...
 
The later won't save the record if the form does not have focus.
Click to expand...

You mean RunCommand, I assume. I don't like using commands where I
have to do extra work to make sure the command operates on the right
object. I've always mistrusted RunCommand and have always been
annoyed that there's no way to delete a record in a form
programmatically in one line of code without using it. Why can't
there be a Me.DeleteCurrentRecord method?
I think you'll find that RunCommand will work will work okay
without DoCmd.
Click to expand...

I wouldn't say it's advisable, though. That would imply that all
DoCmd methods would work without it, no?
AFAIK, testing a form's Dirty property should work any time
(assuming it's a bound form.)
Click to expand...

If you're testing the form's Dirty property, why not use that
property to save the record?

Of course, it's always seemed counterintuitive to me that the Dirty
property would not be read-only, but I'm glad it isn't.
 
Back
Top