Forcing a record write with a form button?

[+Bob+]

I have a form that has buttons that call other forms (not subforms,
completely separate forms to be opened, but accessing some of the same
data). When the user clicks the button on the primary form to bring up
one of the other forms, I need to force the primary record to be
updated to avoid a later update conflict.

I know where to put the code/statement I need, but I don't know what
the actual statement is to force an update of the displayed record.

Thanks,

 

[Rick Brandt]

I have a form that has buttons that call other forms (not subforms,
completely separate forms to be opened, but accessing some of the same
data). When the user clicks the button on the primary form to bring up
one of the other forms, I need to force the primary record to be
updated to avoid a later update conflict.

I know where to put the code/statement I need, but I don't know what
the actual statement is to force an update of the displayed record.

Thanks,

Me.Dirty = False

 

[+Bob+]

Me.Dirty = False

Ur gonna have to explain that

 

[+Bob+]

On Sun, 10 Jun 2007 07:42:20 -0500, "Rick Brandt"


Ur gonna have to explain that

I think I figured out what you were saying right after I posted... but
you might be answering a different question.

Effectively what I want to do is have a button on a form that forces
Access to write the record displayed to the disk (or cache, logical
disk for me) immediately when I click on it. I don't want to have to
close the form to cause the write. The data in the form _is_ changed
when I want to do this. I just need to force the write to the
disk/table on demand.

 

[John W. Vinson]

Effectively what I want to do is have a button on a form that forces
Access to write the record displayed to the disk (or cache, logical
disk for me) immediately when I click on it.

That button's Click event should be:

Private Sub cmdSave_Click()
If Me.Dirty Then Me.Dirty = False
End Sub

This will write the record to disk if it's been dirtied, and will not close
the form.

John W. Vinson [MVP]

 

[+Bob+]

That button's Click event should be:

Private Sub cmdSave_Click()
If Me.Dirty Then Me.Dirty = False
End Sub

This will write the record to disk if it's been dirtied, and will not close
the form.

I'll accept that if you say it and try it out... but what triggers the
write? Just setting me.dirty to false?

I was figuring that I'd need a piece of code that had the word "write"
in it

 

[Rick Brandt]

I'll accept that if you say it and try it out... but what triggers the
write? Just setting me.dirty to false?

I was figuring that I'd need a piece of code that had the word "write"
in it

A "dirty" record is one which has unsaved changes in it. Setting Dirty to False
forces those changes to be committed in order to make the record "clean".

You can also use...

DoCmd.RunCommand acCmdSaveRecord

 

[Taylor Mobley]

yes

I'll accept that if you say it and try it out... but what triggers the
write? Just setting me.dirty to false?

I was figuring that I'd need a piece of code that had the word "write"
in it

 

[+Bob+]

A "dirty" record is one which has unsaved changes in it. Setting Dirty to False
forces those changes to be committed in order to make the record "clean".

Yeah... it worked. So I'm all set. Can't argue with success.

This still seem double back asswards though. First, the record has
already been changed by the user (dirty?) but Access does not write it
when the next form is called - unless I take some additional manual
action. Not ideal, but acceptable and perhaps even logical. Next
though, you'd think I would have to set the property to "dirty" to
cause Access to force a write - instead I set it to "not dirty" and
Access writes it. Strange, almost "WTF?". Third, changing a property
causes a method to execute? Another "WTF?" Finally, what would you do
if you want to intentionally discard changes, since setting the
property to "not dirty" causes a write?

I admit to not knowing much about this area... but it doesn't seem
like an engineer with object oriented experience designed this
Enlighten me if you can!




This still seems very odd though - setting a property of a record to
false causing a method to be executed. After all, the record was
actually changed - but Why would setting a property of an object
cause a method to be executed?

 

[Rick Brandt]

Yeah... it worked. So I'm all set. Can't argue with success.

This still seem double back asswards though. First, the record has
already been changed by the user (dirty?) but Access does not write it
when the next form is called - unless I take some additional manual
action. Not ideal, but acceptable and perhaps even logical.

It would automatically save if you closed the form displaying the dirty
record or moved to a different record. Opening a completely different form
though would not cause anything to happne on the first form. If you think
about it there would be LOTS of sitiuations where that would be undesired
behavior.

Next
though, you'd think I would have to set the property to "dirty" to
cause Access to force a write - instead I set it to "not dirty" and
Access writes it.

Not if you realize that "dirty" means "contains unsaved changes".

Strange, almost "WTF?". Third, changing a property
causes a method to execute? Another "WTF?" Finally, what would you do
if you want to intentionally discard changes, since setting the
property to "not dirty" causes a write?

You would issue the Undo method on the form...

Me.Undo

I admit to not knowing much about this area... but it doesn't seem
like an engineer with object oriented experience designed this
Enlighten me if you can!

This still seems very odd though - setting a property of a record to
false causing a method to be executed. After all, the record was
actually changed - but Why would setting a property of an object
cause a method to be executed?

That is a bit unorthodox, but as you say "it works". As I posted earlier
you can also use...

DoCmd.RunCommand acCmdSaveRecord

I prefer Me.Dirty = False for two main reasons...

1) It's less to type.

2) The SaveRecord command will operate on whatever form has focus and in
some circumstances that will not be the form running the code. With
Me.Dirty = False I know exactly which form is having the save applied.

 

[+Bob+]

On Tue, 12 Jun 2007 10:33:19 -0500, "Rick Brandt"

Thanks for all the info.