2003==>2007: Safest Path?
in [Help]
|
Prev: printing a report without blank pages after a record in Access 2007
Next: printing a report without blank pages after a record in Access2007
From: (PeteCresswell) on 25 Jun 2010 11:56 Per Arvin Meyer: >I would not convert at all. Just leave it alone. If you do not need later >version features, there is no reason to "upgrade" the app. Now that the /INI issue has surfaced, I'm leaning in that direction too. Only real reason so far to convert is that IT is pushing out Office 2007. OTOH, the install they use leaves Access 2003 intact and it's just a matter of modifying the execution/deployment .BAT file to look in the 2003-specific path instead of just calling "MSACCESS". I'm having trouble believing that /INI has gone away and there is no replacement: very un-Microsoft-Like. Even though it seems tb a holdover from 16-bit Access, it supplies what I consider tb some very useful functionality that cannot be supplied by registry entries. -- PeteCresswell
From: Banana on 25 Jun 2010 12:03 On 6/25/10 8:56 AM, (PeteCresswell) wrote: > I'm having trouble believing that /INI has gone away and there is > no replacement: very un-Microsoft-Like. Even though it seems > tb a holdover from 16-bit Access, it supplies what I consider tb > some very useful functionality that cannot be supplied by > registry entries. Looking at the help, it seems that /profile was the replacement for /ini. There's also SetOptions which I believe are far more preferable to than tinkering with registry. Exactly what functionality are you concerned you'll lose with /ini?
From: (PeteCresswell) on 25 Jun 2010 19:42 Per Banana: >Looking at the help, it seems that /profile was the replacement for >/ini. There's also SetOptions which I believe are far more preferable to >than tinkering with registry. > >Exactly what functionality are you concerned you'll lose with /ini? The ability to supply various parms (like the address of the back end, certain numbers, and so-forth) from one source - and the ability to make changes to that source quickly and easily. /Profile is a totally different animal - not even comparable IMHO - unless there is some way to just use it as a front end to a single text file; but even if that were possible I'd guess it would add several layers of complexity/possible points of failure to what is, with /INI, a beautifully-simple setup. Never heard of SetOptions... gotta look into it. -- PeteCresswell
From: Banana on 25 Jun 2010 19:57
On 6/25/10 4:42 PM, (PeteCresswell) wrote: > The ability to supply various parms (like the address of the back > end, certain numbers, and so-forth) from one source - and the > ability to make changes to that source quickly and easily. Thanks. I certainly can understand why INI files appeal so much having had used and appreciated same simple text file to configure various *nix programs. I don't go that far back with Access so missed the boat on that one. > /Profile is a totally different animal - not even comparable IMHO > - unless there is some way to just use it as a front end to a > single text file; but even if that were possible I'd guess it > would add several layers of complexity/possible points of failure > to what is, with /INI, a beautifully-simple setup. Well, one option is to use a local Config table that stores all parameters you need and have your startup code read the table to handle all startup. That does not solve the workgroup join as by that point, it's too late but should do the job for storing information on backend path and few other things, I would hope. > Never heard of SetOptions... gotta look into it. They're basically identical to what you can set in Registry. However, the reason why we should be using SetOptions/GetOptions is that they will be then temporary and thus does not require us to tinker the registry and having to remembering to set it back so it can be done on a per-application basis if that is required. FWIW, I rarely use SetOptions as the default usually are adequate but I've used it to good effects in those rare instances. HTH. |