Corruption of shared files on Citrix

#11

Tony,

Thanks for this very good information. Logging users is not a bad
idea and perhaps we should do it. It would help us understand usage
patterns as well as catch poor practice--like seeing who is leaving
the application open overnight, for example.

I would like to compact the back end every day but it's almost
impossible because the application is in use around the clock during
the week. Also, we foresee the number of users doubling within the
next year so we thought it might be a good idea to look at moving to
SQL Server. However, I began to worry that even if we did that, we
might start to have problems with the shared front end as the load
increased.

Bill

#12

"Bill E." <billmiami2 (AT) netscape (DOT) net> wrote:

Quote:

like seeing who is leaving
the application open overnight, for example.

HOW TO: Detect User Idle Time or Inactivity in Access 2000 (Q210297)
http://support.microsoft.com/?kbid=210297
ACC: How to Detect User Idle Time or Inactivity (Q128814)
http://support.microsoft.com/?kbid=128814

However we found that the code which runs on the timer event must be disabled for the
programmers. Otherwise weird things start happening when you're editing code.

Also print preview would sometimes not allow the users to run a menu item to export
the report to Excel or others. So you had to right click on the Previewed report to
get some type of internal focus back on the report so they could then export it.
This was also helped by extending the timer to five minutes.

The downside to extending the timer to five minutes was if a person stays in the same
form and at the same control for considerable parts of the day, ie someone doing the
same inquiries, the routine didn't realize that they had actually done something.
I'll be putting in some logic sometime to reset this timer whenever they do something
in the program.

Quote:

I would like to compact the back end every day but it's almost
impossible because the application is in use around the clock during
the week.

What about backup?

Quote:

Also, we foresee the number of users doubling within the
next year so we thought it might be a good idea to look at moving to
SQL Server. However, I began to worry that even if we did that, we
might start to have problems with the shared front end as the load
increased.

Well, you should still be giving users their own copy of the FE.

I specifically created the Auto FE Updater utility so that I could make changes to
the FE MDE as often as I wanted and be quite confident that the next time someone
went to run the app that it would pull in the latest version. For more info on the
errors or the Auto FE Updater utility see the free Auto FE Updater utility at
http://www.granite.ab.ca/access/autofe.htm at my website to keep the FE on each PC up
to date.

In a Terminal Server or Citrix environment the Auto FE Updater now supports creating
a directory named after the user on a server. Given a choice put the FE on the
Citrix server to reduce network traffic and to avoid having to load objects over the
network which can be somewhat sluggish.
--
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/
Granite Fleet Manager http://www.granitefleet.com/

#13

"Bill E." <billmiami2 (AT) netscape (DOT) net> wrote in
news:e57635d7-72ec-4b4b-85da-1c17ff32ee3d (AT) k6g2000yqn (DOT) googlegroups.com
:

Quote:

Logging users is not a bad
idea and perhaps we should do it. It would help us understand
usage patterns as well as catch poor practice--like seeing who is
leaving the application open overnight, for example.

I don't recall if Tony said this, but you should log more than just
the user. I log these:

Windows logon
Workstation name
Jet version
Access version

All those in addition to time and so forth.

