Runtime error 64019 (97 SR-1)

Topic

New Reply

Hi All

Several controls on my form open three additional forms based on the current value of a field called ParticipantID. They all work properly when I am developing the application. But when I close Access and restart the app and immediately try to open any of the forms, Access responds with Runtime Error 64019 — Reserved Error (-1517)

If I subsequently open the form in design mode and immediately open it form view (without changing anything), everything works properly. Last symptom — when the error occurs and I go into debug mode and move the mouse over ParticipantID field in the error line, then Access pops up an error message: Reserved Error (-1517).

Here’s one of the lines:

Private Sub cboPeopleID_DblClick(Cancel As Integer)
DoCmd.OpenForm “frmParticipantsInWorkshops”, , , _
“ParticipantID = ” & ParticipantID, , acDialog
End Sub

Any clue what’s causing this? Thx.

Reply | Quote

Replies

Try putting this all on one line –

DoCmd.OpenForm “frmParticipantsInWorkshops”, , , “ParticipantID = ” & ParticipantID, , acDialog

Just a guess on my part because you are not using the Continuation underscore and & properly….

hth,
Jack

Reply | Quote

First of all, I’m assuming ParticipantID is numeric? Then, you should really be referencing the control on the form, and it is usually best to do it my using Me!ParticipantID. Actually, I would have renamed the control to txtParticipantID, so I would use Me!txtParticipant. Your use of line continuation seemed correct (assuming you had a space before the underscore character; as did your use of the &.

Reply | Quote

thanks Mark, I will try that from the office tomorrow.

Yes, it is numeric. I normally do rename all (???) the controls to txt…. Not sure whether I did in this case, but I will check. However, your answer raises a point — does it really make a difference whether you reference the control or the recordset field? I’ve done either method explicitly on occasion, but never really knew whether one was preferred over the other.

Reply | Quote

you wrote:
>>However, your answer raises a point — does it really make a difference whether you reference the control or the recordset field? I’ve done either method explicitly on occasion, but never really knew whether one was preferred over the other. <<

I'm not really sure either. I guess my own preference (habit?) is to address the control.

Reply | Quote

Curiouser and curiouser…. (sp???)

Taking your hint that control vs field ambiguity is the culprit. First, I ran the program from boot-up to confirm the problem still exists. Yes, it does.

Then, I added a new textbox control to the form. Bound it to the ParticipantID field and renamed it txtParticipantID. Ran the program and everything worked properly. Hooray!

Then I deleted the control, and it *still* ran properly. No other changes to the program. nada. zilch.

I think you hit the nail on the head, though, with being absolutely certain to distinguish between control names and field names. In this case, the field “ParticipantID” was not even represented on any control on the form. The event was bound to cboPeopleID, which is related to, but distinct from the ParticipantID field.

I don’t get it… but at least it works. Thanks for your help.

Reply | Quote

I think it is safe to say that Access works best when you take away the necessity for it to make choices!

Reply | Quote