When are changes saved to table?

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

Guest

Hello,

I was looking at a form I have with an option group and a hidden text box
[bound] that becomes visible depending on the state of the option group, and
I noticed that the underlying query/table didn't get updated immediately
after something was changed.
In fact, I'm not sure at what point a change does get committed to the query.

Is there a way to ensure that it's done right away?
I'm concerned that if a users edits the text box, or selects another option,
and then prints a reports right afterwards, that the report will still show
the old, pre-editing state of the table.

Thank you.
 
Niniel said:
Hello,

I was looking at a form I have with an option group and a hidden text
box [bound] that becomes visible depending on the state of the option
group, and I noticed that the underlying query/table didn't get
updated immediately after something was changed.
In fact, I'm not sure at what point a change does get committed to
the query.

Is there a way to ensure that it's done right away?
I'm concerned that if a users edits the text box, or selects another
option, and then prints a reports right afterwards, that the report
will still show the old, pre-editing state of the table.

Thank you.

Records are saved when you leave the record (move to a different one) or
close the form.
 
Is there a way to ensure that it's done right away?
I'm concerned that if a users edits the text box, or selects another
option,
and then prints a reports right afterwards, that the report will still
show
the old, pre-editing state of the table.

The above is correct. There is no need to "force" a disk write of data UNTIL
the user actually tries to print..

So, simply place some code with your "report print" button. The reason why
the record is not committed is that then the user can un-do their changes.

So, right before you launch the report, simply write the data to disk:

eg:

if me.dirty = True then
' pending data to write to disk
me.dirty = false\
end if

--- you code to print report goes here....
 
So I can't do anything about it?
I noticed that the changes do show up after I tab out of the last text box
on the tab, or after I go to a different tab [same record]. But if I just
change the content of the text box and then open the report, I get the old
information.
 
Per Niniel:
So I can't do anything about it?

You could force a save by writing some code
for txtWhatever_Exit().

Namely: DoCmd.RunCommand acCmdSaveRecord
 
For this particular case, I recommend the code be put in as part of the
CommandButtonToOpenReport_Click Event.

Check whether Form's Dirty is true on not and if it's true, use
acCmdSaveRecord before the OpenForm statement.
 
Thanks a lot for the advice!

One last question - is there any particular reason why it's better to save
only if something has changed? Does saving the record take so much time that
it's not advisable to just save every time I click on the button?
 
Oh, and also - on my form, I have some text boxes that are only made visible
if certain checkboxes are checked.
Is that also something that can be duplicated on a report, or will the
textboxes have to be visible all the time?
 
Niniel said:
Thanks a lot for the advice!

One last question - is there any particular reason why it's better to save
only if something has changed? Does saving the record take so much time
that
it's not advisable to just save every time I click on the button?

You could save every time, and in fact for a good number of years, I always
used the follwing code to print the ONE reocrd I am looking at:


me.refresh
docmd.OpenReprot "customers",acViewPreview,,"id = " & me!id

The above me.refresh also cases a disk write if the reocrd is dirty. Now,
the me.refresh can cause more i/o then just the disk write, so the "me.drty"
code snip is useally perffered (but, since my forms ONLY are loaded to one
reocrd for reasons of good design/perfmaonce, then me.refresh is not a bad
choice in my case).

I not quite sure of your question, but the suggested code to save was:


if me.dirty = True then
me.dirty = false
end if

Are you suggesting that you reduce the above code to:

me.dirty = false

I don't see a "bug huge" savings in code. So, I not 100% sure of your
question on saving each time. You can, but the given code snip only saves if
you need to. I not much thought about this, but you likely could just use
the one line of code, but the if.....end if block of code is VERY clear to
read, and conveys quite well what the programmer (you) intentions were/are.

Oh, and also - on my form, I have some text boxes that are only made
visible
if certain checkboxes are checked.
Is that also something that can be duplicated on a report, or will the
textboxes have to be visible all the time?

yes, on your reports 'on format' event, you can put the code

if me.SomeCheckBox = true then
me.SomeTextBox.visible = false
else
me.sometextbox.visible = true
end if

Do the above type of code for each check box you need. Note that you use the
"details" section format event of your report to do this..
 
I'm glad to hear it can be done, thank you.

Regarding the code for the dirty event, I hadn't really asked a question
about it. :) I was simply wondering if it would be bad to just add the save
command to the button without checking for dirty first, essentially saving
every time the report was printed.
Although I have to admit that I was puzzled to see "iff me.dirty=true then
me.dirty=false".
So what I ended up using is this: "iff me.dirty=true then DoCmd.RunCommand
acCmdSaveRecord end if"
 
pete you sure about that?

I hadn't seen that one before; is it new?

I've always had to use the DoMenuItem command that is generated by the
command button wizard

-Aaron
 
Per (e-mail address removed):
I hadn't seen that one before; is it new?

I've always had to use the DoMenuItem command that is generated by the
command button wizard

I think it's the same thing - just a newer syntax that became available sometime
in the last couple of versions. Several of those commands became available via
DoCmd.
 
yeah.. just wish it was documented

I must have missed that memo lol

-Aaron
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Back
Top