UtterAccess HomeUtterAccess Wiki

Welcome Guest ( Log In | Register )

Custom Search
Edit Discussion
> Thin Client Considerations    
Thin Client Considerations

This page is a stub. Please help us by expanding or merging it with applicable content

In some scenarios where we want to use Access as a part of distributed solution and requiring WAN connectivity, using thin client technology can provide the answer. There are several different technologies but most familiar may be Citrix or Remote Desktop Services (commonly referred to as Microsoft Terminal Server). Using those technologies to expose an Access client can be a good solution for enabling remote users to use applications without the data actually leaving the network. This is intended to cover some possible consideration that should be incorporated in the development of such Access client.


When we are using Access as a client via a thin client, it basically means that all we are sending over the network is the drawing of the screen & mouse/keyboard inputs. The server will process the screen output & keyboard/mouse input to a local instance of Access. Because Access is actually running on the server side, it is thus local to the company's network and thus can access other resources. Frequently the Access client will be split which implies that the backend must be also in the same local network where the server is running.

File locations

In all cases, we want to ensure that both front-end client file and backend data file (or the database server, if we're using ODBC linked tables instead) are always local to the server. By "local", we refer to not only physical proximity but also being in the same network & subnet. A common mistake is to store a front-end file on a file server which may be local to the user but is actually distant to the server. This may force the server to open the file across WAN, significantly degrading the performance and increasing risk of corruption.

Likewise, in a large setup, the actual session may be running on a different server from the server where the profile was deployed. If this different server is distant from the original server, it may be also distant from the front-end files & backend and thus presents a risk. It may be necessary to verify with the administrators to ensure that in all cases, a given session won't be ever remote in relative to the source files.

Session & Persistence

Another consideration is that depending on the configuration of the server, whenever an user starts a new session, the server will copy a new profile from a stored configuration, including any Access files. This means if the users edits and makes some changes, the changes will be lost when the session ends because the server does not save it back. Therefore, if the Access application uses temporary tables or similar constructs that are expected to persist beyond a single session, steps need to be taken to ensure it will be saved correctly or use alternatives such as saving the temporary data in a backend file.

Edit Discussion
Custom Search

Thank you for your support!
This page has been accessed 3,481 times.  This page was last modified 02:03, 9 February 2012 by Jack Leach. Contributions by BananaRepublic  Disclaimers