"'Save Record' not available" error

[jmoudy77]

Hi, I've got a form that allows a user to imput their flight data. I programmed a MsgBox into the save button that asks if the user wants to input another duty position for the flight.

If no, the record saves and the formresets for the next rocord input.

If yes, the record is saved and the duty position and mode of flight fields are set to null, with the remainder of the fields retaining the data already entered.

The problem is that when I press save again, the message box appears, and when I press yes or no I get the 'Save Record' not available error message.

Code attached. Any ideas?

[CODE=vb]Private Sub Command38_Click ()
On Error GoTo Err_Command38_C lick

Response = MsgBox("Add another duty position?", 4)
If Response = 7 Then
DoCmd.DoMenuIte m acFormBar, acRecordsMenu, acSaveRecord, , acMenuVer70
DoCmd.GoToRecor d , , acNewRec
Else
DoCmd.DoMenuIte m acFormBar, acRecordsMenu, acSaveRecord, , acMenuVer70
[PI] = Null
[PC] = Null
[IP] = Null
[SP] = Null
[IE] = Null
[MTP] = Null
[Daytime] = Null
[Night] = Null
[NVG] = Null
[Hood] = Null
End If

Exit_Command38_ Click:
Exit Sub

Err_Command38_C lick:
MsgBox Err.Description
Resume Exit_Command38_ Click

End Sub[/CODE]

[sierra7]

Hi Scott
Are you by chance using Access 2003 ???

I've found it very prone to chuck-up this error on code which works perfectly in '97 or 2002.

I have not fully bottomed this out , but in some cases if the record has already been saved it will not allow it to be saved a second time (nothing to save?) other times it "thinks" that Allow_Edits=Fal se, because some form is open in Dialogue mode.

However, in passing, I would mention that the syntax you are using is pre-Access'97 and (unless it has changed again with 2007) the preferred syntax is;-

 DoCmd.RunCommand acCmdSaveRecord

but I don't think this will resolve your problem.
On a more personal note, I find
[CODE=vb] Response = MsgBox("Add another duty position?", 4)
If Response = 7 Then
[/CODE]
less easy to read than
[CODE=vb]
Response = MsgBox("Add another duty position?", vbYesNo)
If Response = vbNo Then[/CODE]
if I have guessed right, but that is just a matter of preference and will not be the cause of the error message.

If I get time I'll try and set-up a demo and test out your code but I suspect it is more a case of what is open in Access at the time you are trying to Save.

S7

[sierra7]

Hi
I've just re-read your question and I can't understand why you want to "force" a Save in either case.

Access will save automatically on the acNewRecord, so you don't need it there. (Unless you are you using 'Unbound' forms when it won't work anyway)

And I am not too clear why you would want to save on the 'Yes' if the data is incomplete. Why not wait until it is complete? I suspect (and I will have to test this) that if you change the values to Null programatically then the form may not be set to 'Dirty' , so Save may not be available. (having just saved)
Maybe setting

Me.Dirty = True

will allow a second save, whether it's needed ot not.
I'm not at my Access2003 machine today but will test on Monday.
S7

[jmoudy77]

Hi S7,

Scott edited the code tags in for me, thanks Scott.

You hit the nail on the head. The record has already been saved; what I can't figure out is how to have it recognize this as a new record without deleting the information out of all the controls. The only controls I want deleted are the ones I null in the code. Any thoughts?

Thanks

[jmoudy77]

I don't want it to save an incomplete record. Here's the situation:

An aviator opens the form to log his flight info.
Once he's done and presses the Save cmdbttn, the msgbox appears asking if he wants to add another duty position for this same flight.
If no, the record is saved and the form resets to add a new record.
If yes, the record saves and then clears only the fields he needs to fill for his second duty position, which keeps him from having to re-enter all the other info.
He then saves this and selects No on the msgbox if no other duty position is required to be filed.
Basicly it creates a new record in the table for each duty position he wants to log.

Josh

[missinglinq]

I'm heading out the door right now, but I'll look at this further later on today, but one thing that strikes me right off is that your code only shows you moving to a new record once, if you don't want to add another flight position. The way you've described this though, when you add another flight position, you still need to add a new record, just a new record with much of the same data pre-loaded.

In Access you can't simply save a record, delete some of the data from it, then save it again as a new record, like you would a word processor file! The record you're working with is still the original record! You have to move to a new record first, then prefill it with data from the original record, complete it and then save the second record.

Welcome to TheScripts!

Linq ;0)>

[missinglinq]

I think this is the sort of thing you need:

[CODE=vb]Private Sub Command38_Click ()
On Error GoTo Err_Command38_C lick

Response = MsgBox("Add another duty position?", 4)
If Response = vbNo Then

DoCmd.GoToRecor d , , acNewRec

Else 'Add another flight position

'Assign value of fields you want to carry forward to variables
MyFirstField = Me.FirstField
MySecondField = Me.SecondField
MyThirdField = Me.ThirdField

'Go to a new record
DoCmd.GoToRecor d , , acNewRec

'Plug in old values from variables to new record
Me.FirstField = MyFirstField
Me.SecondField = MySecondField
Me.ThirdField = MyThirdField

End If

Exit_Command38_ Click:
Exit Sub

Err_Command38_C lick:
MsgBox Err.Description
Resume Exit_Command38_ Click

End Sub[/CODE]
Lines 12-14 copies the value of the fields in the original record that you want to carry forward into the new record into variables.

Line 17 moves to a new record.

Lines 20-22 re-assigns the variables to the fields in the new record. Any fields that haven't been copied in this manner will be empty, awaiting the new data.

Linq ;0)>

[sierra7]

That makes good sense to me Linq!

On the question of differences between 2002 & 2003; have you found that 2003 is more fussy than 2002 in this matter ?

S7

[jmoudy77]

Thanks Linq, that worked like a charm.