Question about running accdr/accdb files

[CostasD]

Hi,

We have an Access application consisting of two files: an .accdr and an. accdb
If I understand correctly the accdr file is the Interface to interact with the database found in the accdb file



What is the correct way of running it in a multiuser environment? Can I place the two files on a network share and run the accdr from there? Or do I have to copy and run the accdr locally, and leave the accdb on the network share?

Thank you

[CJ_London]

The .accdr should be on each users local machine and the .accdb on a shared network drive somewhere. If you were to put the .accdr on the network, then you run the risk of corruption as conflicts can occur with users doing different things at the same time - one of the reasons that other files such as excel and word cannot be shared - the first user opens it OK, all subsequent users open a copy. This does not happen with Access because the file is being updated constantly

[CostasD]

Ok! Any idea why the .accdr file is ~30MB? I mean it's only an interface to the database, is it supposed to be that large?

[CJ_London]

On a machine that has a full access version (rather than runtime) rename as .accdb. You should then be able to open in design view. There should be no local tables, only linked ones.

Before taking any further action, make sure you take a copy of the file. It is extremely unlikely that anything will go wrong (it never has for me) but it is better to be safe than sorry.

So now compact and repair (click on file). That should reduce the file size.

Before compacting, and assuming you are using VBA you can also decompile/recompile which should remove any 'rubbish' remaining from developing the VBA - or do this after compacting the tables, then compact again.

Here is a link as to how to decompile https://www.devhut.net/ms-access-decompile-a-database/

once done, rename as .accdr.

Note that the r means runtime, it is used by developers to test their app in a runtime environment. It is sometimes used as a very low level security measure to prevent users from messing with the front end - but as you can see, easy to overcome if you have a full version of access.

It is usually better to distribute the front end (what you can the interface) as a .accde so users cannot mess with forms, reports and modules. These can still be renamed as .accdr. If what you have is actually a .accde then you won't be able to decompile/recompile

[ArviLaanemets]

When users are in same LAN as the resource with your accdb, you place the copy of accdr on every user's hard drive, or on shared network resource (like CJ_London adviced).

When there is a need for users to work with app outside of your LAN, then you need a terminal server (with Access installed) in your LAN. Users have the copy of accdr in their TS profiles, or they have there shortcuts to accdr's on shared network resource. They log into your LAN remotely, log in into TS, and start accdr from there.

To avoid possible confusion, when users use the same laptop to work in office, and to work remotely, it will be best such users work with this app from TS even when they are in office.