saving form data various ways (why some don't work)

[neuroman9999]

I've recently been frustrated to no end with these methods of saving form data:

- docmd.runcommand(accmdsaverecord)
- DoCmd.Save acForm, Me.Name

can anyone tell me what each one is supposed to do and what the rules are, in terms of under what circumstances they DON'T work? here's what I have noticed:

=> when assigning a value to a ctl binding using code from an external proc, the form dirty event is not triggered (e.g. - forms("form1").controls("textbox") = "value")
=> runcommand(accmdsaverecord) does absolutely nothing and doesn't recognize form values present if the above method is used
=> same rule from previous line applies too, if also using docmd.save acform, form_reference_here
=> if you issue runcommand(accmdsaverecord) for a specific form for the purpose of saving a record when it is brand new and the values are put in the binding from code, you can't run subsequent action queries on that record because the record technically has not been recognized as transacted. thus, access doesn't see any data in it. query errors out.

given all of that, how do you guys do it the right way? both under the scenario when a buy has messed it up themselves, or they actually do want to redo it from scratch so it's built the right way? there are many ways, obviously, but in the "fix it" game, a lot of times people don't want to pay to get it done correctly from scratch. happens all the time.

thanks.

 

[pbaldy]

The second doesn't save data, it saves the form object itself. I typically use

Me.Dirty = False

To force a save.

 

[neuroman9999]

The second doesn't save data, it saves the form object itself. I typically use

Me.Dirty = False

To force a save.

you mean you actually force the DIRTY event to happen? I tried that on this project and it failed. runtime error. is it supposed to work? you mean, code like this would actually work, if it is written outside the target form's mod?

forms("form1").controls("textbox1") = "test"
forms("form1").controls("textbox2") = "test1"
forms("form1").controls("textbox3") = "test2"
forms("form1").dirty = false

or would that not work? would I have to focus the target form again to get the dirty to work? because me.dirty is the only dirty code that works, ever?

 

[pbaldy]

Don't know what to tell you. Just tested this from Form2:

Forms!Form1.Text12 = 777
Forms!Form1.Text16 = "Paul B"
Forms!Form1.Dirty = False

Worked as expected.

 

[neuroman9999]

Are you sure you understood the complaint of mine and the various scenarios where it didn't work for me? Now granted when I was running this test I was remoting into somebody's computer using the TeamViewer software and anyone anybody with a brain knows the TeamViewer sucks. I've had all sorts of problems using that software especially working with access products because you get all sorts of weird stuff happening like cursor moving around without wanting letters being typed in the wrong order when you're typing on the keyboard all sorts of stuff

 

[pbaldy]

My test was done over Teamviewer to my work PC. I work from home and use Teamviewer all day every day to get to 2 different development computers (different cities) plus various servers. I don't have the problems you describe. Your description sounds more like a timer event running.

 

[neuroman9999]

I can try to replicate it. want to see a sample DB with 90% stripped out?

 

[pbaldy]

If you want to post a sample, I'll take a look at it.

 

[neuroman9999]

well don't waste your entire evening messing with it. i'll strip it, test it, and if it happens during the test, i'll post it here with instructions of where the problem is.

 

[The_Doc_Man]

If you want to do a SAVE, the way that SHOULD work best is to follow this one-time action:

- Create a command button with wizards enabled.
- In the wizard dialog, pick the "Save" operation from the Form options.
- Now use the VBA screen to see what code was created for the button_Click event. That will tell you how Access saves a form on command.

Once that is done, you can just delete the button and its code because all you wanted to see was what Access does to achieve that effect.

 

[pbaldy]

Doc, later version's wizards will probably create an embedded macro rather than code.

 

[The_Doc_Man]

There is an option to request code.

But you could also create the macro, then use the function that converts macros to code.

 

[pbaldy]

Good point, forgot about that.

 

[neuroman9999]

@pbaldy , here's what I dealt with. it seems as though there was some type of timer running without me knowing it, as an effort by the previous person to detect idle time. it was running via the auto exec macro. see this image:

and the code behind the form was:

I deleted that form, and the macro, during the stripping process for you. the code, tried in various forms and lines moved around many times, to try and figure it out, can be found behind form frmSignOff. the routine is:

btnSignOff1_Click

the reason this was a hair splitting issue was because the person I was working for had no clue what they were doing, nor did they know how to ask the right questions. but that happens with almost everyone, so I'm not surprised. I can't remember to ask EVERYTHING.

 

[pbaldy]

Running timers are notorious for causing the issues you were blaming on Teamviewer.

Did you try the method I suggested?

Forms!tblKapilare.Dirty = False

If I had to bet, the RunCommand is being applied to the object containing the code or whatever object Access considers the "active" object, which may not be the object you want.

 

[Pat Hartman]

This is the code generated by Access once you convert the macro to VBA. As you can see, it uses the DoCmd method. I'm not sure why you have the argument enclosed in parentheses. I've never done that. So that might be your problem with that method. It does however, work ONLY with the current form. If your code is running in one form and automating a different form, then the Forms!someformname.Dirty = False would be a better option.

I have never run into the problem that prompted some MVPs to suggest Me.Dirty as the "only" solution. The one time I tried to use it, it failed. I don't remember the error message. It was a while ago.

'------------------------------------------------------------
' Command16_Click
'
'------------------------------------------------------------
Private Sub Command16_Click()
On Error GoTo Command16_Click_Err

    On Error Resume Next
    DoCmd.RunCommand acCmdSaveRecord
    If (MacroError <> 0) Then
        Beep
        MsgBox MacroError.Description, vbOKOnly, ""
            End If


Command16_Click_Exit:
    Exit Sub

Command16_Click_Err:
    MsgBox Error$
    Resume Command16_Click_Exit

End Sub

 

[pbaldy]

I certainly wouldn't represent using Dirty as the only method, but it has worked for me. This is a case where a different form's data is being saved.

 

[neuroman9999]

I have never run into the problem that prompted some MVPs to suggest Me.Dirty as the "only" solution.

has the title of MVP ever meant anything ?

 

[Pat Hartman]

Perhaps you shouldn't try to pick fights in the technical forums.

 

[neuroman9999]

Perhaps you shouldn't try to pick fights in the technical forums.

what makes you think I'm doing that. apparently you're not thinking clearly. I understand MS did away with that title years ago...

I'm assuming you thought I was putting someone else down. if so, I'm not surprised.