Question : Sharing an Access 2007 database

We have an Access 2007 (part of Office Enterprise) database which we are three people sharing. We have split it into a front end and a back end part (the back end contains the tables). Currently our sharing is done through Grooving of the two accdb files (meaning we all have identical, updated copies of the database on each of our laptop), which works, but means we cannot work concurrently in the database. Also, each addition/change of data has shown to generate quite significant Groove traffic (and thus a buildup of the Groove binary file). The database is quite large in terms of number of records (83,000 in one table, 42,000 in another and 40,000 in a third table  the 83,000 is also likely to grow with 15,000 records per year), but in terms of size on disk it is not as bad (or at least far away from the limit which I have understood is 2 GB): front end is 13 MB and back end is 74 MB.

Calculating queries is slow (meaning opening some of the forms is also slow, as is searching in them)  as we run it on laptops (I have a Thinkpad x61s with a Intel Core 2 Dup CPU    L7300@1-40GHz processor and 4 GB of Ram).

We would like to work in the database concurrently (each with our own front end, but using the same back end file), but are uncertain of how this is best arranged. It is important for us that it remains as easy as possible to continue making changes to the database, including its structure (we are still adding new tables every now and then), so that we can continue to manage this ourselves. We feel quite comfortable using Access, have never used an SQL server, but are happy to learn if it is not too complicated.

At the moment we own a Dell PowerEdge T105 Server with SBS 2003R2 which we are currently not using, but could set up in our office (and thus connect with a cable to our laptops when we are in the office).
"      What options are there for sharing the back end database (putting on a server (the Dell?), putting it on a separate desktop PC in the office running normal (i.e. not server) software, moving it to SQL, etc...)?
"      Should we make changes to the front end as well to optimize performance?
"      Is there any way to speed up the calculations (would it e.g. help to move queries from the front end to the back end, could it help if we split the back end into two databases with half of the tables in one and half in the other,...)?

Answer : Sharing an Access 2007 database

This is a difficult problem to answer accurately without a great deal more information.

There are lots of ways to speed up almost anything, but first you would have to investigate what part is "slow"...  speeding up the things that are not the current bottleneck will just cost $ and not help much...

Using Windows Perfmon to watch the system while you are using it can point to the bottlenck as being CPU or disk or possibly something else...  

If it is disk bound, using an SSD (Solid State Disk) in each laptop instead of the hard drive, (basically a big, fast flash drive) could help a very large amount if the slow laptop disk was the bottleneck.  Partitioning the disk so that the database is on it's own partition/drive letter would keep the database files from being fragmented as much.  Running a regular disk defrag could help the laptops now (Vist does this daily by default).  Reformatting / Changing the disk database drive so that the clusters were larger also helps slower laptop hard drives.

If it is CPU bound then changing the way the calculations are done would likely be the most effective approach.  Moving things to a SQL server could make things better or worse, depending on how the application is written.  "Pre-Calculating" things on a SQL server so they are ready to be retrieved could save a lot of time, but it would be hard to say that just moving the calculation load to the SQL server would improve your response time.

Good code can run quickly just about anywhere, but code that is not written well to minimize the bottlenecks can be slow almost anywhere as well.
Random Solutions  
 
programming4us programming4us