Remote Desktop Services and Users Overlaying each other's data!

[John]

I have been running a production access front end to a back end Oracle
DB via ODBC.
We recently moved the application to a Windows Remote Desktop Server
and allowed our overseas users to get better performance.
The system uses a Logon to set up a User View query that limits the
user'v view to his or her country's data. Come to find out, the last
user in, changes EVERYBODY's user view to his own. That is, even
though they are on separate access sessions on the server this all
important local query gets overlaid by the last user logging in.
I thought each session was as independent as if running on a separate
local client?!
Help much appreciated as this is live.
John

 

[David W. Fenton]

m:

I have been running a production access front end to a back end
Oracle DB via ODBC.
We recently moved the application to a Windows Remote Desktop
Server and allowed our overseas users to get better performance.
The system uses a Logon to set up a User View query that limits
the user'v view to his or her country's data. Come to find out,
the last user in, changes EVERYBODY's user view to his own. That
is, even though they are on separate access sessions on the server
this all important local query gets overlaid by the last user
logging in. I thought each session was as independent as if
running on a separate local client?!
Help much appreciated as this is live.

Is everybody opening the same front end? If so, that's the source of
the problem. You should never, ever, under any circumstances share a
front end in any scenario whatsoever. Each user needs an individual
copy of the front end. That's the only proper way to distribute an
Access app on workstations and exactly the same thing applies to
Terminal Server users, too. There is absolutely nothing different
about running in a Terminal Server session that magically makes it
possible to share a front end.

 

[John]

Is everybody opening the same front end? If so, that's the source of
the problem. You should never, ever, under any circumstances share a
front end in any scenario whatsoever. Each user needs an individual
copy of the front end. That's the only proper way to distribute an
Access app on workstations and exactly the same thing applies to
Terminal Server users, too. There is absolutely nothing different
about running in a Terminal Server session that magically makes it
possible to share a front end.

David,
Thanks for your response.
The business data (back end) does reside remotely in an Oracle db
accessed via ODBC. However, key local variables sit on the "client
side". These include the all important "UserView" delimeters, that are
getting overlaid.!
I was thinking of pushing those session variables (user views) over to
Oracle as well, but your post leads me to the realization that I
should skip that and change my remote desktop approach to in fact
replicate the MDB for each user folder on the remote desktop virtual
server! (just as we do for each client pc in the office.) Kind of a
pain, in that every new release requires more distribution steps and
it will also take up more space at 20 meg per mdb instance, but I hear
your guidance:"never, ever, under any circumstances" use an overlaid
MDB."

I appreciate, we appreciate, your help here.
Thanks
John

 

[David W. Fenton]

m:

I was thinking of pushing those session variables (user views)
over to Oracle as well, but your post leads me to the realization
that I should skip that and change my remote desktop approach to
in fact replicate the MDB for each user folder on the remote
desktop virtual server! (just as we do for each client pc in the
office.) Kind of a pain, in that every new release requires more
distribution steps and it will also take up more space at 20 meg
per mdb instance, but I hear your guidance:"never, ever, under any
circumstances" use an overlaid MDB."

It's no more of a pain in a terminal server environment than with
regular desktops. Indeed, it's exactly the same set of issues.

And Tony Toews's Auto FE Updater makes it pretty easy (including
full support for Terminal Server/Citrix environments):

http://www.autofeupdater.com/

 

[John]

It's no more of a pain in a terminal server environment than with
regular desktops. Indeed, it's exactly the same set of issues.

And Tony Toews's Auto FE Updater makes it pretty easy (including
full support for Terminal Server/Citrix environments):

 http://www.autofeupdater.com/

Thanks again David.
I will check out Auto FE updater for sure.
Also, our systems admin made the change in minutes and assured me that
20 megs is "tiny" for an application size. Breathing easier about this
app now as every user uses his own version.
Much obliged.
John

 

[Tony Toews]

I will check out Auto FE updater for sure.

If you have any problems please email me. Well, after checking out

Also, our systems admin made the change in minutes and assured me that
20 megs is "tiny" for an application size. Breathing easier about this
app now as every user uses his own version.

Excellent.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

 

[David W. Fenton]

:

Also, our systems admin made the change in minutes and assured me
that 20 megs is "tiny" for an application size.

If you mean the front end is 20MBs, that would seem quite large to
me! Mine tend to be in the 5-10MB range (usually in the lower end of
that, and many smaller than that).

But it is true that 10 users with 20MBs each is still only 200MBs,
which with current disk space availability is still completely
trivial.