Several of my customers now change to Citrix or VMware terminal server solutions.
To obey my customers request I rebuild my application to handle this.
Private and temporary tables was extracted from the application and located on each users logon domain as a private MDB. So fare no problem at all. The application runs smooth and nicely …… as long as he/she is the only user…
Now my problems occur:
When next user has been connected to the private MDB the connection to common MDB gets really slow. 8 to 10 times slower than for the first user.
As soon as the LDB file has been created the database really act as locked.
I guess (after searching the net) that I'm not the first one to run into this problem. In order to take correct actions to overcome this problem I ask you all for comments and ideas what to do.
Are there any solution to this using MS Access as database in a terminal server environment ?
Will it help to change to another database platform (Oracle… ?)
1 - My application function without any problems as mentioned above in a client - server solution.
2 - I tested to just open the common MDB file and start my application from another user. The same problem occurred now. Slow as ….
I've always man aged to duck deploying Access applications on Citrix and the like...but Im surprised its having problems with two users.
First off Id suggest that you have your front end deployed locally on each client workstation, (that way round the application is only calling for data across the network; you can also create as many local tables as you wish without seriously impacting the server or the network).. yes you will still cane the network sucking data but thats always going to be a risk
next I'd want to be certain I was using unbound controls.. a lot more work for you the developer, you loose a lot of the Access wizards, but you get to control what data is pumped around where. you have to manage the recordset, record locking updating etc
changing to a server back end will not make a huge difference unless you design the app for that server back end.. which in my books means using unbound controls and the like, and being very very careful where you run the SQL..... if you run it on the server, and make sure that you only retrieve what you need then fine, but try to avoid running it on the client machine (that way round its pulling all the indexes across the network, to trawl through and find the data you need.
Yes a server back end will make a difference, but unless you design for that then there is danger that you will get the worst of both worlds.
I run Access actually on the Terminal Server with the Back End on a file Server. Each user has there own version of the FE on the Terminal Server MDE database. We also have a mix of remote users and local users, there is essentially no difference both sets of users. We don't really get database performance issues except when handling a rather large library of images.