Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.databases.ms-access > #9033 > unrolled thread

Access 2010: Is /INI Back?

Back to article view | Back to comp.databases.ms-access

Contents

  Access 2010: Is /INI Back? "(PeteCresswell)" <x@y.Invalid> - 2014-02-18 17:14 -0500
    Re: Access 2010: Is /INI Back? "Albert D. Kallal" <PleaseNOSpamkallal@msn.com> - 2014-02-19 16:02 -0700
      Re: Access 2010: Is /INI Back? "(PeteCresswell)" <x@y.Invalid> - 2014-02-20 09:27 -0500
        Re: Access 2010: Is /INI Back? Neil <xxx@gmail.com> - 2014-03-12 21:24 -0500
      Re: Access 2010: Is /INI Back? Neil <xxx@gmail.com> - 2014-03-12 21:07 -0500
    Re: Access 2010: Is /INI Back? "Access Developer" <accdevel@gmail.com> - 2014-02-20 13:27 -0600
      Re: Access 2010: Is /INI Back? "(PeteCresswell)" <x@y.Invalid> - 2014-02-20 16:02 -0500
        Re: Access 2010: Is /INI Back? "Access Developer" <accdevel@gmail.com> - 2014-02-20 15:35 -0600
        Re: Access 2010: Is /INI Back? "Joan Wild" <joanwild@xplornet.com> - 2014-02-20 21:56 +0000
        Re: Access 2010: Is /INI Back? "Albert D. Kallal" <PleaseNOSpamkallal@msn.com> - 2014-02-20 23:48 -0700
          Re: Access 2010: Is /INI Back? "(PeteCresswell)" <x@y.Invalid> - 2014-02-21 10:03 -0500
            Re: Access 2010: Is /INI Back? "Albert D. Kallal" <PleaseNOSpamkallal@msn.com> - 2014-02-21 15:57 -0700

#9033 — Access 2010: Is /INI Back?

MS dropped the backward-comparability ball going from 2003 to 2007 in
that the /INI command-line parm was lost.

Did they fix that in 2010?

I'm still waiting for The Powers That Be to approve the Office 2010
install on my PC, so I can't tell myself yet - but knowing will let me
get started on some /INI-dependent stuff.

-- 
Pete Cresswell

[toc] | [next] | [standalone]

#9037

I never used the /ini, but if it been dropped, then I much have to assume it 
remains dropped.

I quite sure for the 20+ year history of the office we find that when 
something is removed, then it is VERY rate that something is returned.

You have to give me a reasonable example where something in office was 
removed, and then was returned?

So given my basic experience in this industry and without knowing your 
answer, I think one based on common sense and using simple reason and logic 
should likely suggest that if ini support was dropped in 2007, then it 
remains dropped in 2010.

I guess I am trying to apply reason and logic here  and you seem to be 
suggesting that we drop all our experience in our industry and hope 
something going to occur that I am not aware has EVER occurred in office for 
the last 20 years?

You might want to explain what you were doing in the past with the .ini 
stuff, and I cannot say I much ever have seen any posts in regards to using 
.ini here.

I see that even 97 not supposed to support the /ini here:
http://support.microsoft.com/kb/105128

They state that /ini works for version 2!!

Quite sure over the years use of ini is very rare and few have used this 
feature in recent years, if not much at all in the last 10 years.

The above article also suggests that /ini been replaced with /profile.

I believe /profile will work with Access 2010 but you must ALSO include a 
workgroup file – even for a accdb. So you might have to use/include a 
"dummy" workgroup. So some testing here might be in order.

Best regards,
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
kallal@msn.com 

[toc] | [prev] | [next] | [standalone]

#9038

Per Albert D. Kallal:
>You might want to explain what you were doing in the past with the >.ini stuff, and I cannot say I much ever have seen any posts in
> regards to using .ini here.

My apps run on user PCs and automagically connect to back ends on file
servers or SQL servers.   The address of the back end server is in the
.INI file, along with a lot of other user-specific stuff.

Using a single file-server-based .INI file for everybody also makes the
application easily installable on any PC running Access: I just
drag/drop a shortcut that points to a .BAT file that does all the heavy
lifting.

-- 
Pete Cresswell

[toc] | [prev] | [next] | [standalone]

#9142

