 | |
Replication as a Performance Enhancer?
comp.databases.ms-access comp.databases.ms-access
 |
| | Thread Tools | Display Modes |
#21
 
| |||
| |||
|
Re: Replication as a Performance Enhancer? -
01-28-2009
, 09:53 AM
|
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. * When a user is logged into a terminal server, their user profile |
of wan or lan, data stored in the user profile will always be local
when logged in). An exception to this is if there is a folder
redirection policy enabled, which is the case for many terminal server
installations (like mine) but is not the default.
#22
| |||
| |||
|
|
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. I disagree. They all shared the same front end because that's how TS operates. Even if the temp files had been in a separate folder, it would have been the same -- they would have all shared the same temp files. 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. Again, disagree that that had anything to do with it. 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. And that's what I was saying in the first place -- that with TS, you haveto have separate directories for each user. That's what my point was. And you're agreeing with me. So what's the issue? 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. Again, disagree that the problems are caused by design errors in the app, but, rather, by how TS operates. So I'm sort of missing the point, I guess. The point was that migrating to TS would require restructuring how the users have their apps set up, that each user would have to have their own custom directory, etc. I was not "objecting" to TS; I was just saying that it's more involved than just setting up some software, and that if he can finda solution to his problem without having to through the time and expense of TS, then that might be better. Neil |
the FE anywhere but the terminal server user profiles directory, which
you can set with group policy to be any network share accessible to
the server. When a user logs in to the TS, their profile is cached
locally and everything 'just works'. All you need to do is make sure
your TS users group has full permissions for the BE.
When the user logs off, the profile is written back to it's original
location, so any changes made to the FE (an update via AutoFE, for
example (which absolutely ROCKS btw)) persist to the user's next
session.
#23
| |||
| |||
|
|
The point was that migrating to TS would require restructuring how the users have their apps set up, that each user would have to have their own custom directory, etc. I was not "objecting" to TS; I was just saying that it's more involved than just setting up some software, and that if he can find a solution to his problem without having to through the time and expense of TS, then that might be better. Neil |
the FE anywhere but the terminal server user profiles directory, which
you can set with group policy to be any network share accessible to
the server. When a user logs in to the TS, their profile is cached
locally and everything 'just works'. All you need to do is make sure
your TS users group has full permissions for the BE.
When the user logs off, the profile is written back to it's original
location, so any changes made to the FE (an update via AutoFE, for
example (which absolutely ROCKS btw)) persist to the user's next
session.
======================================
Well "easier" is a relative term. I'm not saying it's extraordinarily
difficult; only that it requires additional steps from just giving a person
an installation package, and having them install it locally. One also needs
to manage all the users using TS with the users who need updating, etc.,
etc. Just additional steps, is all.
But this is all very interesting, you know. In the early days of computing,
back when people used mainframes and all, the terminals were "dumb," and all
the applications were run on the back end. Then they came out with PCs, and
having "smart" terminals that did processing on the client side was seen a
step forward. Now, with Google Apps and Terminal Services and the like, the
pendulum is swinging back to server-side applications. Eventually the
limitations of that will be seen, and the pendulum will swing back the other
way again. But, for now, having "everything in one place," not having to
worry about different versions of drivers, being able to work over long
distances, etc, are seen as big advantages. But there was a reason the
computing world went to client-side applications in the first place. It's
not like everyone's been confused these past 30 years, and now, all of a
sudden, we're realizing that server-side apps are the way to go. But, for
the needs of the moment it works.
#24
| |||
| |||
|
|
One person in another thread suggested the temp folder which is also reasonable enough so long as something is available such as the Auto FE Updater to update it if the temp folder is cleared out. Not to mention that the temp folder sometimes contains thousands of files, which could slow performance if the system starts to bog down because of it. And the ability of the user to clear the temp folder (and not have a reason not to, since it is a "temp" folder) is reason enough, IMO, not to put it there. Even I was aware that the app was installed there, I wouldn't want to not be able to clear my temp folder, or have to perform additional steps of reinstallation if I cleared my temp folder. |
by running an exe and INI file on the server and does it's thing. If the files and
shortcuts don't exist they are recopied from the server. So you could clean out
your temp folder all you want and it wouldn't matter.
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/
#25
| |||
| |||
|
|
...having the temporary data in a separate MDB file wouldn't eliminate the need for everyone to have their own folder. That was my point. Agreed. But the temp file is not the reason you need a separate folder for each user. The reason you need it is because each user *must* have an individual copy of the front end. |
then you would want a separate folder per user.
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/
#26
| |||
| |||
|
|
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. * When a user is logged into a terminal server, their user profile (roaming or not) is cached on that server (which means that regardless of wan or lan, data stored in the user profile will always be local when logged in). An exception to this is if there is a folder redirection policy enabled, which is the case for many terminal server installations (like mine) but is not the default. |
systems.
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/
#27
| |||
| |||
|
|
What you're missing is that on a workstation everyone has their own folder, too. But it's because they are running on a non-shared machine. It should be obvious to anyone who gives the matter about 30 seconds of thought that a machine with multiple users running the same application will not be able to use the exact same directory on the hard drive for each user. |
that it's *possible* (not actual; but possible) that an application like TS
could *internally* give users their own copies of all files, and only use
whatever exists on the hard drive as templates, if you will, so that, when a
user opens c:\somedir\someapp.mdb, they're actually opening a copy of it
that TS creates. Or, at the very least, the TS administrator could have the
option to set TS to having users use the actual files, or automatically
create individual copies for the users, perhaps even setting the option for
individual directories to one or the other.
So I'm saying that it's *possible* that a program like TS could have the
option to automatically create copies of the files the user uses, so that
two users do not use the same files. That is a possibility.
So when I said that with TS you have to create individual subdirectories for
users and give them their own copies of files, that's not necessarily a
given. It is possible, in the grand scheme of things, that TS could have
been written to do that automatically, if the admin set that option. But it
was not written that way. And that was the point I was making. Because I
usually give things 31 seconds worth of thought, not just 30 seconds' worth.
;-)
Quote:
|
You seem to me to be making this out as some kind of nefarious, difficult issue for running an app on Terminal Server. It's not. It's really quite simple to address, as you yourself discovered. |
several times. I think you're dragging this out far more than is really
warranted by what I said, turning it into some big debate. All I said to the
OP was that, if he went with TS, it would require him restructuring how his
app is set up a bit, and managing which users are connected to TS, making
sure that those users get their own directories, are updated, etc. I never
said it was a huge deal; just that it was something to consider, and was
additional work beyond just installing the software.
#28
| |||
| |||
|
|
"Neil" <nrgins (AT) gmail (DOT) com> wrote: One person in another thread suggested the temp folder which is also reasonable enough so long as something is available such as the Auto FE Updater to update it if the temp folder is cleared out. Not to mention that the temp folder sometimes contains thousands of files, which could slow performance if the system starts to bog down because of it. And the ability of the user to clear the temp folder (and not have a reason not to, since it is a "temp" folder) is reason enough, IMO, not to put it there. Even I was aware that the app was installed there, I wouldn't want to not be able to clear my temp folder, or have to perform additional steps of reinstallation if I cleared my temp folder. Good points except for the install if you are using the Auto FE Updater. It starts by running an exe and INI file on the server and does it's thing. If the files and shortcuts don't exist they are recopied from the server. So you could clean out your temp folder all you want and it wouldn't matter. |
which means the user would lose that if it got cleared out. (In the case of
my app, I mentioned user selections as local data that would be stored with
the front end). And, even though shortcuts would be reinstalled, presumably
the desktop shortcut wouldn't end up in the same place as its predecessor,
which would be a small, but potentially annoying thing, for the user.
But, in any case, we're talking here about installing in a temp directory,
which I don't think most people would do anyway. But as a hypothetical
consideration it's an interesting discussion.
Neil
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.