OpenArgs is null (Access 2003/XP)

Topic

New Reply

This has me stumped.
In my app I have 2 reports that I want to pass parameters to when they open. The reports are very similar. In both cases, I’m using DoCmd.OpenReport “rptMoStatement”, acViewPreview, , , acWindowNormal, strWHERE. In one case, the report’s open event reads the opening argument string. In the other, it says openargs is null.

Any clue why?

Reply | Quote

Replies

1. Have you checked very carefully whether the number of commas in the statement is correct in both cases? If you omit one, the strWhere argument would not be in the correct position.
2. Have you checked that strWhere is actually assigned a value in both cases?
(3. The name strWhere seems more appropriate for the WhereCondition argument than for the OpenArgs argument.)

Reply | Quote

Yes to both your questions.

The variable name was originally used to pass a querydef, but I found a more effective way to do that. Just never changed the variable name.

Reply | Quote

I’m afraid I have no further ideas. If you wish, you can try to post a stripped down copy of the database.

• Make a copy of the database and work with that.
• Remove all database objects (tables, queries, forms, reports, macros and modules) that are not relevant to the problem.
• In the remaining table(s), remove most records – leave only the minimum number necessary to demonstrate the problem.
• Remove or modify data of a confidential nature.
• Do a compact and repair (Tools/Database Utilities).
• Make a zip file containing the database; it should be below 100KB.
• If you have difficulties getting the zip file below 100 KB, save the database in Access 97 format and then zip it.
• Attach the zip file to a reply.
  [/list]That would allow Loungers to look at the problem directly.

Reply | Quote

DB attached in zip. Idea is to scan badges of employees attending meeting, display info from last scan while prepping mainform ready for next scan. As last scan is displayed, colors are applied based on active status.
“co-scan-in” is mainform.

Reply | Quote

The post by chrisseguin is actually a reply to post 439117. I will post my reply there.

Reply | Quote

The post by chrisseguin is actually a reply to post 439117. I will post my reply there.

Reply | Quote

DB attached in zip. Idea is to scan badges of employees attending meeting, display info from last scan while prepping mainform ready for next scan. As last scan is displayed, colors are applied based on active status.
“co-scan-in” is mainform.

Reply | Quote

Since I still have to add an another entire school besides the one I can’t seem to append, I think I’ll just get rid of the existing database and start all over again – it’ll be good practice for me since apparently I need all the practice I can get!

Again – thank you.

Aunt Linda

Reply | Quote

Did you reply to the wrong post or was this a glitch of the Lounge software?

Reply | Quote

Must be a glitch – I clicked on the link to reply and this is where I ended up. Thank Goodness it’s 2007 and the cyberworld is sooooooooooo dependable!

Sorry –

Aunt Linda

Reply | Quote

No need to apologize – it’s not your fault.

Reply | Quote

HansV
Thanks, but I can not recreate the problem. My client has it and just runs the code three or four times and it then works. Also this was not happening before the data table grew. It is one table and has its own data base. The forms, reports, queries and VBA code are another database, while all the other data tables are on a third database. No way to get this down to 100k. So thanks and I will have to try to figure out what is going on.
Sarge

Reply | Quote

Did you intend to post this as a reply to post 651,170? It makes no sense here.

Reply | Quote

Many thanks. Hope it works, seems very small after converting to Access 97. Just over 100k before zipping. If it opens, enter a 1 in the textbox, you will see some records to select. The last does not work .Regards

Reply | Quote

I assume that you meant to post this as a reply to post 699,101 instead of in this thread.

I don’t see any queries in the database that you attached.

Please post your next reply in the correct thread again. Thank you.

Reply | Quote

OK.
If I cannot figure it out, I’ll send a stripped down copy later on.

Reply | Quote

Thank you- I’m sending it along.

Reply | Quote

I assume that you intended this as a reply to post 730,621. I will post a reply in that thread when I have looked at your database.

Reply | Quote

The db I sent was for ‘filter / search a form (2003)’, not this thread. Sorry

Reply | Quote

I’m afraid I have no further ideas. If you wish, you can try to post a stripped down copy of the database.

• Make a copy of the database and work with that.
• Remove all database objects (tables, queries, forms, reports, macros and modules) that are not relevant to the problem.
• In the remaining table(s), remove most records – leave only the minimum number necessary to demonstrate the problem.
• Remove or modify data of a confidential nature.
• Do a compact and repair (Tools/Database Utilities).
• Make a zip file containing the database; it should be below 100KB.
• If you have difficulties getting the zip file below 100 KB, save the database in Access 97 format and then zip it.
• Attach the zip file to a reply.
  [/list]That would allow Loungers to look at the problem directly.

Reply | Quote

Yes to both your questions.

The variable name was originally used to pass a querydef, but I found a more effective way to do that. Just never changed the variable name.

Reply | Quote

Just for fun, I made a copy of the report that is reading the openargs string, called it by a different name, and tried opening it with the same docmd method.
Identical report, identical code module, just a different report name.
Got ISNULL for openargs.