On 2/20/2014 8:27 AM, (PeteCresswell) wrote:
> My apps run on user PCs and automagically connect to back ends on file
> servers or SQL servers.   The address of the back end server is in the
> .INI file, along with a lot of other user-specific stuff.
>
> Using a single file-server-based .INI file for everybody also makes the
> application easily installable on any PC running Access: I just
> drag/drop a shortcut that points to a .BAT file that does all the heavy
> lifting.
>

OK, so here's an alternative approach for you, in lieu of using a .INI file.

You say that the main reason for the .INI file is to point to the back 
end server. So, different shortcuts have different /INI values, which 
then point to different .INI files, which contain different paths.

So, instead of that:

1) Create a front end table (called, tentatively, tsysPaths), which 
lists all the back end server addresses, and an ID (numeric or text) for 
each.

2) In each shortcut, use the /Cmd switch instead of the /INI switch, and 
give it one of the path's ID values, corresponding to the appropriate 
back end address.

3) In your startup routine, before you relink the back end tables, get 
the value of Command(), which will be the path ID from the shortcut. 
Using that, look up the back end address in tsysPaths.

4) Relink your tables using the back end path you got from tsysPaths.

If you need to get more than one value for the ID, then simply add 
another column to the tsysPaths table (perhaps then renamed to tsysInfo 
or whatever) called InfoType (or whatever). Then, for each ID value, 
there can be multiple entries, one for each InfoType value. Knowing the 
ID from the shortcut/Command() function, you could get all the info you 
need.

Now, if you don't want to hard-code these values into the front end, 
then you can simulate an INI file as follows:

1) Create a new MDB or ACCDB.

2) Create a single table in the file that would be tsysInfo or tsysPaths 
or whatever.

3) Link that table to the front end.

Then, in your startup routine, FIRST relink the tsysInfo table, and then 
use it as described above to get all the other values. That way, you can 
have the table separate from the front end, and you can just drop it on 
the user's machine.

As for the location of the tsysInfo MDB or ACCDB, I would just put it in 
the same folder as the front end. Then have Access look for it in 
whatever folder the front end is in (using CurrentProject.Path to get 
that). Or you could just put it in a Windows folder and link to it there.

Hope that helps!!

Neil

[toc] | [prev] | [next] | [standalone]

#9141

On 2/19/2014 5:02 PM, Albert D. Kallal wrote:
> The above article also suggests that /ini been replaced with /profile.
>
> I believe /profile will work with Access 2010 but you must ALSO include
> a workgroup file – even for a accdb. So you might have to use/include a
> "dummy" workgroup. So some testing here might be in order.

Interesting that that article says that /profile is only for Access 7 
and 97! So it seems even that has been done away with.

[toc] | [prev] | [next] | [standalone]

#9043

Pete, if I recall correctly, .INI files were the Windows 3.1 and earlier 
precursor to the Registry that made its debut, also IIRC, in Windows 2000. 
It was Microsoft's intent that developers use the Registry for the purposes 
for which .INI files were intended, but maintained .INI for backward 
compatibility. .INI, being text files, were easy for even amateur hackers to 
use for mischief. Of course the hacker community is so clever that they not 
only figured out the Registry, but were able to make use of new features it 
provided.

I suspect it would take a groundswell of demand from enterprise customers 
for .INI files to be brought back, and my cloudy crystal ball does not 
indicate that groundswell of demand.

-- 
Larry Linson
  Microsoft Office Access MVP
  Co-Author, Microsoft Access Small Business Solutions, Wiley 2010



"(PeteCresswell)" <x@y.Invalid> wrote in message 
news:lmm7g91997893hlaqu2kh1p4st596ibmu4@4ax.com...
> MS dropped the backward-comparability ball going from 2003 to 2007 in
> that the /INI command-line parm was lost.
>
> Did they fix that in 2010?
>
> I'm still waiting for The Powers That Be to approve the Office 2010
> install on my PC, so I can't tell myself yet - but knowing will let me
> get started on some /INI-dependent stuff.
>
> -- 
> Pete Cresswell 

[toc] | [prev] | [next] | [standalone]

#9044

