April 19, 2006 at 5:57 am
Can anyone provide advice regarding the best db solution for a Terminal Server network which I know little about other than an application can be run directly from the server on a client machine.
Will an Access solution run fast enough, or will a SQL Server solution be required with an appropriate front end.
Will there be any record locking issues?
Many thanks for your advice.
April 20, 2006 at 6:48 am
Hi Neil,
Well I wouldn't recommend housing your data crunching on a terminal server itself, but that is a factor based on number of users/speed required/money available.
Personally I would never recommend an Access solution for anything. However, should you go down that particular route bear in mind there are some scripts you need to run on a TS to make Office run better (just google terminal server office scripts). This isn't too difficult - add Access to their client desktop setup, run the Access app from a drive shared by all users and away you go. I seem to remember you might be pulling your hair out for a while with file permissions and the like but it isn't that complex.
To minimise complexity and maximise availablilty I would recommend a client server application - house the clients on the terminal server and the database somewhere else, preferably SQL server of course.
If you do this the only problems you're liable to get are things like if your client app requires access to system dlls (in which case you'll get permissions errors which you need to sort out). Security in general is a dog on TS.
Hope that helps
Rich
April 21, 2006 at 8:21 am
Neil,
I'm with Richard: forget Access for any kind of "serious" application. Once you get beyond a certain number of users, i.e. 1, it's not very robust. And if the term server is being used for anything else, e.g. Office, you're better off splitting the front and back ends. Put the front end on the TS and the database on another server, like it should be.
General rule of thumb is to use a server for one purpose only. If cost is a factor in database choice, consider MSDE or SQL Server Express.
Re locking: this has more to do with programming choices than anything else. The respective database engine handles it's own locking, it's more how you deal with it in your app.
We've deployed several VB apps on TS/Citrix talking to a separate SQL Server 2000 database. User load typically in the dozens to a couple hundred. It all works like it should & the very few support calls we get are usually network problems unrelated to our setup.
Vik
April 24, 2006 at 3:01 am
Dear Vik
Many thanks for your time and knowledge in replying to my query which was very helpful.
I note you mention SQL Server 2005 Express, presumably this is cut down version of SQL Server 2005. I will check this on Microsoft site.
Neil Crabtree
April 27, 2006 at 9:08 am
My company testified in a lawsuit regarding Access on a terminal server. This involved a doctor's office, who had a local tech company set up a server solution for them. Their line of business application, Soapware, was hosted on Terminal Server, and the Access database was located on the same machine. The customer experienced intermittant data loss and corruption over a period of time resulting in thousands of records being affected. She was furious, of course, and sued the company that had implemented it for her.
The question was one of incompetence. Should the implementor have known that this would happen? Should they have specified a SQL backend? We were called to testify as technical experts for both the Soapware product and for MS Access. Our research found that while Access can handle a multi-user environment when accessed from a network share, it does not do as well when located on a terminal server. This seems to be due to how Access handles record locking in a multi-session environment. Access itself has no way of knowing if different sessions are accessing different instances of itself.
The implementor lost the case.
My company's view of installing database programs on Terminal Server is:
1. If you must use Access, split the database and put the backend MDB on another server. Use linked tables.
2. If you can, upsize the database and put the backend in SQL, with linked tables (don't use Access Database Projects; they don't work well on Terminal Server).
Just keep a couple of things in mind:
1. When accessed from a share, MDB database files are terribly slow across a network connection. Users are guaranteed to be unhappy with it, even over a gigabit link. Trust me on this.
2. You need to be careful with things that may affect data integrity. SQL-based data engines are the way to go in a multiuser environment, because they are specifically designed to protect data, via transactions and record locking. Access was never intended to fulfill that. And as we saw, a tech company got sued over it and lost.
3. When people ask me how many users Access supports, I always reply: "One."
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply