Question Is there a way to check MSACCESS.EXE cmd line arguments? (1 Viewer)

SOLVED: Is there a way to check MSACCESS.EXE cmd line arguments?

I am very new still to window's programming. Working with MS Access and VBA has been my first venture so far.

How my code currently works, is that a user will double-click on the application.accdb file, which launches the full version of MS Access. This is equivalent to creating a desktop shortcut like:

"<path to access>/msaccess.exe <path to db>/application.accdb"

I know how to do several things like fake a runtime:

"<path to access>/msaccess.exe <path to db>/application.accdb /runtime"

As well as make an execute-only version (*.accde) which protects the VBA code or even compile a true runtime version with the appropriate packages.

What I am wanting to know is if it is possible to pass, from a customized desktop link or the windows cmd line, parameters that my VBA code can get a hold of and use for scheduled/batch application? I don't know if the MSACCESS.EXE allows for the passing of custom parameters in this fashion. Something like:

"<path to access>/msaccess.exe <path to db>/application.accdb /customargs=mode:batch;autoverify:true"

When the database launches, there is a Startup form that auto launches currently.

Is this type of functionality only available if I split the database from the forms and VBA code or even available at all? I did some searches in this forum and couldn't find anything. Maybe if I knew more about Windows programming I would know how to handle this.

This application will be deployed in a Citrix environment, so there is no worry about the end-users getting to the shortcut and modifying it to bypass or cause strange actions.

omnialive said:

As well as make an execute-only version (*.accde) which protects the VBA code or even compile a true runtime version with the appropriate packages.

Click to expand...

What do you mean by a "true runtime" and what packages are you referring to?

What I am wanting to know is if it is possible to pass, from a customized desktop link or the windows cmd line, parameters that my VBA code can get a hold of and use for scheduled/batch application?

Click to expand...

Use Run or ShellExecute to start the another database. Use Windows Scheduler to run the database as required. VBA can be used to modify the Scheduler settings or the shortcut/batch file it runs.

When the database launches, there is a Startup form that auto launches currently.

Click to expand...

In A2007+ use the Startup form setting in Access settings > Current Database. In earlier versions make a macro and call it Autoexec.

Is this type of functionality only available if I split the database from the forms and VBA code or even available at all?

Click to expand...

All database should be split. Splitting has not effect on functionaliy of VBA.

Galaxiom said:

What do you mean by a "true runtime" and what packages are you referring to?

Click to expand...

In the book, "Beginning Access 2007 VBA", authored by Denise Gosnell, in Chapter 12, pp 330, she talks about how you can distribute the application with the Access runtime using the "Packaging Wizard" which comes with the Office Access 2007 Developer Extensions installed as part of the Visual Studios Tools for MS Office System.

Galaxiom said:

Use Run or ShellExecute to start the another database. Use Windows Scheduler to run the database as required. VBA can be used to modify the Scheduler settings or the shortcut/batch file it runs.

Click to expand...

I don't understand what you are trying to say here. I am sure you meant "the other database" instead of "the another database", but that still doesn't clear up what you are talking about so that I can pass my VBA code arguements that are set on the command line. Maybe an example would help here.

Galaxiom said:

In A2007+ use the Startup form setting in Access settings > Current Database. In earlier versions make a macro and call it Autoexec.

Click to expand...

I already have a startup form that launches and know how to create it. This wasn't an issue.

Galaxiom said:

All database should be split. Splitting has not effect on functionaliy of VBA.

Click to expand...

Why should the database be split? Security? Integrity? Communal consensus?

omnialive said:

... you can distribute the application with the Access runtime using the "Packaging Wizard" which comes with the Office Access 2007 Developer Extensions.

Click to expand...

This package just installs the Runtime on the computer. It doesn't turn the Access executable into a "true executable".

I don't understand what you are trying to say here. I am sure you meant "the other database" instead of "the another database", but that still doesn't clear up what you are talking about so that I can pass my VBA code arguements that are set on the command line. Maybe an example would help here.

Click to expand...

I misunderstood your question. You could probably add your own arguments to the command line used in a command/batch file. Access would probably ignore them. Then have the VBA read that line from the file and make the adjustments once it has started. But AFAIK there is no way to pass arbitrary switches directly from a command line as a parameter as one can do with a command/batch file.

Sometimes developers place this kind of information in an ini file that the database connects to on opening. However I prefer to place user specific settings in a table in the back end. This ensures a consistent environment at any workstation where they use the database.

Why should the database be split? Security? Integrity? Communal consensus?

Click to expand...

Any shared database that is not split is a disaster waiting to happen. Even single user databases are best split. This separates the data from the user interface, minimising the potential for corruption of the data. It also allows the front end to be developed while the current version continue to be in use without having to deal with synchronising the tables when the update is deployed.

From the Access Help File

Command Function

mk:@MSITStore:C:\Program Files\Micr...3\vbaac10.chm::/html/acfctCommand.htm#example
You can use the Command function to return the argument portion of the command line used to launch Microsoft Access.
Remarks

When Microsoft Access is launched from the command line, any portion of the command line that follows the /cmd option is passed to the program as the command-line argument. You can use the Command function to return the argument that has been passed.
To change a command-line argument once a database has been opened, click Options on the Tools menu. On the Advanced tab of the Options dialog box, enter a new argument in the Command Line Arguments box. The Command function will now return the new argument you have entered.
When the Command function is used anywhere other than in Visual Basic code in a module, you must include empty parentheses after the function. For example, to use the Command function in a text box on a form, you would set the ControlSource property of the text box to an expression like the following:
=Command() Example

The following example shows how to launch Microsoft Access with a command-line argument, and then shows how to return the value of this argument by using the Command function.
To test this example, click the Windows Start button and click Run. Type the following code in the Run dialog box on a single line. (You must surround the parts of the command line information in quotation marks).
"C:\Program Files\Microsoft Office\Office10\Msaccess.exe" _"C:\Program Files\Microsoft Office\Office10\Samples\Northwind.mdb" /cmd "Orders" Next, create a new module in the Northwind sample database and add the following Sub procedure:
Public Sub CheckCommandLine() ' Check the value returned by Command function and display ' the appropriate form. If Command = "Orders" Then DoCmd.OpenForm "Orders" ElseIf Command = "Employees" Then DoCmd.OpenForm "Employees" Else Exit Sub End IfEnd Sub When you call this procedure, Microsoft Access will open the Orders form. You can create an AutoExec macro to call this procedure automatically when the database is opened.

DJkarl was spot on! I tested it and it works perfectly! Way to go man! You are my hero! I'm not used to application help files (especially MS's) being helpful! ;-)

This will allow me to develop the app to run in a batch mode whenever the '/cmd "MODE=BATCH"' is used on the command line! Awesome!

Cheers and thanks a million!

Thanks for that djKarl.

I hadn't come across that and when I searched access commandline I only found stuff about the standard arguments. Needed to search access command function

Here is a link to the Microsoft webpage that is the equivalent of the help entry that documents the Command function.
http://msdn.microsoft.com/en-us/library/aa211469(office.11).aspx