https://www.c64-wiki.com/wiki/DATA

PARAMETERS declaration (Microsoft Access SQL)
https://learn.microsoft.com/en-us/office/client-developer/access/desktop-database-reference/parameters-declaration-microsoft-access-sql

> would like to have a form get some parameters/arguments
Are these entered by the User?

> And I would prefer not to reference the form
Where are the parameters coming from then?

Hi Alex thanks, I'll check the links. Yes, the user enters them in the form, unbound fields (Maybe not, I may write a record of what's entered as a log).

I'm used to passing parameters, and I'm not sure the form will be open when the values are needed. I'm thinking form gets the parameters and feeds to a query, which then is the data source for a report. It's possible the report might need some parameters too, but I would probably get those out of global variables. Or maybe there's a more straightforward way, since I'm not sure a form can call a query which then fires off the report.

If the Form isn't open and they were unbound you wouldn't have the values to reference as they aren't stored anywhere?

@Alex post#6 Exactly why I want to pass them before the form closes.
The DATA command was for "reading" from a constant, this is similar, in that I want to "stuff" parameters.
It's odd that Microsoft didn't include OpenArgs for queries with some kind of delimiter.

Could just use CreateQueryDef and clean up after yourself later.

Can you write out your steps very simply

Open Form
Populate user based values
Open Report based on values

?

@ Alex This has been in the back of my mind for some time, and I've been trying to figure out the "new Access" way to do what I did in an old RAD on a minicomputer, which was this:

1. The Menu program prompted for various arguments based on a table record for the job selected
2. A processing job was created in a BATCH like language (PROC) by the Menu program, a copy saved to a log file
3. Menu starts execution of the PROC file which would normally run a query to start with
4. A report or update program (initiated by the BATCH) would use the query as a source to do its work, and arguments were passed by the BATCH to the update or report program
5. Execution returns to the Menu program

The minicomputer's "PROC" language is similar to BATCH and pipes in DOS, but a bit more sophisticated with more commands and logic abilities.

To be more in synch with what I've done with regular forms to populate a table, I'm thinking, instead of the Menu program doing the prompting, a Master Parameter Form could do it for all the different jobs that need arguments to run. This would be a morphing form, similar to my current Menu form.

Since there isn't a BATCH type component in Access, one either has to CHAIN between the form and query and then report, or one has to have the Master Parameter Form do all the work, feeding the arguments to the update or report via global variables and the update or report has to build the SQL statement for its source.

This last approach isn't too farfetched, since I'm already doing much of it to make one form call another which needs arguments.

I was just curious if there is a way to "pass" arguments to a query, because at the moment, I need a simple method to get a quick-and-dirty parameter driven query done, as the Master Parameter Form will be a big programming project.

You can either use a form to get the parameters, or like Alex said create a QueryDef and then just delete it later. Or you can use TempVars which queries can read. Lots of ways to do it. What's the purpose of the query? Is it an action query or just a select query for viewing data?

@ Richard, I do a lot of updates that are way beyond what a simple query can do. For example, when processing claim transactions, I do an extensive error validation, look for duplicate claims, update a host of different totals in different tables, etc. that use a lot of DAO. Reports are straighter forward, but I want to avoid multiple popups asking for Begin date, End date, Customer, Claim, etc.  So far, I just create the SQL statement inside the procedure and do a Set x.OpenRecordset(wSql) since it's fairly easy to construct in VBA and avoid a contaminated query object.

Which brings up a good question. When you do reports, say for one customer, do you ask for the Autonumber Id (Autonumbers aren't for you!) or some other code, that then requires a bit more complicated SQL?

I prefer to use Global variables (over TempVars) for temporary passing of transient data. I've read the Microsoft help for QueryDef object (DAO) temporary, and it may be useful in the future. Got a video on that?

I'm guessing from your and Alex's responses, that there isn't a way to pass arguments to a parameter query other than a form's controls. You did mention something in one video I think you called query parameters that looked like a table, but that went over my head.