Re: Replication as a Performance Enhancer?

"Neil" <nrgins@xxxxxxxxx> wrote in
news:Hyufl.2243$PE4.488@xxxxxxxxxxxxxxxxxxxx:

And then you have the issue that, since TS users share a file,
there can be no local tables unless it's configured such that
each user has their own copy of the front end (multiple FE
copies in user directories; each user has their own shortcut
that points to their copy of the front end; need to maintain
that when updating the FE; etc.)

Sorry, but you lost me there. An Access app hosted on a Terminal
Server is no different than run from workstations -- each user
has her own copy of the front end. Tony Toews's front-end updater
is even written to handle this for you quite easily.

So, this is a complete non-issue, unless you're talking about
something I'm missing out on.

Keep in mind that there is *no* circumstance in any scenario
where a front end should be shared. Period. End of statement.

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.

Since Windows 2000, that's an improper location for files that have
to be writable by users, because the root of C: is read-only for
users. You either have to assign non-standard permissions, or have
your users running as administrators, which is inadvisable for so
many reasons I shouldn't have to outline.

The correct location for user-writable data is in user's profile.
There's some variation on how apps install their application files
and their data files, but the user profile is all writable by the
user.

Thus, when installing on an Access app on a workstation, the front
end should be installed in a folder under the user's profile. This
may or may not be the best place for that on a Terminal Server, but
there you have very easy control over permissions and will likely
have an NTFS security group for the users of your Terminal
Server-hosted app. Thus, it's quite easy to set up a location
outside the user profiles that can have a folder for each user and
that will have default permissions for the users that allow full
control.

That's one of the beauties of Terminal Server -- it puts all the
administratino of the app in one place, rather than spread across
all the workstations of your users.

And, by the way, if you're hardwiring a path into your app, that's a
huge error, as well, since it means that you are going to run into
precisely this kind of problem in the future.

The FE uses local tables which, for the most part, perform one of
two functions: either compile temporary data for reports; 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).

I don't see any issue at all with this, as nobody is suggesting
sharing a front end.

And on another note, it's not a good idea to put temp tables in your
front end, anyway, as it causes bloat. The usual practice is to have
a separate temp MDB linked from the front end.

If you're worrying about linking to that, it's not a big deal to run
code that looks for the temp file in the same folder as the front
end.

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.

When we went to TS for about a dozen users, we found that they all
shared teh same front end in c:\myaccessapp.

This is because you were doing it wrong -- your original design was
mistaken in the first place.

When one user would check the check
box, updating the local table's Yes/No field, it was as though
they all had done it. The selection was written to the MDB file in
c:\myaccessapp, and, since they all shared that same file, they
all got the same selections, defeating the purpose of having the
selection in the front end to begin with.

Proper design makes it very easy to avoid such problems.

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.

The base folder is wrong, but the idea is correct.

I realize one might say that the local tables shouldn't be in the
FE anyway;

They absolutely should not be.

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.

Yes, but you'd avoid the bloat problems in the front end.

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.

Seems to me you understand what you should be doing, so I don't
understand what your objections to Terminal Server are. It seems to
me that you are complaining about problems that are caused by design
errors in your application, and that you already know how to
resolve.

So I'm sort of missing the point, I guess.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
.

Relevant Pages

  • Re: Terminal server client and old dos programs
    ... When running on the console, will it run in windowed mode, or only full screen? ... No full-screen for DOS applications in Terminal Server. ... >> can get is by simulating full-screen with a window that covers the entire ... >> non-admins can't run the app, then it's a permissions or rights issue. ...
    (microsoft.public.windows.terminal_services)
  • Re: Detecting PC location through Terminal Services
    ... to deny access to our app from a specific workstation that may be at any of ... one of our developers was able to write a small app that ... or one of many other facilities. ... terminal server from, in a way that is passable to our custom ...
    (microsoft.public.windows.terminal_services)
  • Re: Application caching
    ... Terminal Server is in Malaysia for users in Singapore). ... at the same time on each workstation. ... scenario) would be at a minimum *all* instances of the exe ... close the app properly but it still remain running with no ...
    (microsoft.public.windows.terminal_services)
  • Re: Limit TS users to One App
    ... Which OS are you running on the Terminal Server? ... Using Software Restriction Policies to Protect Against Unauthorized ... then you can use the Application Security Tool: ... > group policy settings to limit a user to one app via hiding ...
    (microsoft.public.win2000.termserv.apps)
  • Re: QRe: Legacy Access 2 VB 4 app, Word 11 merge on XP Pro SP2 client
    ... selecting "blank database" or some such. ... possible to set a simple password on a whole mdb file, ... case, make sure you have a backup of the .mdw file, then launch Access ... >I could not get the app to accept the changes to Notepad within the ...
    (microsoft.public.access.conversion)