Here's an easy one for someone...

[GWhiz]

Hi, folks!

This ought to be easy -- but it's challenging my grip on reality (assuming, of course, I had a grip to begin with):

I have a form with fields on it bound to a query containing a single table. I can change values in the fields just fine (new value replaces old value in the field being edited). But, when I exit the form (close the pop-up), then re-open or activate the form, all the fields that I changed have reverted to the old values. That is, the new values aren't saved. I get no error messages or burps of any kind -- it simply does not save the newly entered values.

I've already tried running DoCmd.RunCommand acCmdSaveRecord as the form is closing, and I've tried adding the "Save" extension or parameter to the "docmd.close" command that closes the form.

Form and query RecordsetType values both have been set to Dynaset (Inconsistent Updates).

The form WILL save the new values if I use the PageUp/PageDown keys to move to another record and back before closing the form (Access default behavior) -- but this does NOT work if I run...

DoCmd.RunCommand acCmdRecordsGoToNext
DoCmd.RunCommand acCmdRecordsGoToPrevious

...when I close the form.

So the question is: What is the simple, reliable way to save changes to a record without having to go to the next record, and without using Save Record from the Records Menu? Isn't there, or shouldn't there be, a simple, single line statement that forces all changed values in bound fields to be saved on demand? Isn't the .Dirty property supposed to go True whenever there's a difference between the value in a bound field from a recordsource, and a NEW value entered in the field as the record is edited?

I'm closing the form using the form's KeyPress event triggered by the Escape key. It's obviously being executed correctly, because the form closes on command as expected, executing all other code in the process (except anything having to do with saving the record). Is there some other underlying invisible "safety" code executed when using the Escape key to close the form that overrides any code that tries to save records? Or maybe it's a bug that prevents explicit efforts to save records in certain situations.

I'm embarrassed at the huge number of hours that this particular problem has caused me to spend trying to do something so incredibly simple.

Thanks so much, folks.

Respectfully,

GWhiz

 

[jebry]

Hi!

Let us see the code you use to open the popup form and any code that associated with the popup form.



Jeff Bridgham
bridgham@purdue.edu

 

[GWhiz]

Jeff:

Hi. Thanks for responding.

There's NO code being executed when I open the form. The form opens normally and displays the correct record (based on the value in a control on another form which sets the criteria in the query). That's what's got me boondoggled -- there's nothing going on which sets this form apart from any other, other than the fact that this particular requirement isn't followed by moving to another record before closing the form, so it never activates the default save that Access executes when moving to other records. I've had this particular problem for a long time, but most of the time there's something else that I'm doing with other forms (such as moving to another record) that causes the record to be saved automatically, so there is no requirement to save it on the fly like I'm trying to do here. The requirement here is to open the form, change some values, then close the form, saving any changes in the process (without moving to another record).

It could be as simple as something that I just don't get about the way Access saves records, so I'm trying to understand everything from an erroneous assumption to begin with. And, for the life of me, I can't figure out what I'm assuming that is causing the problem!

GWhiz

 

[jebry]

Hi!

Well, since you are not closing the original form Access doesn't know about the change in the record source until you do something in the original form. You can add a Me.Refresh which will refresh the information in the form but I think it goes back to the first record instead of staying on the current record.

hth
P.S. If you want me to look at the Db, you can zip it and email it to me.


Jeff Bridgham
bridgham@purdue.edu

 

[GWhiz]

Hmmm...not quite sure I follow you here, at least in the context of how this is organized. The form that doesn't work accesses records through a query that's based on a table that has no links/connections/relationships with any other table in the database. So, for all practical purposes, it's as if it's the only form and table in the entire database. While it is true that the criteria for the query is set by another form, that's no more than just a filter that tells the form which record in the stand-alone table to display, so it pops-up displaying the correct record (all of which works just fine).

So, the way I understand it, this IS an "original" form as far as Access is concerned -- it's the only one working on that particular table, the table isn't used or accessed by any other form, so it seems that it should save any changes every time I close the form. And it DOES save just fine, but only if I move to another record in that form before I close it. So, it seems to be operating "normally" -- but it simply refuses to see any explicit command to save the record, and doesn't even trigger any kind of error to let me know it can't be saved or that it's trying to execute bogus code.

The Me.Refresh is something else that I've already tried, to no avail -- and I just don't understand why any explicit save record command isn't working, and why I'm not getting any error messages when it doesn't.

The only clue may be that the Me.Dirty property never goes True even after the data in several bound fields on the form is changed -- which tells me that Access thinks there are no changes to be saved, regardless of what the fields are displaying relative to the data in the underlying table.

It's got to be something VERY simple -- but it's got me climbing the walls. And I know there are a couple of computers that are fearing for their lives.

Then again -- aggravation seems to be par for the course in the programming business.

Respectfully,

GWhiz