2007: /INI Command Line Parm Unavailable?

[(PeteCresswell)]

I'm trying to convert an app from 2003 to 2007.

It's starting to look like /INI does not work for 2007 - instead
it seems like they want /profile - which points to stuff I would
have to set up in each user's registry.

It this is true, it's a major hit on my deployment strategy -
which relies heavily on an easily-editable .INI file on the LAN.

I'm just not looking in the right place or doing something
stupid, right? Please, please, please, please..... -)

 

[David W. Fenton]

It's starting to look like /INI does not work for 2007 - instead
it seems like they want /profile - which points to stuff I would
have to set up in each user's registry.

It this is true, it's a major hit on my deployment strategy -
which relies heavily on an easily-editable .INI file on the LAN.

If the particular commandline switch is gone, maybe you can replace
with /CMD (or whatever the switch is to pass an arbitrary command in
the commandline and then act upon it your startup code).

 

[(PeteCresswell)]

Per David W. Fenton:

If the particular commandline switch is gone, maybe you can replace
with /CMD (or whatever the switch is to pass an arbitrary command in
the commandline and then act upon it your startup code).

Good point.

But it seems tb pyramiding on me - unless, as I'm hoping, I'm
just not seeing something.

Scattered throughout the app are routines that make calls like:

myIniPath = SysCmd(acSysCmdIniFile)


It all hangs on the command line feeding
/INI \\ServerName\ShareName\Whatever.ini
to the app at startup time.


Before I go overhauling all of them, I think my first task is to
verify my initial assumption: that /INI is gone and has no
functional equivalent on the command line.

 

[Tony Toews]

It's starting to look like /INI does not work for 2007 - instead
it seems like they want /profile - which points to stuff I would
have to set up in each user's registry.

It this is true, it's a major hit on my deployment strategy -
which relies heavily on an easily-editable .INI file on the LAN.

I'm just not looking in the right place or doing something
stupid, right? Please, please, please, please..... -)

I jsut came across the following at
http://office.microsoft.com/en-ca/access-help/command-line-switches-for-access-HA010166605.aspx

"Starts Access by using the options in the specified user profile
instead of the standard Windows Registry settings created when you
installed Access. This replaces the /ini switch used in versions of
Access prior to Access 95 to specify an initialization file."

So it looks like you are correct.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

 

[Tony Toews]

So it looks like you are correct.

Worse it looks like this is in HKLM so you might need an admin account
to make these changes.

http://office.microsoft.com/en-ca/access-help/create-an-access-user-profile-HP005188988.aspx?CTT=1

Can you use group policy to do this? I know next to nothing about
group policy other than it exists and can be used to make changes that
affect users logged into a domain.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

 

[Tony Toews]

It this is true, it's a major hit on my deployment strategy -
which relies heavily on an easily-editable .INI file on the LAN.

Just curious. What kinf of settings do you have in there?

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

 

[(PeteCresswell)]

Per Tony Toews:

Just curious. What kinf of settings do you have in there?

UNC of the back end DB(s) (sometimes up to seven of them) so the
app can refresh it's connections if needed.

Whether it's running in "Production" or "Test" mode ("Test" mode
prints disclaimers on any reports, "Production" mode disables F11
and various other things)

Text for the containing window.

Various numeric values, like the percentage of XYZ that's allowed
in a given fund.

Settings for each user that reflect last size/position of each
window opened to the windows open in the same position at the
same size next time.

User-specific data from the last time a user made a selection
from a combo box or such - so the next time they use said control
it is initialized to the last value they specified.

User-specific information on which screen to open first when the
app is started.

The list goes on.....


This is such a huge loss of functionality that I am still
thinking I must just be missing something.

 

[(PeteCresswell)]

Per (PeteCresswell):

This is such a huge loss of functionality that I am still
thinking I must just be missing something.

This not say it's the end of an era or anything like that - bc I
*think* I can amend the .BAT file that executes the app to have a
REGEDIT line that adds/updates a registry entry which contains
the UNC of the text file that I have been using as the ".INI"
file.

From there, it's just writing a routine to return that UNC from
the registry. Also, if the registry entry is not found, one
could code to supply some default path.

But still.... we've now added a needless level of
complexity/arcane-ness to something that used to be simple as
dirt.

 

[Tony Toews]

This not say it's the end of an era or anything like that - bc I
*think* I can amend the .BAT file that executes the app to have a
REGEDIT line that adds/updates a registry entry which contains
the UNC of the text file that I have been using as the ".INI"
file.

From there, it's just writing a routine to return that UNC from
the registry. Also, if the registry entry is not found, one
could code to supply some default path.

But still.... we've now added a needless level of
complexity/arcane-ness to something that used to be simple as
dirt.

Why not pass the UNC of the INI file on the server in the msaccess.exe
/cmd command line argument ? Then the code can read that using the
command function?

"C:\Program Files\Microsoft Office 2003\OFFICE11\MSACCESS.EXE" "Q:\1
access\NewsgroupAnswers.mdb" /cmd "XXX"

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

 

[Tony Toews]

Ahh, I've never used the INI settings myself so I didn't unerstand how
it worked. Bascially though this INI file does not do anything for
Access itself. Instead you are reading all the settings using VBA
code.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

 

[David W. Fenton]

The list goes on.....

This is such a huge loss of functionality that I am still
thinking I must just be missing something.

It looks like you are using your INI file as a database.

Hmmm.

I wonder what possible solutions to that there might be?

 

[David W. Fenton]

I
*think* I can amend the .BAT file that executes the app to have a
REGEDIT line that adds/updates a registry entry which contains
the UNC of the text file that I have been using as the ".INI"
file.

Have you forgotten about my suggestion to use the /cmd switch to
pass in a command that your app can then react to?

 

[(PeteCresswell)]

Per David W. Fenton:

Have you forgotten about my suggestion to use the /cmd switch to
pass in a command that your app can then react to?

Yes. Mea Culpa - and to Tony too.

That nails it 100%: no registry, just a little tweak to extract
it from the command line.

Sometimes I think when I was born, they just should have done the
pillow thing and put me out of my misery right then and there....
-)

 

[(PeteCresswell)]

Per David W. Fenton:

Hmmm.

I wonder what possible solutions to that there might be?

Yes and no.

The essential features are:

1) Easy to browse and update via NotePad.

2) Simple to read from/write to within the
application.

3) No chicken-egg conflicts where the app needs data,
but does not know where data live yet.

4) Free-form.


Don't knock it until you've tried it... it's *really* powerful.

 

[David W. Fenton]

Per David W. Fenton:

Yes and no.

The essential features are:

1) Easy to browse and update via NotePad.

So far as I can tell, this is the only thing storing it in a data
table does not accomplish, and it seems an artificial requirement to
me.

2) Simple to read from/write to within the
application.

3) No chicken-egg conflicts where the app needs data,
but does not know where data live yet.

4) Free-form.

Don't knock it until you've tried it... it's *really* powerful.

I basically don't store any user configuration data anywere in any
of my apps. My users have not complained.

 

[David W. Fenton]

Per David W. Fenton:

Yes. Mea Culpa - and to Tony too.

That nails it 100%: no registry, just a little tweak to extract
it from the command line.

Sometimes I think when I was born, they just should have done the
pillow thing and put me out of my misery right then and there....
-)

That's a terrible thing to say!