[AccessD] One Accdr (front end) for each User's PC or Share the Accdr file on the File Server

Heenan, Lambert Lambert.Heenan at aig.com
Mon Oct 20 15:19:11 CDT 2014


" The consequences of them accessing the data on the server will be:
Delays in getting data selection done, as the server will be doing all the work that their local PC's were doing"  Not so. The server is just acting as a file server, so when the 10 or so users open the same front end, all the heavy lifting is still being done by their local machine.

Other consequences of allowing the users to share a front end - if you ever need to make an update to the front end design you will need to kick all the users out before you can deploy the revised version. When they each have their own copy of the front end you have no such constraint, but then you do have the problem of how to distribute new versions to the users.

Lambert and his two cents.

Prediction is difficult, especially of the future.
  -- Niels Bohr



-----Original Message-----
From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of James Button
Sent: Monday, October 20, 2014 4:10 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] One Accdr (front end) for each User's PC or Share the Accdr file on the File Server

Please note the following is only my opinion. 

If the front ends are never going to be allowed any update access at all by the imbedded security, or the access method including constraints - as in pre-coded SQL, then the main considerations for you at the server end will be the effect of an update being performed while one, or more of those users has the database open for access, and the effect on any scheduled (or ad-hoc) maintenance such as a backup if a user leaves their system in a state where it is accessing the database, and that access stops the DBMS being set in a can-do-maintenance state.

The consequences of them accessing the data on the server will be:
Delays in getting data selection done, as the server will be doing all the work that their local PC's were doing (adequate real memory on the server may mitigate that). 
And transmission delays as the selected data is transmitted across the Lan
(Wan/web?)

There is also the consideration that they will have assurance that the data they are viewing is up-to-date, and the results of any searches they do will change as the data does, and they will not have to schedule and actually achieve an update to their local copy.

Now all of the above is a matter for your, and the organisation's management to
consider rather than being a technical limitation of the use of Access.   

JimB 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Brad Marks
Sent: Monday, October 20, 2014 8:31 PM
To: Access Developers discussion and problem solving
Subject: [AccessD] One Accdr (front end) for each User's PC or Share the Accdr file on the File Server

All,

I recently built a small inquiry system with Access 2007. 

I am using a "Split" database (data stored in a "_be.accdb" backend file).

The data is coming from an outside source and the inquiry system will never update the data.

Currently all of the users (about 10) share the Accdr (front end) which is stored on a file server.

A couple years ago, I built a similar inquiry system and I set things up so that each user had their own copy of the Front-end Accdr file.

I am now wondering if this is really necessary. 

Would it be Okay for all users to share the Accdr (front end) which is stored on the file server?  

Please Keep in mind that no updates are ever done via the font-end.

Thanks,
Brad

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



More information about the AccessD mailing list