The Jet and Access versions have been instrumental in identifying
workstations that have reverted to "bad" versions of Access (e.g.,
because somebody re-installed and didn't apply the patches).

As to users leaving the app open overnight, I prohibit it for any
app where there's a nightly backup of the data file. I use a timer
on the app's main form, set it to fire at the time I want to close
things down. When that time is reached, it pops up a message. If
someone is actually working, they can respond to the choices and get
a few minutes to work before they have to shut down. If they aren't
there, I cycle through the open forms, and for every form that is
dirty, save the data and close the form. Then I close the app.

So, nobody in these situations is able hold up a backup.

And I log the event as a FORCED LOGOUT, which tells me who is
screwing up by not shutting down when they leave the office.

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

#14

"Bill E." <billmiami2 (AT) netscape (DOT) net> wrote in
news:e57635d7-72ec-4b4b-85da-1c17ff32ee3d (AT) k6g2000yqn (DOT) googlegroups.com
:

Quote:

Also, we foresee the number of users doubling within the
next year so we thought it might be a good idea to look at moving
to SQL Server.

If you've designed your app efficiently, i.e., to only retrieve
subsets of data and with tables properly indexed, upsizing is likely
to go very smoothly, assuming you're not using things like SEEK
(Jet-specific).

Quote:

However, I began to worry that even if we did that, we
might start to have problems with the shared front end as the load
increased.

The front end should not be shared with even TWO users, let alone
anything more than that.

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

#15

Tony - Thanks for the offer on the "auto updater", but I have my own
VB6 executable for that which I created many years ago.

David - I set up user session logging today. I'm capturing the user's
MS Access login, the user's network name and the machine name, which
in most cases will be the Citrix server.

I can't start forcibly closing applications on users. Remember, users
in this case are located all around the world--the Americas, Europe,
Australia, Japan, etc. It would be impossible to define what
"overnight" means. However, passive logging would help us spot folks
who didn't close out promptly and we could send them a warning about
it. Honestly, I don't know if users are even doing this but I suppose
we'll find out.

I appreciate your comments about "upsizing" but if I move this to SQL
Server, I will almost certainly cut out most all of the MS Jet queries
and run stored procedures via pass through or ADODB to get the best
performance. In many cases I know that I could have a single stored
procedure replace multiple Jet queries and a bunch of VB code, which
would simplify this application greatly and make it much easier to
maintain.

Bill

#16

"Bill E." <billmiami2 (AT) netscape (DOT) net> wrote in
news:ac7edeba-ee77-40c3-8d43-174776297205 (AT) i6g2000yqj (DOT) googlegroups.com
:

Quote:

I appreciate your comments about "upsizing" but if I move this to
SQL Server, I will almost certainly cut out most all of the MS Jet
queries and run stored procedures via pass through or ADODB to get
the best performance.

I would say it is unwise to do this pre-emptively. Instead, try it
as is and then move server-side what doesn't work well.

Quote:

In many cases I know that I could have a single stored
procedure replace multiple Jet queries and a bunch of VB code,
which would simplify this application greatly and make it much
easier to maintain.

The biggest app I've ever upsized turned out to benefit least in the
places I assumed it would, and, in fact, didn't need the rewrites I
expected. That is, the things I expected to be slow were not, and
the things I expected to work needed to be altered (not always
moving them server-side -- often converting to passthrough did the
trick).

So, even though you *think* you know what's going to need to be
moved to the server, you likely don't.

On the other hand, what you describe sounds like something that's a
different ball of wax, particularly if you are currently doing it in
a transaction.

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

#17

"David W. Fenton" <XXXusenet (AT) dfenton (DOT) com.invalid> wrote:

Quote:

Logging users is not a bad
idea and perhaps we should do it. It would help us understand
usage patterns as well as catch poor practice--like seeing who is
leaving the application open overnight, for example.

I don't recall if Tony said this, but you should log more than just
the user. I log these:

Windows logon
Workstation name
Jet version
Access version

All those in addition to time and so forth.

Good point. I do all those as well.

(Just for grins, one of these days I have to find and work with the API code to
determine the IP address of the connecting PC if they are on Terminal Server. No
particular need but something on my to do list.)

Quote:

As to users leaving the app open overnight, I prohibit it for any
app where there's a nightly backup of the data file. I use a timer
on the app's main form, set it to fire at the time I want to close
things down. When that time is reached, it pops up a message. If
someone is actually working, they can respond to the choices and get
a few minutes to work before they have to shut down. If they aren't
there, I cycle through the open forms, and for every form that is
dirty, save the data and close the form. Then I close the app.

I don't bother being nice. I just shut down the app.

Quote:

And I log the event as a FORCED LOGOUT, which tells me who is
screwing up by not shutting down when they leave the office.

Agreed.

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/
Granite Fleet Manager http://www.granitefleet.com/

#18

"Bill E." <billmiami2 (AT) netscape (DOT) net> wrote:

Quote:

I can't start forcibly closing applications on users. Remember, users
in this case are located all around the world--the Americas, Europe,
Australia, Japan, etc. It would be impossible to define what
"overnight" means.

There is no set time when you force the users to exit. It's a 30 or 60 minutes of
inactivity that does it.

How do you backups work then?

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/
Granite Fleet Manager http://www.granitefleet.com/

#19

"Tony Toews [MVP]" <ttoews (AT) telusplanet (DOT) net> wrote in
news:055s65908prpkbbkh9bma10on6pi60l7e5 (AT) 4ax (DOT) com:

Quote:

"Bill E." <billmiami2 (AT) netscape (DOT) net> wrote:

I can't start forcibly closing applications on users. Remember,
users in this case are located all around the world--the Americas,
Europe, Australia, Japan, etc. It would be impossible to define
what "overnight" means.

There is no set time when you force the users to exit. It's a 30
or 60 minutes of inactivity that does it.

Well, perhaps that's how you do it, but I very plainly described
kicking them out at a particular time, in order that the back end be
free of users when the backup starts.

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

#20

Tony,

I have an executable run under a scheduled task that backs up the
database to a folder and compacts/repairs once per day. It checks if
the database is in use and if so, it doesn't compact--it only writes
to a log. Because the database is in use so often, it ends up
compacting very infrequently. If I wanted to guarantee that I would
get a daily compact, I would have to clear everyone from the system at
the same time like David is doing. Just logging people off for
inactivity would not suffice.

David,

I typically use a SQL trace to see how the database is being used and
what is performing well and what isn't. A trace will show you exactly
how your Jet queries are being translated and how long they're
taking. If you don't use a SQL trace, I highly recommend that you
start. It takes the guess work out of it.

Bill