We have an immediate need to convert an MS Access 2003 app and
it's 2003 back end DB to 2007.

We do not want or need any of 2007's functionality at this
moment.

I'm thinking maybe the safest path would be to use each of those
DBs as 2003 .MDB files and just execute with 2007 -
converting/testing at some later date when we're not under the
gun any more.

Does this work for anybody? Or should I bite the bullet and
convert/test now rather than later?
--
PeteCresswell

(PeteCresswell) wrote:

Why????????

Per Bob Alston:
Why what? Convert or run as 2003?

--
PeteCresswell

You should be fine simply using the existing MDB files.

Check http://www.allenbrowne.com/Access2007.html at Allen Browne's site for
more information when you are ready to convert.

--
Doug Steele, Microsoft Access MVP
http://www.AccessMVP.com/DJSteele/AccessIndex.html
Co-author: "Access 2010 Solutions", published by Wiley
(no private e-mails, please)


"(PeteCresswell)" <x@y.Invalid> wrote

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.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.accessmvp.com
http://www.mvps.org/access
Co-author: "Access 2010 Solutions", published by Wiley


"(PeteCresswell)" <x@y.Invalid> wrote

Per Arvin Meyer:
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

On 6/25/10 8:56 AM, (PeteCresswell) wrote:
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?

Per Banana:
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

On 6/25/10 4:42 PM, (PeteCresswell) wrote:
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.

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.

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.