Can anyone assist with settling this argument?

[Binnit]

We are currently running Access 97 via a Citrix Metaframe XP Windows 2000 server environment.

This is now causing problems due to the known incompatability of Access 97 which hogs all the CPU when used by multi-users.

We used to run this via MSTS/NT4 and all was sweet for our 50 users even if 30 were using Access concurrently.

We wish to upgrade to Office 2003 to overcome our current issues. Our parent company is resisting this and instead recommending that we switch to SQLServer and re-write all our applications!

The main thrust of their argument is that they do not consider:-

A) MSAccess to be a multi user application
B) That by upgrading to 2003 the problems will not be resolved

Can anyone offer any factual or official guidelines/articles on this subject
or
Can anyone provide their own experiences given this scenario and details of any arguments put forward from both sides?

Thanks



If IT ain’t working Binnit and Reboot

 

[Binnit]

oophs that should read
B) That by upgrading to 2003 the problems will be resolved


If IT ain’t working Binnit and Reboot

 

[Ed2020]

For what it's worth my opinion is:

A) Nonsense, of course MS Access is a multi-user application.

B) I'm not sure but I'm inclined to agree with them.

Ed Metcalfe.

Please do not feed the trolls.....

 

[Binnit]

Ed2020
Are you saying that an upgrade will or will not resolve the current problem?
(sorry I really badly misworded part b)

If IT ain’t working Binnit and Reboot

 

[Ed2020]

Binnit,

Please don't take my word for it, but no I don't believe upgrading from A97 to A2K3 will make a difference.

I don't really have any evidence for this - just gut feeling.

When you say Access is hogging all the CPU do you mean CPU on the users' desktop machines?

Ed Metcalfe.

Please do not feed the trolls.....

 

[Binnit]

Ed
No it hogs the Citrix Server CPU as per

http://support.microsoft.com/?kbid=160819

Thanks for your comments



If IT ain’t working Binnit and Reboot

 

[Ed2020]

Binnit,

I'm confused. I can't see where this article makes reference to hogging server-side CPU. MS Access is a file server database, not a client server database so CPU usage on the server should be minimal...

Ed Metcalfe.

Please do not feed the trolls.....

 

[Binnit]

We are running 40 thin client terminals using Citrix. The Access db resides on a separate XP file server.

Citrix delivers both the Access application and DB to the thin client upon request.

Hopes this clarifies, the bottleneck is Access hogs the citrix server CPU.

This is what we are being told by IBM support.

Does this make sense?


If IT ain’t working Binnit and Reboot

 

[dhookom]

SQLServer and re-write" SQL Server is not a front-end. Any re-write would require VB, VB.NET, ASP.NET, or some other programming environment that allows you to create forms, reports, ....

Duane MS Access MVP
[green]Ask a great question, get a great answer.[/green] [red]Ask a vague question, get a vague answer.[/red]
[green]Find out how to get great answers faq219-2884.[/green]

 

[fneily]

We used to run this via MSTS/NT4 and all was sweet for our 50 users even if 30 were using Access concurrently."

So, since hardware and software is relatively cheap compared to gas prices and a pound of kool-aid, reestablish it as a separate system.

"Our parent company is resisting" . Yeah, and I worked for 14 years for the largest company in the world at that time called AT&T. The people who made technical decisions were non-techs, they were management. We usually ignored them.

 

[MichaelRed]

Shouln't (per the iomplication of the thread) be running the FE over the NET. The major point of splitting the db is to avoid this. The FE should reside LOCALLY on individual desktops / workstations.



MichaelRed

 

[PHV]

The FE should reside LOCALLY on individual desktops / workstations.
Shouldn't this defeat the Citrix purpose ?

 

[Binnit]

Hey a real mixed bag of comments...

The environment is totally "Thin" for our users, nothing resides on local machines other than an underlying XP build. The desktop is completely tied down (no shortcuts are allowed etc) and all data files incl db's are located on a shared XP file server from where they pick up the db' Frontend's.

fneily: Unfortunately, the "management" are stumping up the cash and licenses so we cannot ignore them! what really irritates is the resistance to upgrade is being led by the parent co "systems architecture" dept manager.

Any more thoughts?


If IT ain’t working Binnit and Reboot

 

[MichaelRed]

I currently use Citrix (as seldom as possible), with the citrix server acting as a 'surrogate' for the local system. I am not 'in charge' of it so some details of the structure / performance are not available to me. What I do see is that most any FE run as in multiuser mode from a server rquires a great deal more network activity than ones residing locally. For 'my' system, the apparent workload on the citrix server is to handle the activity quite nicely as long as the number of users / applications doesn't cause thrashing (swapping to / from disk) of portions of the application. Once this starts to happen, the system(s) start to slow down quite noticably.

Past attempts (before I was there) apparently attempted to use a single FE app which all could access either through citrix or locally over the LAN. Performance through citrix was -according to reports from those who were there- started off approx the same, but slowed noticable with far fewer users on the citrix connection.

Other -slightly off the beaten track- thoughts:

Ms. A would support use of SQ: Server BE quite nicely, and even comes with an 'upsizing' wizzard to accomodate this. You can actually use the so-called mini SQL serverr with Ms. A. for free going this route. As previously mentioned, if you go any other route, you WILL be reengineering the app. Using SQL (or any Industrial Strength db engine) pernits the retention of the forms and reports, makes many/most of your code either directly useable or MUCH easier to update / modify and retains the look and feel aspect of the app.

This is NOT to say you will get all the benefit without the effort. Using SQL server EFFECTIVELY also means converting your queries -which the upsizing wizzard is purported to be not the best at optimizing. Also, without any knowledge of the app, I would guess that it has some SQL embedded as 'code ' -which WILL be ignored by the upsizing wizzard. The upside of upsizing, after a bit of tweaking / angst / frustration and settlling of the dust is usually an much better performance. The performance boost is almost all from the reduced network traffic. Ms. A. (Jet db engine) returns the 'cartesian' set for any / all every data request. The (LOCAL) version of the Jet engine does ALL of the actual processing to reduce the recordset to the match the request. SQL SErver, at the other end of the pipe, processes the entire data request, returning ONLY the recordset actually requested. This is NEVER any larger than the cartesian recordset, and is (with the exception of an entire table without any conditionals) usually smaller. I do not have the specifics of how much smaller, but believe it to close to an order of magnitude.

I cannot help with the corporate mentality of pinching pennies. I would offer that recent (the last several decades anyuway) the cost benefit studies have shown that the cost of equipment and software is trivial in comparision to the cost of labor. A Computer, loaded with the software necessary for general office productivity can usually be had for a few $$K, Even 'cheap' workers will run $30K. From an economice perspective, it would seem like saving even one worker would 'buy' ten whole workstations. So, to me at least, the attitude is 'penny wise - pound folish'.

All of the above won't make any material difference to an entrenched attitude, so advice and facts aside, if the word from 'on high' is to do it --- quit quibbling and get to the task at hand. Perhaps you could start with paln, budget and schedule for the conversion?

MichaelRed

 

[Binnit]

MichaelRed
I appreciate your post and agree that in an ideal world we would have the FE on each "thin" machine, but being totally "thin" this is not an option and therefore the entire application Forms/Reports & recordsets has to be dragged from the file server to the thin machine via the Citrix box.

This used to work really well with Citrix + NT on the file server but no longer does with XP.

Management comments noted...

If IT ain’t working Binnit and Reboot