When to use code

majhl

Registered User.
Local time
Today, 12:17
Joined
Mar 4, 2008
Messages
89
I'm hoping someone can clear something up for me. I've only now been made aware of it, which is a bit of an embarrassment as I've been using it this way for years!

I've just discovered that when you use it on, say, the click event of a button that's intended to save the current record and close a form, it will raise an error (runtime error 2046 'the command or action 'saverecord' isn't available now').

When (under what circumstances) exactly can the following line of code be used?

Code:
DoCmd.DoMenuItem acFormBar, acRecordsMenu, acSaveRecord, , acMenuVer70
I've also used the following to try and do the same thing with the same error message:

Code:
]DoCmd.RunCommand acCmdSave
RunCommand acCmdSaveRecord
I know that closing a form (without using 'undo') will save the record anyway, but this does not seem right to me. So how exactly do I achieve what I want?

Thanks for any help.
 
I don't have an explanation for your post except that I have observed in the way past that it is not recommended and so have always used the following to do stuff ...

For saves: DoCmd.RunCommand acCmdSaveRecord
For undos: DoCmd.RunCommand acCmdUndo
For deletes: DoCmd.RunCommand acCmdDeleteRecord

I normally have these set up on my own buttons that change depending on if a record is new or not (acNewRecord) so I can control the users exits of my forms.

For your error, just the one statement and you should be good to do.

-dK
 
Yes, I tried using 'DoCmd.RunCommand acCmdSaveRecord' and I get the same error message ('runtime error 2046'). Perhaps I didn't explain that in the OP.

All of the three methods I use raise the error.
 
what you can do is to trap the error number so in the on error routine
Code:
IF err <> 2046 Then
    Msgbox err & " " & err.Description
endif
Resume yourExitHandler
 
Hmmmmm. I would guess a couple of things.

Not sure where or how you are using this. Does the form properties have Allow Edits or Allow Additions set to Yes?

You could try a wrapper on it to check to see if a save is necessary. For instance ...

Code:
If Me.Dirty = True Then DoCmd.RunCommand acCmdSaveRecord

I'm not sure what the fix could be - I've never ran into this problem; but I know there is a known issue and I will try to find the Microsoft article that discusses this problem.

-dK
 
Hmmmmm. I would guess a couple of things.

Not sure where or how you are using this. Does the form properties have Allow Edits or Allow Additions set to Yes?

Yes, those properties are set to 'Yes'.

You could try a wrapper on it to check to see if a save is necessary. For instance ...

Code:
If Me.Dirty = True Then DoCmd.RunCommand acCmdSaveRecord
I'm not sure what the fix could be - I've never ran into this problem; but I know there is a known issue and I will try to find the Microsoft article that discusses this problem.

-dK

Yes, I've tried using the dirty property and I get the same error. Thanks for any help you can provide.
 
Hmmmm. Now a buncha guessing ...

Tried compact and repair? Tried compiling the code? Tried creating a new form and bringing all of your controls and code into it?

After that, I guess the next line of questioning would be, what version of Access are you using? Did you recently upgrade? Service Pack version? Is it a networked database or standalone?

-dK
 
OK. Db is compact and repaired by default on exit. Code has been compiled a gazillion times!

I'll try the new db approach.

Using 2003 SP3 and as far as I'm aware, all updates have been installed. It is a networked db. Is that an issue?
 
OK, I've something which appears to work and which I found a reference [to] to via google:

Code:
If Me.Dirty = True Then Me.Dirty = False
Question is, why does this work and not the others?

BTW, creating a new db and importing all the db objects made no difference.....
 
The reason I asked if a networked db is that what if, at that instant it wants to save - the network isn't available. That would probably cause this error.

Perhaps the recordset isn't updatable? Is the form bound to a table or a query? Can you edit the query in the QBE? This is because I am thinking that the joins might prevent the record from being updatable.

My last thought is the database properties. Assuming that this error persists in all of your forms, does the user have the proper read/write access to the folder? Is the database in read-only mode (i.e., copied from a CD and access rights were unchanged)?

-dK
 
OK, I've something which appears to work and which I found a reference [to] to via google:

Code:
If Me.Dirty = True Then Me.Dirty = False
Question is, why does this work and not the others?

That's great if it works, but it sounds as if you are just using a double-negative and cancelling out the Save and just letting Access automatically save the record.

For me personally, I use Me.Dirty alot checking for things the user might be doing or have done and I wouldn't be able to trust the code if I had to use Me.Dirty for this effect on a save. If you feel the same, is there anyway to slim down the db, strip out everything but the offending form and table and post?

-dK
 
That's great if it works, but it sounds as if you are just using a double-negative and cancelling out the Save and just letting Access automatically save the record.

For me personally, I use Me.Dirty alot checking for things the user might be doing or have done and I wouldn't be able to trust the code if I had to use Me.Dirty for this effect on a save. If you feel the same, is there anyway to slim down the db, strip out everything but the offending form and table and post?

-dK

Yup. I'll do that later if you want to have a look at it.

Thanks very much.
 
The DoCmd.RunCommand acCmdSaveRecord will fail with that error message if you are stepping through the code. If you need a breakpoint, put it in the BeforeUpdate event itself or after the save depending on wher you want to start the debugging.
 
The DoCmd.RunCommand acCmdSaveRecord will fail with that error message if you are stepping through the code. If you need a breakpoint, put it in the BeforeUpdate event itself or after the save depending on wher you want to start the debugging.

Thanks for the reply. What I don't understand here is why does 'DoCmd.RunCommand acCmdSaveRecord' (or any of the other options I've tried) fail when I'm stepping through? If I wasn't stepping through there's no error generated, so does that mean the code has run properly?

For example:

Code:
DoCmd.RunCommand acCmdSaveRecord
DoCmd.OpenForm "frmMain"
Forms!frmSearch.Visible = True
DoCmd.Maximize
DoCmd.Close acForm, Me.Name

All I know for sure is that the lines after the 'DoCmd.RunCommand acCmdSaveRecord' have executed properly becuase I can see the effects in the behaviour of the db. Has Access executed the save command? This is what I'm unsure about.
 
well try this

show the record selector on the from

if the record is dirty, it will show a pencil

if its saved it will turn back to a black arrow/triangle

---------
and out of interest, did you know you can click the pencil to save a record
 
i know what it is

you are closing the form, with a partially edited (probably new) but invalid record on the form - eg incomplete mandatory fields

so the form has to close, and the save isnt available

you can intercept this with unload, or beforeupdate event, and cancel the cl0ose, if you want to handle the error, or just use the form error event to dismiss the error.

its hard to be precise - its awkward to scrap a users entry without telling him why
 

Users who are viewing this thread

Back
Top Bottom