Is this an Access 2003 bug?

Reply | Quote

I don’t have Access 2003 myself. There are a few newsgroup posts about OpenArgs in Access 2003, but nothing really conclusive, so I don’t know if it is a bug.

Reply | Quote

(Edited by HansV to provide link to MSKB article – see Help 19)

I’m suspicious, because I found a Microsoft Knowledge Base Article 836030 that says, tantalyzingly, that the following bug in Access 2002 was fixed in SP3:

“The OpenArgs function only works one time in a VBA project

If your MS VBA code for a form makes a call to the OpenArgs function after you open the form in design mode, yhou may receive the following VBA error message:

Run-time error: 94
Invalid use of Null

No hyperlink to any more info, and my app is a regular .mdb, not a .mda, plus the problem is in a report, not a form, nor does an error message display.
Still, this is Microsoft . . .
Any suggestions as to how to find out more?

Reply | Quote

That must be an obscure bug, for I have never encountered it in Access 2002 (I don’t think they meant an .mda in that section)

No further ideas, except what I posted higher up in this thread.

Reply | Quote

That must be an obscure bug, for I have never encountered it in Access 2002 (I don’t think they meant an .mda in that section)

No further ideas, except what I posted higher up in this thread.

Reply | Quote

The question is *when* is OpenArgs null? If it is not null in the Report_Open event, then just store the value in a module level variable and refer to the variable after that. Then it will work regardless of whether or not it has been “fixed”. I’ve never seen the aforementioned bug in 2000, but then I don’t keep referring to OpenArgs elsewhere in the report.

Reply | Quote

I’ve had problems with OpenArgs for a form losing its value when the form has been open a while, so I tend to use a module level variable too. But Kathryn mentions explicitly that she got the error in the Open event of the report. I’ve never had problems with OpenArgs being unavailable in the Open event…

Reply | Quote

Yes, I realize that, Hans. However, if one report is OK and another isn’t, I would suspect an unhandled error in the report that is experiencing the problem. If the value can’t even be assigned to a string variable at the top of the Report_Open event, then it simply isn’t making it into the report at all, as opposed to evaporating after it gets there.

Reply | Quote

Okay, I think we have solved it by installing SP1 for Office 2003. I have tested it on one PC so far, and no problems.

Thanks to all of you for your help.

Reply | Quote

Okay, I think we have solved it by installing SP1 for Office 2003. I have tested it on one PC so far, and no problems.

Thanks to all of you for your help.

Reply | Quote

Yes, I realize that, Hans. However, if one report is OK and another isn’t, I would suspect an unhandled error in the report that is experiencing the problem. If the value can’t even be assigned to a string variable at the top of the Report_Open event, then it simply isn’t making it into the report at all, as opposed to evaporating after it gets there.

Reply | Quote

I’ve had problems with OpenArgs for a form losing its value when the form has been open a while, so I tend to use a module level variable too. But Kathryn mentions explicitly that she got the error in the Open event of the report. I’ve never had problems with OpenArgs being unavailable in the Open event…

Reply | Quote

The question is *when* is OpenArgs null? If it is not null in the Report_Open event, then just store the value in a module level variable and refer to the variable after that. Then it will work regardless of whether or not it has been “fixed”. I’ve never seen the aforementioned bug in 2000, but then I don’t keep referring to OpenArgs elsewhere in the report.

Reply | Quote

That isn’t talking about once in a database, it’s once in a form in that project, and please note the reference to opening it in design view.

Reply | Quote

That isn’t talking about once in a database, it’s once in a form in that project, and please note the reference to opening it in design view.

Reply | Quote

(Edited by HansV to provide link to MSKB article – see Help 19)

I’m suspicious, because I found a Microsoft Knowledge Base Article 836030 that says, tantalyzingly, that the following bug in Access 2002 was fixed in SP3:

“The OpenArgs function only works one time in a VBA project

If your MS VBA code for a form makes a call to the OpenArgs function after you open the form in design mode, yhou may receive the following VBA error message:

Run-time error: 94
Invalid use of Null

No hyperlink to any more info, and my app is a regular .mdb, not a .mda, plus the problem is in a report, not a form, nor does an error message display.
Still, this is Microsoft . . .
Any suggestions as to how to find out more?

Reply | Quote

I don’t have Access 2003 myself. There are a few newsgroup posts about OpenArgs in Access 2003, but nothing really conclusive, so I don’t know if it is a bug.

Reply | Quote

Just for fun, I made a copy of the report that is reading the openargs string, called it by a different name, and tried opening it with the same docmd method.
Identical report, identical code module, just a different report name.
Got ISNULL for openargs.

Is this an Access 2003 bug?

Reply | Quote

1. Have you checked very carefully whether the number of commas in the statement is correct in both cases? If you omit one, the strWhere argument would not be in the correct position.
2. Have you checked that strWhere is actually assigned a value in both cases?
(3. The name strWhere seems more appropriate for the WhereCondition argument than for the OpenArgs argument.)

Reply | Quote