Continous Form not linking right record

[natsirtm]

I have a continuous form that I use as a launchpad to open individual records. However it doesn't open the right record, and troubleshooting shows that instead of the records primary key, it's giving me "????????".

I am using replication id's for the PK.

Any ideas?

TIA

 

[natsirtm]

Even when I add a hidden textbox to store the value from the query - the value is loaded into the textbox right, but doesn't change that I receive "????????" when referencing Me.field

 

[natsirtm]

I tried adding a button using the wizard to see if that would work. Linked the PK field, however now I get a Parameter Pop up with asian characters as the description?!?

 

[natsirtm]

Found partial answer here
http://stackoverflow.com/questions/393381/recommendations-on-using-sql-server-guid-from-ms-access

• When you try to get a GUID value from a control in a form (usually as the linked field in a combobox), you'll get '?????'but no value. You have to refer to the field value in the recordset to get the correct data. You can open such a form in your app, go to the 'immediate' window, and try this:

? myForm.myControl
?????

? myForm.recordset.fields("myFieldName")
{000581EB-9CBF-418C-A2D9-5A7141A686CC}

Except I get a Jet formatted GUID, which still doesn't open the right record.
Tried using a St to GUID function, but got an error.

"Only user-defined types defined in public object modules can be coerced to or from a variant or passed to late-bound functions."

Any ideas on that? I'll be back at this monday.

 

[dfenton]

The Stackoverflow reference includes a comment from me citing this article about GUIDs in Access:

http://trigeminal.com/usenet/usenet011.asp?1033

The key is that Access doesn't deal with them well, and I recommend against ever using them for anything in an Access application.

The key functions in VBA for dealing with GUIDs are StringFromGUID() and GUIDFromString(). There's other weirdness in trying to join them in queries and often you can't and have to use an implicit join, instead (i.e., using a WHERE clause instead of a JOIN).