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..... -)
--
PeteCresswell

"(PeteCresswell)" <(E-Mail Removed)> wrote in
news:(E-Mail Removed):

> 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).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Per David W. Fenton:
>> 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).

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.
--
PeteCresswell

On Wed, 23 Jun 2010 16:09:46 -0400, "(PeteCresswell)" <(E-Mail Removed)>
wrote:

>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/ac...010166605.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/

On Thu, 01 Jul 2010 17:46:12 -0600, Tony Toews
<(E-Mail Removed)> wrote:

>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/ac...988.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/

On Wed, 23 Jun 2010 16:09:46 -0400, "(PeteCresswell)" <(E-Mail Removed)>
wrote:

>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/

Per 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?

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.
--
PeteCresswell

On Fri, 02 Jul 2010 13:13:24 -0400, "(PeteCresswell)" <(E-Mail Removed)>
wrote:

>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/

On Thu, 01 Jul 2010 20:17:00 -0400, "(PeteCresswell)" <(E-Mail Removed)>
wrote:

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

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/