Hosting

[HansBades]

Looking for ideas on how to securely host an access dbase so that others can use it but cannot access anything but the form and thus wouldn't have access to the tables, relationships, code, etc. We are not on a common share drive and wondering what others might have done and how you did it. THanks.

[CJ_London]

You really need to develop a 'security policy' defining what you want to protect, from whom, doing what and by what methods. Otherwise you can end up with a mishmash of solutions which may not integrate well with your app. What's might be data or types of data, code, queries. Who's may be all users, occasional users, users groups, non-users, Methods might be exporting, copying, moving/deleting files, sql injection etc. It's up to you.

if you have a 'production' db, the db must be split to back end (BE - tables) and front end (FE - everything else) - even if you only have a single user. Not just for security but for ease of ongoing maintenance. A copy of the FE would be on each users local device.

You can protect the BE with a password which will protect your tables and relationships. In a multi user environment you do need a shared location for the BE. If you don't then you will need to use something like terminal server or citrix for which you have to pay for licensing. This will also host the FE for each user. This does have benefits in that users can be anywhere and can connect from any device that supports remote desktop and you can connect wirelessly. Performance should be very good, similar to having FE and BE on your local device.

Another very old alternative is to have replicated copies of the BE on each users machine and a means to synchronise them. It was used before network performance was acceptable and not so widely available. It is also only appropriate for certain applications - basically where users are viewing data and adding new data, but not changing existing data plus data does not need to be current as this is dictated by the frequency of synchronisation - imagine sales people out on the road only adding new customers and orders and synchronising when back in the office.

You protect the FE forms, reports and modules by compiling the FE to a .accde. If you are using terminal server or citrix, you can install access runtime which further prevents users from messing with your files.

With regards hiding the access window, that is easily achieved, but your forms will all need to be popups. Or you could rename your file with a .accdr suffix which simulates runtime and provides a limited menu and ribbon and no navigation window but does mean you can use the tabbed documents view of your forms. However runtime does not enable right click menus. If your app relies on these for sorting/filtering etc you will need to write your own. The .accdr ability is really there for the benefit of developers who know their app will be run in the runtime environment so a knowledgeable user who has a full version of access can simply rename it back again.

There is quite a lot more you can do but usually you need to know this before you start developing your app otherwise you can be into major rewrites.

[HansBades]

Thank you. Lots for me to think about it. I appreciate your expertise.