Runtime versus accdr

Don't confuse the runtime version of Access with a runtime database.

They are different things!

The runtime version of Access is an installed msaccess.exe crippled by the removal of most design tools. If all the user has is the (free) runtime version, then the design window buttons for forms, reports, VBA and so on are all greyed out, and they cannot even get into the mode to change the structure of things; nor can they even see your VBA code. It doesn't matter whether the database is named .accdb, .accdr,  .accde, .mdb or whatever - the program itself simply doesn't contain the code to let them change the design.

However, if the user has a full retail or corporate version of Access installed, then they CAN get into design mode. Changing the extension to .accdr just tells retail Access to behave as if it were the runtime version (it's good for testing to make sure that you aren't preventing the user from doing legitimate work). But it does NOTHING to protect the database; the user can just rename it back to .accdb and do whatever they like. Changing the extension doesn't affect what's in the database in any way whatsoever!

What you CAN - and should - do is to use the Make ACCDE option to "compile" the .accdb database into a .accde version. This compiles and hides all the VBA code, and turns off most of the design tools (e.g. you can't open a Form in design view). You can still design or change Queries, but not forms or reports. It's possible (using third-party tools you can find on the web) to convert a .accde back to a .accdb but it's not something most endusers will be able to do.

I'd suggest keeping your own master copy of the frontend as a .accdb file, well backed up both onsite and offsite; make .accde files for your users, both for security and because they're usually a bit smaller and a bit faster. When they need a new feature, create and test it in your master copy and then make and distribute a new .accde. It's totally up to you (and your IT department if you have one) whether to buy each user a retail Access license and install the full program, or install just the runtime.

It's all but impossible to TOTALLY secure the backend. If the database is to be usable at all, then it must be open for reading and writing; if a user can (say) legitimately delete or change some records, then there's no easy way to prevent them from ILLEGITIMATELY deleting or changing some other records.  If data security is a big issue, you'll need to go to SQL/Server as the backend, with data logging, hot multilevel backups, rollbacks and recoveries, and all the things DBA's get paid for. You just need to decide how much effort you need to expend for your particular situation - anything from having one shared .accdb backend (backed up both onsite and offsite at a minimum), to - well, the sky's the limit.

Ummm... when it comes to vehicles, which is the best to get? Is a Lamborghini sports car better than a Allison-Chalmers earthmover? Depends on what you want it for!

SQL/Server is a Microsoft product available in many flavors, from single- or few-user versions that can run under a desktop Windows system, up to enterprise-scale versions that can use terabytes of storage and hundreds of networked processors. There are many competitors in the "server" database market - Oracle, DB/2, Alpha, MySQL, on and on. It would be a major research effort (which I haven't done) to even build a list for comparison, much less to evaluate them for suitability for some particular use. So there is no one answer to your question!