Passing a DOA Recordset to another form

[GraeagleBill]

What would be the preferred method in "passing" a DOA Recordset from one form to another.
1) Dim as DOA Recordset Public?
2) Reference via the Forms Collection?


3) Pass its name in OpenArgs?
4) None of the above

[June7]

I have used #1 to pass recordset between procedures.

Preference likely depends on circumstances.

[pbaldy]

I won't take a position on "preferred". It probably depends on the overall situation and what you're trying to accomplish. Off the top of my head I'd probably declare the DAO recordset publicly. I'm not sure if you could pass the name of it in OpenArgs, though that's completely untested. I'm not sure how you'd then reference it In essence you'd be using a variable for the recordset name, and I can't visualize how that would work.

[GraeagleBill]

I had exactly the same question in my mind about any method involving the use of OpenArgs, not even sure what my test would look like at the moment. While I've had occasion to reference controls via referencing within the Forms collection in the past, I think a well placed comment in code added to a Public declaration in the calling form makes the most sense in my situation.

Ever onward! And, thanks to you both,
Bill

WELL RATS! I thought I knew what I was doing.

In calling form:

Public rsRegEMAs As DAO.Recordset

In called form:

MsgBox rsRegEMAs.RecordCount



GOT IT!  Just had a syntax error

	
	
Forms!frmRegistry.rsRegEMAs.RecordCount
MsgBox Forms("frmRegistry")!rsRegEMAs.RecordCount

Neither of these references work, "rsRegEMAs" not defined in 1st case and field not found in 2nd case. (Funny thing though, the compiler knew to capitalize reRegEMAs when I coded rsregemas.recordcount)

The recordset is Set in the calling form.

GOT IT! Run didn't like the syntax

Forms!frmRegistry.rsRegEMAs.RecordCount

[pbaldy]

Personally, anything I want to be able to reference from different forms is declared in a standard module. Generally all in the same one too, much the same as most of us put all our variable declarations at the top of a procedure, not sprinkled throughout. That's just a style thing though.

[pbaldy]

By the way, as you haven't given us the context with which you're using this, I'll throw out another option. You could have a function that contained the recordset and it returns the count. It could take any parameters required by the recordset.

[GraeagleBill]

The context is, I thought a simple one, one form sets and loads the records into a "public" DOA Recordset and a second form under optional circumstances processes the contents of the Recordset. I just want the first form to be able to "share" the Recordset with the second form. Why having made the Recordset Public didn't get the job done is still a mystery to me.

[Minty]

It's because when you set a declare Public Variable in the forms module, it is still only available in that form (It is still a form variable in it's scope).
Any code in that form will be able to use it but nothing outside of the forms scope will see it.

More and better words here https://bytes.com/topic/access/insig...-vba-ms-access

[GraeagleBill]

Thanks Minty, that clears up that question. My normal practice is to declare variables at the beginning of a form's module when I need all the module's subs/functions to have shared access. When I need global sharing, such declarations go in a general module. Almost all my apps have a ModGlobalVars where such declarations appear. With the current situation, there's no need to share the DOA Recordset across the whole app, just between two foms that have related functionality.

The current reference: With Forms!frmRegistry.rsRegEMAs. is getting the job done so I'll just stick with that.