Full Version: DoCmd.OpenForm issues
UtterAccess Forums > Microsoft® Access > Access Forms
bph
Has anyone had any problems when using Link Criteria (4th parameter) with the OpenForm method
I'm having problems (error is thrown) when trying to edit records (strangely some but not all) in the newly opened form after calling OpenForm.
If I don't specify any link criteria all records can be edited no problem but obviously it doesn't open immediately with the record I want.
The link criteria string is definitely correct in all cases, its not opening the form that is the issue, just updating the record after the form is opened - it actually hangs on a DoMenuItem save record call
I've spent 5 days straight on this issue and my brain is starting to bleed....
for more details see my other related posts:
thread link
regards,
Ben
strive4peace
try this method for saving your record:
If me.dirty then me.dirty = false
bph
hi

what does this statement actually do?

does it indirectly force a record save?

regards,
Ben
Edited by: bph on Fri Apr 29 4:44:41 EDT 2005.
bph
I've finally fixed the problem
till don't understand the problem but I've fixed it
Result.
In the end I forced a recordsource "newQry" in the Form_Open event overiding the where criteria in the DoCmd.OpenForm
this, touch wood, seems to serve as a workaround and all is OK (for now)
Ocan relax now over the weekend
regards,
Ben
strive4peace
yes, "dirty=false" forces a save if the record has been altered
Glad you resolved the problem, Ben -- have a GREAT weekend wink.gif
bph
cheers,
TW, what is the advantage you have found in saving records in this manner?
regards,
Ben
strive4peace
I learned this method from John (mishej) -- he says it is the best way to save and that is good enough for me!
One advantage, though, is that you can test to see if a save needs to be done -- as saving a record when there is nothing to save will cause Access to tell you that the operation cannot be performed at this time...
also, the method you were using is VERY old and no longer recommended for use -- a better one for that is
DoCmd.RunCommand acCmdSaveRecord
LittleViews
Crystal, what event does "if me.dirty then me.dirty = false" go in?
bph
for sure
think DoCmd.MenuItem is a remnant from Access95
I am in the unfortunate position of debugging someone elses code though, they seem to like it
I did try replacing the MenuItems with Runcommands early on but the same error was thrown
will certainly use the dirty property in future projects
regards,
Ben
bph
LittleViews
The statement replaces a save record call (e.g. DoCmd.MenuItem... DoCmd.RunCommand etc.) made in VBA. This could occur in almost any event - this is dependent on the individual project. Most likely it will be in a save button or close button on_click type of event.
regards,
Ben
strive4peace
another time to force a SAVE is to allow creation of related records...
oing menu items that from old versions of Access will not always be available ... whereas the RunCommand constants are more likely to stay supported ... you might want to mention that to the boss who wants you to leave that code in ...
the wizard code generator uses the archaic method -- hence the reason you find it in so much code
in my opinion, for the serious developer, wizards sould be used as a learning tool and a starting point ...
mishej
I'll expand a bit on Crystal's explanation....
There are more than one way to save a record but generally they all have some problems.
The ancient way is with the DoCmd.MenuItem method. This is outdated and not really supported. If you use it and later update to a newer version of Access this command may not be supported. And, of course, this problem will occur 3 years after you written the code and long forgotten about that method. Client won't be happy...
You can use the newer DoCmd.RunCommand acCmdSaveRecord (is that right?) but the problem here is that the line of code is not real specific - what record in what form? What if the user has several forms open and this line runs in the wrong form because the user switched the focus to another form just prior to this line running? Oops... the record you wanted to save might never get saved.
The Me.Dirty = False code line specifies the form ("Me" - the current form, i.e. the form where this code line lives). So a nice little code block of:
CODE
If Me.Dirty Then
   Me.Dirty = False
End If

A form becomes "dirty" if one of its bound (data-bound) controls has been changed. So we check if any control has had its value changed (If Me.Dirty) and if so we "force" the form to save the record (Me.Dirty = False).
There is no ambiguity over which form will save its record - "Me" will. Even if the user switches focus to another form prior to this code actually running.
When would you use this? Well, anytime the user might move the focus from this form would be a good time to do it. For example, you have the user fill out all the fields of a record and then you want them to click on a button on the form to print the values. Well, the record isn't normally saved until you move to the next record (or other record) forcing an implicit save. So if the click the "Print Values" button you probably won't get any values printed because the record hasn't been saved! So you're code for the "Print Values" button should look like this:
CODE
Private Sub cmdPrintValues_Click()
  ' check if the user hasn't saved the current values
  If Me.Dirty Then
    Me.Dirty = False   ' save the value
  End If
  DoCmd.OpenReport "rptPrintValues",, .....<etc>
End Sub

Now the report will contain the current values (assuming the rest of the DoCmd.OpenReport line had the proper arguments).
This is a "lo-fi" version of UA. To view the full version with more information, formatting and images, please click here.