Per Access Developer:
>Pete, if I recall correctly, .INI files were the Windows 3.1 and >earlier precursor to the Registry that made its debut, also IIRC,
> in Windows 2000. 
>It was Microsoft's intent that developers use the Registry for the
>purposes for which .INI files were intended, but maintained .INI
>for backward compatibility. .INI, being text files, were easy for
>even amateur hackers to use for mischief. Of course the hacker
>community is so clever that they not only figured out the Registry,
>but were able to make use of new features it provided.
>
>I suspect it would take a groundswell of demand from 
>enterprise customers for .INI files to be brought back, 
>and my cloudy crystal ball does not indicate that groundswell of
>demand.

.INI files are alive and well.  It's just that the developer has to add
a little code to parse the UNC from the command line instead of having
it conveniently delivered via the .INI property.

Regarding "...the purposes for which .INI files were intended..", I
don't know what the intent of the DOS developers was, but things become
useful even though their creators had not imagined that utility.

To the extent that using the registry means an Access app has to be
"Installed" on each users PC while using a shared .INI files obviates
that, I'd say that the registry is dysfunctional for those particular
purposes and the .INI file is functional.

The concept will never go away...maybe just the API calls that make it
more convenient.
-- 
Pete Cresswell

[toc] | [prev] | [next] | [standalone]

#9045

I always liked the ease of using .INI, and detested (still do) the 
Registry -- as with most well-intentioned improvements to our security, what 
it did was complicate the life of the legitimate user/developer, and was but 
a temporary barrier, if any, to the malicious hacker. There was a promise 
somewhere along the way, that the Registry would soon be gone, installation 
not required, just copy and execute -- but it seems someone 'thought better' 
of that or, more likely, it was an empty promise from someone to whom it 
sounded good, but who didn't realize the complexities of windows would make 
it impossible to accomplish.

  -- 
  Larry

"(PeteCresswell)" <x@y.Invalid> wrote in message 
news:h2rcg9toj0hbh4puob6nmv1043fvsjkqej@4ax.com...
> Per Access Developer:
>>Pete, if I recall correctly, .INI files were the Windows 3.1 and >earlier 
>>precursor to the Registry that made its debut, also IIRC,
>> in Windows 2000.
>>It was Microsoft's intent that developers use the Registry for the
>>purposes for which .INI files were intended, but maintained .INI
>>for backward compatibility. .INI, being text files, were easy for
>>even amateur hackers to use for mischief. Of course the hacker
>>community is so clever that they not only figured out the Registry,
>>but were able to make use of new features it provided.
>>
>>I suspect it would take a groundswell of demand from
>>enterprise customers for .INI files to be brought back,
>>and my cloudy crystal ball does not indicate that groundswell of
>>demand.
>
> .INI files are alive and well.  It's just that the developer has to add
> a little code to parse the UNC from the command line instead of having
> it conveniently delivered via the .INI property.
>
> Regarding "...the purposes for which .INI files were intended..", I
> don't know what the intent of the DOS developers was, but things become
> useful even though their creators had not imagined that utility.
>
> To the extent that using the registry means an Access app has to be
> "Installed" on each users PC while using a shared .INI files obviates
> that, I'd say that the registry is dysfunctional for those particular
> purposes and the .INI file is functional.
>
> The concept will never go away...maybe just the API calls that make it
> more convenient.
> -- 
> Pete Cresswell 

[toc] | [prev] | [next] | [standalone]

#9046

(PeteCresswell) wrote:

> .INI files are alive and well.  It's just that the developer has to
> add a little code to parse the UNC from the command line instead of
> having it conveniently delivered via the .INI property.
> 

Tony's FE Updater uses ini files.

[toc] | [prev] | [next] | [standalone]

#9047

"(PeteCresswell)"  wrote in message 
news:h2rcg9toj0hbh4puob6nmv1043fvsjkqej@4ax.com...

>To the extent that using the registry means an Access app has to be
>"Installed" on each users PC while using a shared .INI files obviates
>that, I'd say that the registry is dysfunctional for those particular
>purposes and the .INI file is functional.
>
>The concept will never go away...maybe just the API calls that make it
>more convenient.
>-- 
>Pete Cresswell

I have extensive use of .ini files and my Inno scripts contain a gazilion 
settings from SQL server names, install paths, current customer features.

And yes I use the windows API to mange and pull these features out of the 
.ini file.

However the above is MASSIVE different issue and use of .ini files compared 
to the "switch" to use a .ini file with Access.

As I stated, the /profile or /ini switch for older versions of Access is 
really not much of a big deal, and such a feature did not "magic" ALLOW you 
to all of a sudden use and read values out of a .ini file in which you read 
out settings.

