Re: Front-end / Back-end - Vista
- From: Jack Leach <dymondjack at hot mail dot com>
- Date: Sun, 26 Apr 2009 05:59:02 -0700
Trouble is if the user has a new FE which is linked to tables on the
developers system then how can get that path from a linked table?
Only use the FE after the install/firstrun flag file has been removed. If
it's a fresh install or new version there will be a flag file located in the
..mdb directory. Startup would look for this file, and perform all the
essentials (relinking to the BE via the path left behind by the install,
setting all the system variables in the BE after it's linked), and then
remove the flag file.
How do we know where the user are putting the files?
The data paths and any other variables would be written to file in the
install procedure, and distributed with the FE. On the FE's first run the
app relinks and sets variables in the backend.
I don't use database properties anyhow as I prefer to store variables
in a Global Options table in the BE or user specific variables in a
System Users table in the BE.
With the obvious exception of the path and file name of the BE which
has to be stored somewhere else on the users system.
Two particular peices of data I store are used more than anything else: the
BE root folder and the FE root folder. Just about every path used in the
project refer back to these two. I used to store them in a table, but wasn't
happy about having to read it from a table over the network every time I
needed to build a path. I had switched to storing these two in a constant
instead (Every computer I distribute to is easily within physical reach on a
normal work day), which freed up a lot of performance. I've recently
switched to properties and include the property settings as part of the
startup code.
So the system/user variables are stored in the back end, but on startup the
two root locations are set as a global property for efficient usage.
This is very much one of those things where there's 10k+ ways to do it
depending on personal preference and circumstance (isn't there always).
Thanks for the feedback on your methods. I'm currently in process of
revamping my core application coding, so I'll take any ideas I can get!
--
Jack Leach
www.tristatemachine.com
"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)
"Tony Toews [MVP]" wrote:
Jack Leach <dymondjack at hot mail dot com> wrote:.
I had meant to pull the path from a linked table in the BE on normal
startup,
Trouble is if the user has a new FE which is linked to tables on the
developers system then how can get that path from a linked table?
or pull it out of an install file if the file exists for the
installation, and relink the tables using it.
How do we know where the user are putting the files? In my opinion
the FE and related files should be inside the users APPData folder
while the data MDB should reside in the users My Documents folder.
And the user can override those if the installer lets them. And those
folders, of course are different for each user as the account name is
part of the path.
Anyway, an INI file makes much more sense... store that or any other hard
variables in there are read them through vba's file IO at startup.
Anywhere except in the FE or the BE.
If you don't mind Tony (or anyone else who knows), would you recommend
storing this in a property as I mentioned? I only starting using properties
like this a few months ago, and while I haven't come across any problems yet,
I haven't used it long enough to be fully confident in them and have had no
outside opinion on them yet.
You mean a database property? No I wouldn't again because if they
download a new FE then they lose the old FE's database property.
I don't use database properties anyhow as I prefer to store variables
in a Global Options table in the BE or user specific variables in a
System Users table in the BE.
With the obvious exception of the path and file name of the BE which
has to be stored somewhere else on the users system.
Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
- Follow-Ups:
- Re: Front-end / Back-end - Vista
- From: Tony Toews [MVP]
- Re: Front-end / Back-end - Vista
- References:
- Front-end / Back-end - Vista
- From: Rick Allison
- Re: Front-end / Back-end - Vista
- From: Tony Toews [MVP]
- Front-end / Back-end - Vista
- Prev by Date: Help with Stephen Lebans code
- Next by Date: Re: undo changes
- Previous by thread: Re: Front-end / Back-end - Vista
- Next by thread: Re: Front-end / Back-end - Vista
- Index(es):
Relevant Pages
|
