Re: Replication as a Performance Enhancer?

"Neil" <nrgins@xxxxxxxxx> wrote:

With our Access app, we have the app installed in a directory, say
c:\myaccessapp. Each user has their own copy of the FE, each in the same
directory.

David mentions user profile. Let me get a bit more specific. Probably, and
generalizing without getting into TS, the best location is in the AppData folder on
the client PC. On my system this would be C:\Documents and
Settings\ttoews\Application Data\Granite Fleet Mgr as an example.

Now this isn't necessarily suitable in a TS environment as if they are not on the
same LAN then the FE is now being access by the TS system from the local PC. Not a
good idea if they are on a WAN.

I'm not sure that the best location would be in the TS system itself. And the IT
staff may not like doing that. So at the one client we stored the FEs in a user
specific folder on the same file folder as the backend.

The Auto FE Updater made this quite easy as I just put in the user name as a
parameter in the location line in the INI file.

The FE uses local tables which, for the most part, perform one of two
functions: either compile temporary data for reports;

See the TempTables.MDB page at my website which illustrates how to use a temporary
MDB in your app. http://www.granite.ab.ca/access/temptables.htm. This will help
keep bloating of the FE down.

or keep track of user
selections (there is a local table with two fields: a PK field,
corresponding to the PK field in the main table, and a Yes/No field). The
main form has a check box which is bound to this local table's Yes/No field;
the rest of the fields are bound to the shared main table.

I'm not sure what is going on with this table here but what happens when the FE is
replaced by a new version? You lose the the data in the local table. Unless this is
very temporary data such as parameters for a report.

We ended up having to give each user their own copy of the front end in
their own personal directory: c:\myaccessapp\bob, c:\myaccessapp\sally,
c:\myaccessapp\joe, etc.

Which is reasonable enough. Presumably the IT staff had to create that folder on the
TS system and give appropriate permissions.

I realize one might say that the local tables shouldn't be in the FE anyway;
that they should be in a separate file. But that would still amount to the
same thing, as they'd each have their own copy. of that separate file. Plus,
if I had code which created a temporary MDB file (for data compilation),
those MDBs would overwrite each other, as they'd be in teh same place.

If you created the temp MDB in the same folder as the FE then you wouldn't have the
problem if everyone had their own folder.

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

Relevant Pages

  • Re: Replication as a Performance Enhancer?
    ... in a hidden folder? ... MDB in your app. ... very temporary data such as parameters for a report. ... that they should be in a separate file. ...
    (comp.databases.ms-access)
  • Re: Deploying Access 2007 Runtime / developer extensions / basic MSI installer questions
    ... That folder might be a read only folder to regular users. ... How does Access treat varying environment variables for the linked BE? ... MDB. ... Tony Toews, Microsoft Access MVP ...
    (comp.databases.ms-access)
  • Re: DLL problem
    ... Putting all 37 in SYSTEM32 seems to get my VBA DLL calls to work. ... What happens if you put those in the same folder as your MDB? ... Tony Toews, Microsoft Access MVP ...
    (microsoft.public.access.gettingstarted)
  • Re: DSN Connection to Microsoft Access
    ... It is actually MDB (the extension of Microsoft Access) ... And does the account that ASP.NET is running under have write permissions on that folder? ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Database security
    ... That message would indicate that you do not have full permission to the ... Not really a Microsoft Access issue, ... you need FULL permission to the folder. ... > Is there a nice simple way I can get into the mdb? ...
    (microsoft.public.access.security)