So lets be SUPER CLEAR here on distinguishing on those that choose and 
continue to use .ini files for config stuff - such configuration files DO 
NOT benefit in any way I can think of by the "older" support of the /.ini 
switch in Access. In fact that /switch has ZERO effect on YOUR CHOICE to use 
such .ini files for user settings to my knowledge.

So yes, do I still use .ini files for my install and setup scripts? Yes of 
course I do!
Do I have Access read many of the settings from a .ini file on startup?  yes 
of course I do!

But this ability is 100% UN-RELATED to the build in support of the /profile 
or /ini switch that most of use never used and does not have any real value 
anyway.

I not sure where the big "meltdown" here occurred in which we talking about 
saving settings in a .ini file, and that of the /ini switch which has "zero" 
use these days and has not for what, 20 years?

If you saying that you need to specify some server side path name, then I 
would suggest using a default local .ini that is assumed to be in the SAME 
local dir as the front end, and inside that .ini you have the path name to 
the server side .ini

Last but not least:

If you are saying that the /ini switch allowed you to select/use different 
.ini on startup and you JUST were pulling out the path name specified in the 
.ini switch?
Well then YES you have a REALLY good point that such a switch is rather 
useful.

Are you suggesting that in the past you grabbed the /ini path name based on 
the /ini switch?
If this was/is the case, then in fact I gracefully accept your point and it 
is well taken - this would be a missed feature then.


Best regards,
-- 
Albert D. Kallal  (Access MVP)
Edmonton, Alberta Canada
PleaseNoSpam_kallal@msn.com 

[toc] | [prev] | [next] | [standalone]

#9048

Per Albert D. Kallal:
>If you saying that you need to specify some server side path name, then I 
>would suggest using a default local .ini that is assumed to be in the SAME 
>local dir as the front end, and inside that .ini you have the path name to 
>the server side .ini

But with 20 users, what happens when one wants to use a different back
end?   Sounds like a couple hours going from PC to PC making that little
change instead of just making it in the shared .INI file.

-- 
Pete Cresswell

[toc] | [prev] | [next] | [standalone]

#9051

"(PeteCresswell)"  wrote in message 
news:5jqeg99infsp01vlun5hr7cr70dahphrad@4ax.com...

Per Albert D. Kallal:
>>If you saying that you need to specify some server side path name, then I
>>would suggest using a default local .ini that is assumed to be in the SAME
>>local dir as the front end, and inside that .ini you have the path name to
>>the server side .ini
>
>But with 20 users, what happens when one wants to use a different back
>end?   Sounds like a couple hours going from PC to PC making that little
>change instead of just making it in the shared .INI file.
>
>-- 
>Pete Cresswell

Well, that's what this statement handles:

>> a default local .ini that is assumed to be in the SAME
>>local dir as the front end, and inside that .ini you have the path name to
>>the server side .ini (which resides in the same dir as the back end)

In other words, the local .ini ALSO has the last linked path name to the 
current active back end. That’s how you can automatic re-link after updating 
a NEW front end.
So you "need" the path name to the active back end stored OUTSIDE of the 
front end if you going to have some automated re-link on startup after a 
update.

So the local .ini file has this path name to the back end. Thus you have a 
path name to the server side .ini file. So my whole point here is that 
nothing is stopping you from "assuming" or using a .ini file that is assumed 
to be in the same location as the back end. If you don't want or care or 
need a "default" local .ini in the same dir as the front end, then there not 
a need for such.

One could always assume that the .ini file used is the one in the same 
dir/location as the current linked back end (I sure we all have code to get 
the "current" path name to the current linked back end - I certainly do). So 
the above suggestion is exactly what I do right now - the front end .ini has 
several settings, including the location of the LAST known linked back end. 
With that path name you thus simply read + use the .ini file from the same 
dir as the back end. Certainly does not suggest  any need to go from machine 
to machine.

Furthermore, there are settings that you may want to keep/hold local such as 
a default printer or some such - they cannot go in the global shared .ini on 
the server.

best regards,
-- 
Albert D. Kallal  (Access MVP)
Edmonton, Alberta Canada
PleaseNoSpam_kallal@msn.com

[toc] | [prev] | [standalone]

Back to top | Article view | comp.databases.ms-access

csiph-web