473,320 Members | 1,580 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Access on Citrix: will global vars come back to haunt me

DFS
An application I wrote has been deployed on Citrix, and the Citrix admin
tells me all users run the same .mde file. There aren't a lot of concurrent
users, but even 2 could be cause for concern.

I think the use of globals is worrisome in this case. Anybody have any
experience with Access on Citrix?

(Al Kallal already griped me out about globals, but if he has anything new
to add I'm all ears).
Thanks
Nov 13 '05 #1
33 3185
It doesn't matter how you try, you can't share VBA
globals between users.

There are several reasons for not using a shared file,
but use of VBA global variables is not one of them.

There are several reasons for not using VBA Globals,
but use of Citrix is not one of them.

(david)

"DFS" <nospam@dfs_.com> wrote in message news:bn***************@fe04.lga...
An application I wrote has been deployed on Citrix, and the Citrix admin
tells me all users run the same .mde file. There aren't a lot of
concurrent
users, but even 2 could be cause for concern.

I think the use of globals is worrisome in this case. Anybody have any
experience with Access on Citrix?

(Al Kallal already griped me out about globals, but if he has anything new
to add I'm all ears).
Thanks

Nov 13 '05 #2
Nicely put!

On Thu, 27 Oct 2005 19:08:14 +1000, "david epsom dot com dot au"
<david@epsomdotcomdotau> wrote:
It doesn't matter how you try, you can't share VBA
globals between users.

There are several reasons for not using a shared file,
but use of VBA global variables is not one of them.

There are several reasons for not using VBA Globals,
but use of Citrix is not one of them.

(david)

"DFS" <nospam@dfs_.com> wrote in message news:bn***************@fe04.lga...
An application I wrote has been deployed on Citrix, and the Citrix admin
tells me all users run the same .mde file. There aren't a lot of
concurrent
users, but even 2 could be cause for concern.

I think the use of globals is worrisome in this case. Anybody have any
experience with Access on Citrix?

(Al Kallal already griped me out about globals, but if he has anything new
to add I'm all ears).
Thanks


Nov 13 '05 #3
DFS
david epsom dot com dot au wrote:
It doesn't matter how you try, you can't share VBA
globals between users.
Which means Citrix (or Access itself) runs an instance for each user in a
separate memory space. Not really a separate instance for each (that would
be extremely inefficient), probably a pointer to the first instance.

There are several reasons for not using a shared file,
but use of VBA global variables is not one of them.
It's not my decision on using the single .mde.

There are several reasons for not using VBA Globals,
but use of Citrix is not one of them.
Gotcha.

Thanks

(david)

"DFS" <nospam@dfs_.com> wrote in message
news:bn***************@fe04.lga...
An application I wrote has been deployed on Citrix, and the Citrix
admin tells me all users run the same .mde file. There aren't a lot
of concurrent
users, but even 2 could be cause for concern.

I think the use of globals is worrisome in this case. Anybody have
any experience with Access on Citrix?

(Al Kallal already griped me out about globals, but if he has
anything new to add I'm all ears).
Thanks

Nov 13 '05 #4
From postings in this group and my experience with a number of consultants,
most Terminal sever / Citrix admins have no clue on how to run Access. They
to treat the MDE like an EXE. You will need to convince them that each user
must get a private copy of the MDE front end and share the Access program or
runtime.

"DFS" <nospam@dfs_.com> wrote in message news:bn***************@fe04.lga...
An application I wrote has been deployed on Citrix, and the Citrix admin
tells me all users run the same .mde file. There aren't a lot of concurrent users, but even 2 could be cause for concern.

I think the use of globals is worrisome in this case. Anybody have any
experience with Access on Citrix?

(Al Kallal already griped me out about globals, but if he has anything new
to add I'm all ears).
Thanks

Nov 13 '05 #5
On Thu, 27 Oct 2005 11:23:27 -0400, "DFS" <nospam@dfs_.com> wrote:
david epsom dot com dot au wrote:
It doesn't matter how you try, you can't share VBA
globals between users.


Which means Citrix (or Access itself) runs an instance for each user in a
separate memory space. Not really a separate instance for each (that would
be extremely inefficient), probably a pointer to the first instance.


Separate processes with separate data memory space, one copy of the Access EXE
and DLLs in memory.
There are several reasons for not using a shared file,
but use of VBA global variables is not one of them.


It's not my decision on using the single .mde.


I'd make 2 MDEs in the shared location. The first one is a loader that checks
whether the user's unique copy is up-to-date (stored under the user's
documents and settings somewhere), makes a new unique copy if it needs to be
updated, then opens the other MDE using Shell "...msaccess.exe
""<unique-mde-copy-path"" ".

It may sound like this would greately increase start-up time, but it turns out
to be very fast. Access.exe is only loaded into memory once, so launching a
separate instance is very low overhead.

Nov 13 '05 #6
DFS
Steve Jorgensen wrote:
On Thu, 27 Oct 2005 11:23:27 -0400, "DFS" <nospam@dfs_.com> wrote:
david epsom dot com dot au wrote:
It doesn't matter how you try, you can't share VBA
globals between users.
Which means Citrix (or Access itself) runs an instance for each user
in a separate memory space. Not really a separate instance for each
(that would be extremely inefficient), probably a pointer to the
first instance.


Separate processes with separate data memory space, one copy of the
Access EXE and DLLs in memory.


Which sounds like my global variables will be 'safe' inside the user
instance, and one user can't overwrite another's. I'll be running some
tests to ensure, but that sounds hopeful.

Since I didn't design the system for use on Citrix, and in past the client
did install a copy for each user, I also now face the issue of using a few
local tables for reporting and querying. I think those local tables in the
..mde will be shared by all users (looking at them, I got lucky and it won't
matter this time - but it could in other systems).

The bottom line: Citrix deployment can impact your Access system design.

There are several reasons for not using a shared file,
but use of VBA global variables is not one of them.


It's not my decision on using the single .mde.


I'd make 2 MDEs in the shared location. The first one is a loader
that checks whether the user's unique copy is up-to-date (stored
under the user's documents and settings somewhere), makes a new
unique copy if it needs to be updated, then opens the other MDE using
Shell "...msaccess.exe ""<unique-mde-copy-path"" ".


Not quite understanding you. The 'shared location' is on the Citrix Server.
All users run the same .mde. That .mde will always be up to date. The
users run the Access system from inside a web browser.

It may sound like this would greately increase start-up time, but it
turns out to be very fast. Access.exe is only loaded into memory
once, so launching a separate instance is very low overhead.

Nov 13 '05 #7
DFS
paii, Ron wrote:
From postings in this group and my experience with a number of
consultants, most Terminal sever / Citrix admins have no clue on how
to run Access. They to treat the MDE like an EXE. You will need to
convince them that each user must get a private copy of the MDE front
end and share the Access program or runtime.
That's what I thought would be the case as well. But I'm hearing
differently from others here in cdma. I'm hearing it won't matter that all
users run the same .mde.

This client has been sharing a single .mde on Citrix for 6 to 8 months
already, but I'm just now hearing about it.

The users haven't reported any problems, but I'm going to do some tests with
the Citrix admin at the client site, and I'll report back.

"DFS" <nospam@dfs_.com> wrote in message
news:bn***************@fe04.lga...
An application I wrote has been deployed on Citrix, and the Citrix
admin tells me all users run the same .mde file. There aren't a lot
of concurrent users, but even 2 could be cause for concern.

I think the use of globals is worrisome in this case. Anybody have
any experience with Access on Citrix?

(Al Kallal already griped me out about globals, but if he has
anything new to add I'm all ears).
Thanks

Nov 13 '05 #8

"DFS" <nospam@dfs_.com> wrote in message
news:3s*******************@fe05.lga...
paii, Ron wrote:
From postings in this group and my experience with a number of
consultants, most Terminal sever / Citrix admins have no clue on how
to run Access. They to treat the MDE like an EXE. You will need to
convince them that each user must get a private copy of the MDE front
end and share the Access program or runtime.
That's what I thought would be the case as well. But I'm hearing
differently from others here in cdma. I'm hearing it won't matter that

all users run the same .mde.

This client has been sharing a single .mde on Citrix for 6 to 8 months
already, but I'm just now hearing about it.

The users haven't reported any problems, but I'm going to do some tests with the Citrix admin at the client site, and I'll report back.

"DFS" <nospam@dfs_.com> wrote in message
news:bn***************@fe04.lga...
An application I wrote has been deployed on Citrix, and the Citrix
admin tells me all users run the same .mde file. There aren't a lot
of concurrent users, but even 2 could be cause for concern.

I think the use of globals is worrisome in this case. Anybody have
any experience with Access on Citrix?

(Al Kallal already griped me out about globals, but if he has
anything new to add I'm all ears).
Thanks



You can get away with sharing for a while, but when one of your users
crashes the app and corrupts the MDE, all your users will go down with him.
Also any local temp tables in the MDE are shared by all users, which can
cause them to interfere with each other. Search for Terminal server in this
group, I am sure others can give your more reasons to not share the front
end. Also check the Microsoft site for using Access on terminal server.
Nov 13 '05 #9
"DFS" <nospam@dfs_.com> wrote in news:Nh****************@fe04.lga:
It's not my decision on using the single .mde.


Then you're bound for a huge number of problems.

Each user *must* have their own copy of the front end. If they don't
it's never going to work reliably.

It's stupid of your admins to put such a restriction on you since
there is absolutely no justification for it at all. The additional
disk space and memory required are trivial by themselves, but even
moreso in comparison to the cost of recovering from the problems
that sharing a front end will cause.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #10
DFS
David W. Fenton wrote:
"DFS" <nospam@dfs_.com> wrote in news:Nh****************@fe04.lga:
It's not my decision on using the single .mde.
Then you're bound for a huge number of problems.


Maybe. Nothing has been reported to me in 6 months.

Each user *must* have their own copy of the front end. If they don't
it's never going to work reliably.
It's worked fine so far, but since I just found out about it I have to do
some due diligence tests to ensure some things. Basically I'm going to
launch the app in Citrix and check some global var values and some data in
local tables. Then launch second and third instances and check the globals
from those instances. If the globals are different/reset each time a user
runs the app, they're hosed. I reviewed the local table data and I'm
confident it won't be a problem.

5 years ago they deployed one of my apps on Citrix and installed a copy for
each user. I assumed they always did it that way. But with this latest
one, they're just now (6 mths later) telling me they're doing it
differently.

It's stupid of your admins to put such a restriction on you since
there is absolutely no justification for it at all. The additional
disk space and memory required are trivial by themselves, but even
moreso in comparison to the cost of recovering from the problems
that sharing a front end will cause.


I'd rather they run separate copies, and probably can convince them. But it
truly may not be an issue - it depends on the Citrix settings. The admin
tells me Citrix/2000 allows each user to run in their own protected memory
space and virtual channel.
Nov 13 '05 #11
"DFS" <nospam@dfs_.com> wrote in
news:xo*******************@fe05.lga:
The bottom line: Citrix deployment can impact your Access system
design.


No, it can't.

Terminal Server deployment should be exactly the same as deployment
on workstations -- one front end per user. Period.

Anyehing else is WRONG.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #12
"DFS" <nospam@dfs_.com> wrote in
news:3s*******************@fe05.lga:
paii, Ron wrote:
From postings in this group and my experience with a number of
consultants, most Terminal sever / Citrix admins have no clue on
how to run Access. They to treat the MDE like an EXE. You will
need to convince them that each user must get a private copy of
the MDE front end and share the Access program or runtime.


That's what I thought would be the case as well. But I'm hearing
differently from others here in cdma. I'm hearing it won't matter
that all users run the same .mde.


Who exactlyi in this newsgroup has ever recommended sharing a front
end?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #13
> 5 years ago they deployed one of my apps on
Citrix and installed a copy for
each user. I assumed they always did it
that way. But with this
5 years ago if they had deployed just one copy, it
might have crashed immediately, depending on their
server software. There was a bug in some of the NT
TS/Citrix code which caused the shared mdb to be
released when the first user disconnected -- thus
killing all other connections.
tells me Citrix/2000 allows each user to run in
their own protected memory
space and virtual channel.
Yes, Citrix has been fixed. Windows hasn't: by
reputation, the file system still seems to have
problems with shared files.

We are NOT talking about the shared copy of MSACCESS.EXE
In it's current version, Citrix won't have any problems
sharing one copy of that executable.

But Windows is not running the DOS 3.1 database API
against MSACCESS.EXE. It's the MDE/MDB's people here
are worried about.

I've got an Access 97 mde shared by three users on TS,
and I haven't had any problem. But then, unless you
have some spare A97 CD's, you are going to have problems
upgrading to that version. And my users only add 2 or 3
transactions per day.

(david)

"DFS" <nospam@dfs_.com> wrote in message
news:S4*******************@fe03.lga... David W. Fenton wrote:
"DFS" <nospam@dfs_.com> wrote in news:Nh****************@fe04.lga:
It's not my decision on using the single .mde.


Then you're bound for a huge number of problems.


Maybe. Nothing has been reported to me in 6 months.

Each user *must* have their own copy of the front end. If they don't
it's never going to work reliably.


It's worked fine so far, but since I just found out about it I have to do
some due diligence tests to ensure some things. Basically I'm going to
launch the app in Citrix and check some global var values and some data in
local tables. Then launch second and third instances and check the
globals
from those instances. If the globals are different/reset each time a user
runs the app, they're hosed. I reviewed the local table data and I'm
confident it won't be a problem.

5 years ago they deployed one of my apps on Citrix and installed a copy
for
each user. I assumed they always did it that way. But with this latest
one, they're just now (6 mths later) telling me they're doing it
differently.

It's stupid of your admins to put such a restriction on you since
there is absolutely no justification for it at all. The additional
disk space and memory required are trivial by themselves, but even
moreso in comparison to the cost of recovering from the problems
that sharing a front end will cause.


I'd rather they run separate copies, and probably can convince them. But
it
truly may not be an issue - it depends on the Citrix settings. The admin
tells me Citrix/2000 allows each user to run in their own protected memory
space and virtual channel.

Nov 13 '05 #14
On Thu, 27 Oct 2005 17:48:32 -0500, "David W. Fenton" <dX********@bway.net.invalid> wrote:
"DFS" <nospam@dfs_.com> wrote in
news:3s*******************@fe05.lga:
paii, Ron wrote:
From postings in this group and my experience with a number of
consultants, most Terminal sever / Citrix admins have no clue on
how to run Access. They to treat the MDE like an EXE. You will
need to convince them that each user must get a private copy of
the MDE front end and share the Access program or runtime.


That's what I thought would be the case as well. But I'm hearing
differently from others here in cdma. I'm hearing it won't matter
that all users run the same .mde.


Who exactlyi in this newsgroup has ever recommended sharing a front
end?


Nobody has "recommended" sharing a front end, but some have said that they do/are forced to run a single front end
without problem.

I have an app in use running on Citrix and being used by up to 16 users (A2002). This company (an international mining
company) flatly refuses to run separate copies of the FE for each user despite my continual lobbying and citation of
various articles and reports recommending against the practice. They run a single FE mde only and have been doing so
since April 2000.

The bottom line is that in the 5 1/2 years they have been running with this setup, they have never had single case of
the front end being corrupted and have had 1 case of the backend being corrupted, which was immediately fixed with
compact / repair.

I have since given up the battle for a "proper" installation as it appears Citrix handles the single FE scenario
admirably.

The one modification that was required to the app design was the use of temporary tables. I use temp tables frequently
for report data etc and using a single temp database in this setup resulted in users overwriting each other's data in
these tables. I resolved this by creating separate temp database for each user naming them based on the CurrentUser. The
app creates the temp database and links the tables at startup and deletes the links when the app closes. So each user is
linked to their own specific temp db. Since making this change there have been no further problems.

I definately would not however, recommend using a single FE on a normal LAN.

Nov 13 '05 #15
"DFS" <nospam@dfs_.com> wrote in
news:S4*******************@fe03.lga:
It's worked fine so far


This is what the astronauts on the Challenger were thinking just
before "Throttle up."

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #16
Wayne Gillespie <be*****@NOhotmailSPAM.com.au> wrote in
news:8n********************************@4ax.com:
I have since given up the battle for a "proper" installation as it
appears Citrix handles the single FE scenario admirably.


It can't be anything about Citrix that's making it possible. It's
just luck, in my opinion.

And I would never trust to luck.

Clients that don't follow my advice on critical issues like that
this would have to sign documents holding my nonliable for anything
that goes wrong. I'd bill a double rate for fixing any poblems that
happened because of going against my explicit recommendations.

If they don't like it, they can hire someone who is incompetent
instead.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #17
Hi Wayne,

Wayne Gillespie wrote:
I have since given up the battle for a "proper" installation as it appears Citrix handles the single FE scenario
admirably.
I guess it also means no user is into Design View - the developer has
his own FE, does dev on it and then deploys it to Citrix

The one modification that was required to the app design was the use of temporary tables. I use temp tables frequently
for report data etc and using a single temp database in this setup resulted in users overwriting each other's data in
these tables. I resolved this by creating separate temp database for each user naming them based on the CurrentUser. The
app creates the temp database and links the tables at startup and deletes the links when the app closes. So each user is
linked to their own specific temp db. Since making this change there have been no further problems.


I'm interested in your approach. Another workaround that I am toying
with is to create an extra column and populating it with CurrentUser.
That means I avoid linking etc.. but it also means that my code has to
be changed to reflect inserts and deletes as opposed to purging the
table on start of process.

What happens in your case when the user disconnects without warning - do
you have code to detect incompleted logout procedures rather than
blindly trying to create and attach subsidiary tables?

In your case are you working with a separate user space (uh, "home"
folder) for each user? Or do all users share the same home?

Does each user login to Citrix as themselves or are they using a generic
role login?

Thanks for your insights.

Ananda
Nov 13 '05 #18
David W. Fenton wrote:
Wayne Gillespie <be*****@NOhotmailSPAM.com.au> wrote in
news:8n********************************@4ax.com:
I have since given up the battle for a "proper" installation as it
appears Citrix handles the single FE scenario admirably.


It can't be anything about Citrix that's making it possible. It's
just luck, in my opinion.

And I would never trust to luck.

Clients that don't follow my advice on critical issues like that
this would have to sign documents holding my nonliable for anything
that goes wrong. I'd bill a double rate for fixing any poblems that
happened because of going against my explicit recommendations.

If they don't like it, they can hire someone who is incompetent
instead.


While I don't believe it's entirely at fault it is possible that the network
environment greatly increases the corruption risk when sharing a front end. In
a Citrix environment everything can be on local disk (doesn't have to be, but
can be if the developer sets it up that way). The increased speed and
reliablitity of local disk i/o compared to TCP/IP over a LAN might very well
reduce the risk to acceptable levels.

So what! I still need to issue updates. If I use a shared front end I am back
in the silly game of trying to get everyone off at the same time so I can
replace the file. If everyone has their own copy I can use the exact same
update strategy as I use for non-Citrix apps.

In addition I often use local temp objects or modify SQL on the fly in queries
and this is totally safe in an environment where everyone has their own file and
is a big PITA if using a shared front end.

Since I use server back ends exclusively the only corruption I risk is of the
front end file which I can replace in a few seconds. Corruption risk is near
the bottom of the list of reasons to not share a single file (IMO).

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
Nov 13 '05 #19
On Fri, 28 Oct 2005 11:58:30 +1000, Ananda Sim <An*******@gmail.com.invalid> wrote:
Hi Wayne,

Wayne Gillespie wrote:
I have since given up the battle for a "proper" installation as it appears Citrix handles the single FE scenario
admirably.
I guess it also means no user is into Design View - the developer has
his own FE, does dev on it and then deploys it to Citrix

The one modification that was required to the app design was the use of temporary tables. I use temp tables frequently
for report data etc and using a single temp database in this setup resulted in users overwriting each other's data in
these tables. I resolved this by creating separate temp database for each user naming them based on the CurrentUser. The
app creates the temp database and links the tables at startup and deletes the links when the app closes. So each user is
linked to their own specific temp db. Since making this change there have been no further problems.


I'm interested in your approach. Another workaround that I am toying
with is to create an extra column and populating it with CurrentUser.
That means I avoid linking etc.. but it also means that my code has to
be changed to reflect inserts and deletes as opposed to purging the
table on start of process.

What happens in your case when the user disconnects without warning - do
you have code to detect incompleted logout procedures rather than
blindly trying to create and attach subsidiary tables?


The startup routines searches for and deletes any "leftover" links to the temporary database. It then creates a new
temporary database and names it according to the user. It then relinks the tables from the temp db.
This overcomes the problem of incomplete logouts as any latent links to the temp tables are cleaned on startup.

In your case are you working with a separate user space (uh, "home"
folder) for each user? Or do all users share the same home?
The single FE is stored in a shared folder. The temp db's are created in the same folder.

Does each user login to Citrix as themselves or are they using a generic
role login?
I'm not sure how their Citrix login is configured, but each user logs into my app with an individual username. I am not
gathering the user name from citrix, the two logins are separate issues.

Thanks for your insights.

Ananda


Nov 13 '05 #20
DFS
Wayne Gillespie wrote:
On Thu, 27 Oct 2005 17:48:32 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:
"DFS" <nospam@dfs_.com> wrote in
news:3s*******************@fe05.lga:
paii, Ron wrote:
From postings in this group and my experience with a number of
consultants, most Terminal sever / Citrix admins have no clue on
how to run Access. They to treat the MDE like an EXE. You will
need to convince them that each user must get a private copy of
the MDE front end and share the Access program or runtime.

That's what I thought would be the case as well. But I'm hearing
differently from others here in cdma. I'm hearing it won't matter
that all users run the same .mde.
Who exactlyi in this newsgroup has ever recommended sharing a front
end?


Nobody has "recommended" sharing a front end, but some have said that
they do/are forced to run a single front end without problem.

I have an app in use running on Citrix and being used by up to 16
users (A2002). This company (an international mining company) flatly
refuses to run separate copies of the FE for each user despite my
continual lobbying and citation of various articles and reports
recommending against the practice. They run a single FE mde only and
have been doing so since April 2000.

The bottom line is that in the 5 1/2 years they have been running
with this setup, they have never had single case of the front end
being corrupted and have had 1 case of the backend being corrupted,
which was immediately fixed with compact / repair.

I have since given up the battle for a "proper" installation as it
appears Citrix handles the single FE scenario admirably.


That's good to hear. I'll be doing some testing soon, 'cause I have to
prove it to myself of course.
The one modification that was required to the app design was the use
of temporary tables. I use temp tables frequently for report data etc
and using a single temp database in this setup resulted in users
overwriting each other's data in these tables. I resolved this by
creating separate temp database for each user naming them based on
the CurrentUser. The app creates the temp database and links the
tables at startup and deletes the links when the app closes. So each
user is linked to their own specific temp db. Since making this
change there have been no further problems.

I definately would not however, recommend using a single FE on a
normal LAN.

Nov 13 '05 #21
On Thu, 27 Oct 2005 14:55:25 -0400, "DFS" <nospam@dfs_.com> wrote:

....
There are several reasons for not using a shared file,
but use of VBA global variables is not one of them.

It's not my decision on using the single .mde.


I'd make 2 MDEs in the shared location. The first one is a loader
that checks whether the user's unique copy is up-to-date (stored
under the user's documents and settings somewhere), makes a new
unique copy if it needs to be updated, then opens the other MDE using
Shell "...msaccess.exe ""<unique-mde-copy-path"" ".


Not quite understanding you. The 'shared location' is on the Citrix Server.
All users run the same .mde. That .mde will always be up to date. The
users run the Access system from inside a web browser.


No - IT wants to manage the deployment of one MDE - you know everyone should
run a separate copy. Therefore, you should let them deploy one file like they
want to do, and you should have a process for updating each user's separate
copy from the central copy when it has been updated. IT won't know or care -
they still keep track of one file in one place.
Nov 13 '05 #22
DFS
David W. Fenton wrote:
"DFS" <nospam@dfs_.com> wrote in
news:xo*******************@fe05.lga:
The bottom line: Citrix deployment can impact your Access system
design.
No, it can't.


Yes it can.

I built this system with the agreement by the client of one FE per user (LAN
deployment), and made use of local tables for various reporting functions.
I also use a few global variables. But both design decisions can be/could
have been fatal depending on how the system is deployed on Citrix, and on
user memory space settings available on Citrix.

If I had known about the single Citrix front-end 6 months ago I would have
rewritten the code to eliminate the potential for one user overwriting
another's data. That it hasn't happened is a fortunate event I attribute to
Citrix' proper architecture (in the case of the global variables), and luck
(my local table design is such that it doesn't matter if multiple users are
overwriting them).

Terminal Server deployment should be exactly the same as deployment
on workstations -- one front end per user. Period.

Anyehing else is WRONG.


Says you. So far it hasn't caused any problems for me, and at least one
other guy here reports 5+ years of no problems with a shared FE on Citrix.

But in general I don't at all like the single-front end, and I'll strongly
recommend one FE per user.


Nov 13 '05 #23
On Thu, 27 Oct 2005 23:01:14 -0400, "DFS" <nospam@dfs_.com> wrote:
David W. Fenton wrote:
"DFS" <nospam@dfs_.com> wrote in
news:xo*******************@fe05.lga:
The bottom line: Citrix deployment can impact your Access system
design.
No, it can't.


Yes it can.

I built this system with the agreement by the client of one FE per user (LAN
deployment), and made use of local tables for various reporting functions.
I also use a few global variables. But both design decisions can be/could
have been fatal depending on how the system is deployed on Citrix, and on
user memory space settings available on Citrix.


As was said before - you should tell IT that sharing one Access front-end file
between multiple users is not supported, and you can't guarantee it will work.
Therefore, deploying for dhared use does not impact your system design. You
don't have to design for it because you cannot and should not support it.

Again, global variables cannot be a problem, no matter how the application is
deployed on Citrix because multiple users cannot and do not share the same
volatile data memory. The problems lie elsewhere.

....
Says you. So far it hasn't caused any problems for me, and at least one
other guy here reports 5+ years of no problems with a shared FE on Citrix.
I - on the other hand have seen serious problems with shared front-ends on
Citrix. YMMV, I suppose, but I'll never suppot doing that with one of my
apps.
But in general I don't at all like the single-front end, and I'll strongly
recommend one FE per user.


Or sneak it in the back door by automatically making a unique copy on
start-up. IT should not know or care since this is really just your
application copying a working file to the user's local storage area.
Nov 13 '05 #24
DFS
Steve Jorgensen wrote:
On Thu, 27 Oct 2005 14:55:25 -0400, "DFS" <nospam@dfs_.com> wrote:

...
> There are several reasons for not using a shared file,
> but use of VBA global variables is not one of them.

It's not my decision on using the single .mde.

I'd make 2 MDEs in the shared location. The first one is a loader
that checks whether the user's unique copy is up-to-date (stored
under the user's documents and settings somewhere), makes a new
unique copy if it needs to be updated, then opens the other MDE
using Shell "...msaccess.exe ""<unique-mde-copy-path"" ".


Not quite understanding you. The 'shared location' is on the Citrix
Server. All users run the same .mde. That .mde will always be up to
date. The users run the Access system from inside a web browser.


No - IT wants to manage the deployment of one MDE - you know everyone
should run a separate copy. Therefore, you should let them deploy
one file like they want to do, and you should have a process for
updating each user's separate copy from the central copy when it has
been updated. IT won't know or care - they still keep track of one
file in one place.


I think I gotcha now. Let the Citrix admin put the one file in place, but
have it automatically propagated to the user's personal folder when they
login, or at some other time.

That sounds interesting, but right now I don't know how he sets it up so the
users login and use the one copy, or their own copy. I'll talk to the
Citrix admin tomorrow and tell him I* came up with an idea that will make
his life easier, plus reduce potential problems.

Thanks for the suggestion.

* just kidding. I'll call it the Jorgensen Solution.

Nov 13 '05 #25
DFS
Steve Jorgensen wrote:
On Thu, 27 Oct 2005 23:01:14 -0400, "DFS" <nospam@dfs_.com> wrote:
David W. Fenton wrote:
"DFS" <nospam@dfs_.com> wrote in
news:xo*******************@fe05.lga:

The bottom line: Citrix deployment can impact your Access system
design.

No, it can't.
Yes it can.

I built this system with the agreement by the client of one FE per
user (LAN deployment), and made use of local tables for various
reporting functions. I also use a few global variables. But both
design decisions can be/could have been fatal depending on how the
system is deployed on Citrix, and on user memory space settings
available on Citrix.


As was said before - you should tell IT that sharing one Access
front-end file between multiple users is not supported, and you can't
guarantee it will work. Therefore, deploying for dhared use does not
impact your system design. You don't have to design for it because
you cannot and should not support it.


That's one way to look at it. I'm pretty sure I could force the issue. I'm
friendly with the Citrix admin, and in fact he's already said they will do
that if they have to.

Again, global variables cannot be a problem, no matter how the
application is deployed on Citrix because multiple users cannot and
do not share the same volatile data memory.
Do you mean with multiple users running a single FE? Is that your
experience or your opinion? (you know I'm going to have to prove that to
myself before I can rest)

If they cannot be a problem, why do you agitate so strongly against the
single FE on Citrix?
The problems lie elsewhere.


So far there have been no problems.
Says you. So far it hasn't caused any problems for me, and at least
one other guy here reports 5+ years of no problems with a shared FE
on Citrix.


I - on the other hand have seen serious problems with shared
front-ends on Citrix. YMMV, I suppose, but I'll never suppot doing
that with one of my apps.


What problems did you see? How long ago? What versions of Citrix and
Access?
But in general I don't at all like the single-front end, and I'll
strongly recommend one FE per user.


Or sneak it in the back door by automatically making a unique copy on
start-up. IT should not know or care since this is really just your
application copying a working file to the user's local storage area.


Well, I won't sneak it in, but maybe I can do it automagically like you were
talking about in the other post.

Nov 13 '05 #26
Thanks for that Wayne,

I could have a situation where everyone logs into Citrix using the same
role account. So I'll have to assess whether there are any calls to
return their workstation account name as opposed to their Citrix login.
Or is there a WINAPI to their Citrix connection. Some way to discern the
individual user.

Ananda

Wayne Gillespie wrote:
On Fri, 28 Oct 2005 11:58:30 +1000, Ananda Sim <An*******@gmail.com.invalid> wrote:
I'm not sure how their Citrix login is configured, but each user logs into my app with an individual username. I am not
gathering the user name from citrix, the two logins are separate issues.

Nov 13 '05 #27
On Fri, 28 Oct 2005 00:08:19 -0400, "DFS" <nospam@dfs_.com> wrote:

....
Again, global variables cannot be a problem, no matter how the
application is deployed on Citrix because multiple users cannot and
do not share the same volatile data memory.


Do you mean with multiple users running a single FE? Is that your
experience or your opinion? (you know I'm going to have to prove that to
myself before I can rest)

If they cannot be a problem, why do you agitate so strongly against the
single FE on Citrix?


Think of it this way. If you open Access twice on the same machine, does
changing variables in one instance change variables in the other? No. Each
instance is a separate process with its own volatile memory area, even though
the executable code was only loaded into memory once. Citrix does not change
that, it's just that now, some of the processes, in addition to being simply
separate from one another are actually owned by different user sessions.

The operating system will never force a process that expects to run with its
own memory to share memory with another process, because both processes would
probably crash badly and quickly. Citrix would not be a usable product if it
caused that behavior.
The problems lie elsewhere.


So far there have been no problems.


I have had problems. An MDE is still a database, and Access does place locks
on sections of it, even if is has no standard tables. It is possible for
these writes to fail, and leave the MDE in a state where it can't be reopened
until it is repaired. Furthermore, there are object setting changes that can
be saved, such as column layouts, filters, printer selections, etc. One
user's changes can mess up another user or lock the object, so another user
can't open it.
Says you. So far it hasn't caused any problems for me, and at least
one other guy here reports 5+ years of no problems with a shared FE
on Citrix.


I - on the other hand have seen serious problems with shared
front-ends on Citrix. YMMV, I suppose, but I'll never suppot doing
that with one of my apps.


What problems did you see? How long ago? What versions of Citrix and
Access?


Both Access 2002 and 2003. I don't know what version of Citrix.
But in general I don't at all like the single-front end, and I'll
strongly recommend one FE per user.


Or sneak it in the back door by automatically making a unique copy on
start-up. IT should not know or care since this is really just your
application copying a working file to the user's local storage area.


Well, I won't sneak it in, but maybe I can do it automagically like you were
talking about in the other post.


Well, I don't mean lie, I just mean have it be transparent, simple, and no
skin off IT's nose.
Nov 13 '05 #28
On Fri, 28 Oct 2005 00:01:06 -0400, "DFS" <nospam@dfs_.com> wrote:

....
I think I gotcha now. Let the Citrix admin put the one file in place, but
have it automatically propagated to the user's personal folder when they
login, or at some other time.

That sounds interesting, but right now I don't know how he sets it up so the
users login and use the one copy, or their own copy. I'll talk to the
Citrix admin tomorrow and tell him I* came up with an idea that will make
his life easier, plus reduce potential problems.

Thanks for the suggestion.

* just kidding. I'll call it the Jorgensen Solution.


No personal credit required - I didn't even come up with the technique myself.
It was shown to me by a fellow names Steve Titus.

You don't copy the file on logon, that's an additional process that has to be
implemented and maintained by IT, and it can break invisibly - that's bad.

What you do is have the little MDE that initially launches (that one actually
is shared, but doesn't stay open very long) and the one that runs the
applciation. The first MDE looks for the personal copy of the main
application MDE, checks the version, and copies the newest version on top of
it if it's not up to date. Next, it launches the personal copy of the
application MDE in another instance of Access, then that first MDE exits.
This all takes less than 1/2 a second to run. This also works without having
to log out. To update everyone, just have everyone exit and restart the
application.

To check the version, you can use a table in the MDE, but I just like to use
an extra file that gets copied to the same directory as the database called
something like "2005-10-02v2.ver". You can look for "*.ver" in the database
directory, and if you don't find one, or it is the wrong version, copy the
update.
Nov 13 '05 #29
"Rick Brandt" <ri*********@hotmail.com> wrote in
news:MO*****************@newssvr25.news.prodigy.ne t:
While I don't believe it's entirely at fault it is possible that
the network environment greatly increases the corruption risk when
sharing a front end. In a Citrix environment everything can be on
local disk (doesn't have to be, but can be if the developer sets
it up that way). The increased speed and reliablitity of local
disk i/o compared to TCP/IP over a LAN might very well reduce the
risk to acceptable levels.


I think the main risk for corruption in sharing an MDB is from the
monolithic save model, where everyone is editing the same record in
the same MDB. Remember, A97 ran pretty well in shared mode, because
each object had its own record in MSysObjects.

A2K is substantially less able to be shared because you have the bad
concurrency problems that come with everyone loading the same
record.

Chances are good that an MDE decreases that risk, since there's no
longer any chance of a decompiled project that has to be recompiled
at runtime, but, nonetheless, there are still properties that get
saved, such as filters and sorts, and unless you're explicilty
making sure that you are discarding those changes when you close the
form, that can still lead to contention and potential corruption.

That has *nothing* to do with whether or not the MDB/MDE is open
over the network, and everything to do with the way A2K+ works at
the lowest possible level.

Would a db admin roll out a server application designed such that
all users are attempting to edit the exact same record at all times?
No == that's bloody stupid -- you'd never design it that way.
Instead, you'd give each user her own copy of the record to work
with.

And that's precisely what giving each user a copy of the front end
is about, nothing more, nothing less

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #30
Ananda Sim <An*******@gmail.com.invalid> wrote in
news:43***********************@news.optusnet.com.a u:
I could have a situation where everyone logs into Citrix using the
same role account. So I'll have to assess whether there are any
calls to return their workstation account name as opposed to their
Citrix login. Or is there a WINAPI to their Citrix connection.
Some way to discern the
individual user.


I'm confused why everyone is talking about "Citrix." There is no
such thing.

There is Windows Terminal Server, and there is Windows Terminal
Server with Citrix extensions. This has always been the case, even
back in the days of NT 4, where the Terminal Server edition was a
separate versino of Windows NT Server.

If you're running a Citrix server, you're just dealing with a
Windows server, so all Windows APIs should work. So far as I know,
Citrix is not involved in user authentication at all, but I've never
actually worked with a TS with any Citrix extensions (I don't see
them as being worth the cost).

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #31
"DFS" <nospam@dfs_.com> wrote in news:Xv*****************@fe06.lga:
David W. Fenton wrote:
"DFS" <nospam@dfs_.com> wrote in
news:xo*******************@fe05.lga:
The bottom line: Citrix deployment can impact your Access system
design.
No, it can't.


Yes it can.

I built this system with the agreement by the client of one FE per
user (LAN deployment), and made use of local tables for various
reporting functions. I also use a few global variables. But both
design decisions can be/could have been fatal depending on how the
system is deployed on Citrix, and on user memory space settings
available on Citrix.


Citrix/Terminal Server has ZILCH to do with that problem. It is not
by any means a Citrix issue, but an issue caused by the ignorance of
the Terminal Server administrator.
If I had known about the single Citrix front-end 6 months ago I
would have rewritten the code to eliminate the potential for one
user overwriting another's data. . . .
This problem could happen in the complete absence of a Terminal
Server, so the problem has NOTHING to do with Citrix/TS.
. . . That it hasn't happened is a
fortunate event I attribute to Citrix' proper architecture (in the
case of the global variables), and luck (my local table design is
such that it doesn't matter if multiple users are overwriting
them).
It has nothing to do with Citrix.

It is all luck.
Terminal Server deployment should be exactly the same as
deployment on workstations -- one front end per user. Period.

Anyehing else is WRONG.


Says you. So far it hasn't caused any problems for me, , , ,


Which is the result of good luck only.
. . . and at
least one other guy here reports 5+ years of no problems with a
shared FE on Citrix.
Five years of good luck is still just good luck.
But in general I don't at all like the single-front end, and I'll
strongly recommend one FE per user.


Try out my explanation of how the Access project is stored in a
single record and explain to them that all users are opening (and
editing) a single record simultaneously and ask them if they would
ever create a db application where users did not have their own
individual copies of such a record.

They don't understand Access and that's why they insist on a single
shared copy.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #32
Steve Jorgensen <no****@nospam.nospam> wrote in
news:oe********************************@4ax.com:
I have had problems. An MDE is still a database, and Access does
place locks on sections of it, even if is has no standard tables.
It is possible for these writes to fail, and leave the MDE in a
state where it can't be reopened until it is repaired.
Furthermore, there are object setting changes that can be saved,
such as column layouts, filters, printer selections, etc. One
user's changes can mess up another user or lock the object, so
another user can't open it.


From A2K on, the Access project is stored in a single record of a
Jet table. When multiple users open an MDB/MDE, all the users are
EDITING A SINGLE RECORD.

Put that way, it looks like a pretty dangerous and stupid thing to
do, doesn't it?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #33
> actually worked with a TS with any Citrix extensions (I don't see
them as being worth the cost).
As I understand it, the Citrix extensions are
(a) good for application deployment and control, and
(b) now include an HTML version, that can go through
the HTML port on your firewall.

Both of which are important to Network types, not
database developers.

6 Years ago I also heard a suggestion that the Citrix
Extensions included (better) compression. Does anyone
have any knowledge of that?
There is Windows Terminal Server, and there is Windows
Terminal Server with Citrix extensions. This has always
been the case, even
???
I thought there was Citrix, and Citrix bought by MS for
use as TS. But that's a matter of semantics.

(david)
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@216.196. 97.142... Ananda Sim <An*******@gmail.com.invalid> wrote in
news:43***********************@news.optusnet.com.a u:
I could have a situation where everyone logs into Citrix using the
same role account. So I'll have to assess whether there are any
calls to return their workstation account name as opposed to their
Citrix login. Or is there a WINAPI to their Citrix connection.
Some way to discern the
individual user.


I'm confused why everyone is talking about "Citrix." There is no
such thing.

There is Windows Terminal Server, and there is Windows Terminal
Server with Citrix extensions. This has always been the case, even
back in the days of NT 4, where the Terminal Server edition was a
separate versino of Windows NT Server.

If you're running a Citrix server, you're just dealing with a
Windows server, so all Windows APIs should work. So far as I know,
Citrix is not involved in user authentication at all, but I've never
actually worked with a TS with any Citrix extensions (I don't see
them as being worth the cost).

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

Nov 13 '05 #34

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
by: Kepes Krisztian | last post by:
Hi ! How to access my module global vars ? Some applications I want to declare global vars (constants). But in the module I cannot access them: DEF_X=120
0
by: Christopher J. Bottaro | last post by:
>From the python programming FAQ, I learned you can do this: Globals.py: gv = 1 A.py: import Globals class A: def __init__(self): print Globals.gv
6
by: flamesrock | last post by:
ok, so to my knowledge, object oriented means splitting something into the simplest number of parts and going from there. But the question is- when is it enough? For example I have the following...
10
by: Kleenex | last post by:
Reason: I am working on an embedded project which has very limited memory (under 512 bytes, 60 or so of which is stack space), which translates into limited stack space. In order to save on stack...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.