We have an Access 2010 DB to give users. We need to prevent them from altering any forms, code, etc. All we want them to do is change data exposed on our forms. But if we ever need to change the DB objects, they can send it back to us, we'll then have Admin privilege to do anything, and we'll send it back to them, still locked down.

We did this in Access 2000 via Workgroups, where we revoked all access to forms, code, etc, from the MS default Admin, and made our own Admin user, which was the only one with permission to alter all DB objects. I've read Access 2010 is different in how it does security. So how can we lock out users, yet gain access when needed? We can use whatever format works (mdb, accdb, accde, etc.).

If you compile to the.accde format, users cannot alter Forms, Report, Modules or Macros. They could modify Tables and Queries to some degree, however. One method I've seen with 2007 and later is to create a password-protected database, and then use a 'launcher' to open that database (so you don't have to give out the actual password to the database). Essentially your launcher would just fire off this code: Private Function OpenDB(DBPath as string) As Boolean Dim acc As Object acc = CreateObject('Access.Appli cation') acc.OpenCurrentDatabase DBPath,, 'YourPassword' acc.Visible = True End Function Generally you'd do this from.NET, but you could also do it using a second Access database.

As has been said, the accdb format no longer supports work group level security. But really, that's not important anyway. ULS was easy cracked and should not be used to protect a DB. There are several things you might do: 1. Put a password on the VBA project.

They won't be able to modify code without it. Still can distribute in the mdb, accdb format. Distribute as a MDE. Here the source code is stripped out. Not modifying anything with code. There are also some products that can further help protect the DB: VBA code protector: Keyed access: Jim. Sounds like you are distributing monolithic applications.

A better model is a split FE/BE. That way the BE contains ONLY data (tables) and the FE contains everything else. To replace the FE, you just send the user a new copy. He doesn't need to send you the original and that means that you don't have to worry about preserving the data in it. As others have suggested, you can send the users compiled databases in.accde format.

When you open an object, buttons appear in the lower- right corner of the Access window. The following describes how you close a database and exit Access. To close a database: Click the Microsoft Office button. A menu appears. Click Close Database. Access closes the database. To exit Access: Click the Microsoft Office button. A menu appears. Strengthen database security with real-time database activity monitoring, virtual patching, and database vulnerability scanning that secures physical, virtual, and.

However, and that's a big HOWEVER, you MUST retain the.accdb because you can't modify the.accde/.mde. You MUST go back to the.accdb/.mdb and modify the object there. Then recompile and resend. Using the compiled database model you really have to go with a split FE/BE because otherwise, you'll need to get the data out of the.accde/.mde they send you and put it into the new database you create from the original.accdb/.mdb. So, a monolithic.accde/.mde is a poor option.

One other option is renaming the.accdb to. Download Dragon Ball Af Episode 1 Mp4 on this page. accdr. This doesn't offer any real protection since a knowledgable user can just rename it back to gain full access. That file type tells Access to pretend to be the runtime engine and so it will never open the database in design view so it is not possible to change objects unless you know enough to rename the database.

We would need to know more about your business to advise more specifically. Are these your company people? Are the apps in fact monolithic? Are you willing to split them? What are you trying to protect against? Do you have the ability/willingness to keep all the FE's in inventory so you always change your version rather than relying on the user to send you his? Thanks for the input, everyone.

MDB and Workspace: I tried the mdb format with the old workspace and opened the file in Access 2010. But it wouldn't let me modify anything, even with our own Admin workspace.

Given that, and that it sounds like unreliable/older tech, it seems I should avoid it. ACCDE: Sounds like compiling in accde will not be sufficient, as I'm even more concerned about them tampering with tables than forms. And it sounds like I can't get back into it to modify objects later.

Password: I converted our master copy to accdb and set a password. But this requires a password just to get into the DB -- it does not lock access to any design modes. If that's all it does, then it can't work. Monolithic vs Split: We've did monolithic, but I agree, split would be better.

It never occurred to us since we only had update it once a few years ago, and to do so, we wrote a program that all users ran which imported their data into a newer DB. This is our only program like this, because it's so small and we knew updates would be very rare. So we made it quick and easy in Access, yet retained security -- workspaces allowed that. However, now moving to Access 2007/2010, we're willing to split into FE/BE. I envision each remote user has a BE DB, and we can then replace the FE DB if needed. But how to retain security?

We don't want users altering any objects (forms, reports, tables, etc) or to import any forms or reports into another DB. >ULS (User Level Security) is no longer in the product, so no I would not rely on it. It was easily crackable anyway and more trouble then it was worth. >Tampering the tables as in the design of?

If so, you can't use a JET DB to store the data. There is no way to prevent that with ULS gone. You'd need to use something like SQL Server as a back end. >That's a password on the DB. You can place a password only on the VBA project.

When you do that, they can't modify code. >Split and distribute with as a.accde. Also rig it so that it only runs in 'runtime' mode. The.accde only protects code.

It does not protect tables, queries, and macros. As I said earlier, you need to rename the file to.accdr to coerce access into pretending to be the runtime engine. If your users are not technical, this is probably sufficient. Access doesn't really care what the extension is. The only reason we use fixed extensions is so that Windows will know what program to use to open a file when you double click on it. Create the.accde and make absolutely certain that you store the.accdb safely because there is no official way back although you can pay someone to crack the.accde and get the code back but it won't be pretty.

It is best to not loose the master.accdb. Rename the FE as.accdr 3.

Rename the BE as something non-standard like.abc. Just make sure you pick something that is not registered with Windows. You don't want someone double clicking on the file and having some other program trying to open your database.

Word in particular will destroy a database if you try to open one with it. When you link to the tables, you will need to paste the file name into the dialog box since the dialog is programmed to only bring up 'Access' file types. If you want the FE to automatically link to the BE, you need some control over path names. I don't like having the FE and BE in the same folder. But you can create an install that puts the BE in a folder below the FE folder.

Don't give it the obvious name of database unless you want people to investigate. Again, obfuscation is best. The app can determine it's current location and append the hardcoded sub folder name to find the BE to relink when it opens. If the FE is growing faster than the BE it is because you are using temp tables or something else that causes bloat.

Temp tables are almost never necessary since querydefs and tables are interchangeable for most purposes. Temp tables are normally only used when you are summarizing huge tables and need to use the data for multiple reports. An alternate solution is to create a dummy database to hold the temp tables.

Delete the temp database when you open the main database and recreate it. That completely eliminates the bloat caused by temp tables because they don't exist in the FE. Either set the file to compact on close (generally not recommended) or give the user a utilities form with a button to do it. You should also keep a log so you can remind him to do it at least once per week or you can track the file size and if it grows by more than a given percentage do it automatically on close when the threshold is reached.

There were no temp tables, and the growth was minimal, so we're safe there. But in testing, there's a new problem. The ACCDE file does NOT open in Access 2010 64-bit. If I leave it as ACCDB, it does. This is because I have Access 32-bit where I created the ACCDE. This is annoying.

So to work with both Access 32-bit and 64-bit, we have to avoid ACCDE? That would have been nice to know from the start. Bottom line, with mdb, I had locked-down security via workgroups. With ACCDB, any simple and robust security was removed, and the workaround with ACCDE is limited -- both in the environment it can run on, and in the amount of actual security it gives. This only leaves me with renaming my ACCDB file to ACCDR.

Given the user simply needs to change the name, this seems like a big step backward. Am I wrong about that? Or is there a solution still missing here?

All I want is an up-to-date Access DB, in the newer format, that users can't poke around in, that works in 32 and 64-bit environments. Can't really be done apparently? There is lots of stuff written on the incompatibility of bit-wise versions of Access and even Microsoft recommends that you install the 32-bit version of Office. The ONLY reason to install the 64-bit version is if you need to support humongous Excel spreadsheets. And there are many reasons not to install 64-bit Office. The reason that the.accde will not work in both environments is because it is the compiled version of the app.

Compiled code NEVER works in a different bit environment. This is NOT an Access issue. It applies to ALL software. If you want to distribute.accde in a mixed environment, you MUST create two files.

One for each bit version. The.accdb is compiled on the fly and so except for API references which are not compatible but which you can embed in conditional compilation statements, you can use the same database file in both bit-versions. That actually gives Access an advantage.

I agree that the removal of ULS was a mistake. MS removed it because most people implemented it incorrectly and it caused enormous problems. Rather than make it simpler to implement, they convinced themselves they didn't need it and so removed it. I think they didn't understand that the user base was more likely to be using ULS to secure database objects than to secure data. There is no adequate substitution for ULS.

You can create your own security and make it semi-difficult to circumvent but you still need the extra protection of the.accde. I support software for clients all over the country. My positions is this - the data is theirs. If they mess it up by opening the BE and going behind the scenes and mucking around, it is on their head. - the code is mine.

If they want a change, I always start from my own backup copy. If they have made changes, they are lost.

Summer Fun Programs Hawaii 2014. If the software is proprietary and you don't want the user to see anything, that is more of a problem since you can never totally secure an Access FE, and that includes an.mdb with ULS. Same issue with the BE. If you want to hide the schema, you need to obfuscate the file name as I suggested earlier and hope they don't catch on. You can hide stuff and make it generally hard to find things but a file is just that and someone can crack it. A SQL Server database is certainly more secure but although it would hide the data from the individual users, it wouldn't hide the data from the client.

Their DBA would have full access to the database (and he should) so he can manage it. .Net is a slightly different animal.

When you compile, it's closer to a true incremental compile than VBA is. When you 'compile' a.Net program, it's compiled into a common intermediate language.

At run time, the CLR (Common Language Run time) is what actually takes takes it native. VBA's problem is the references which a MDE includes. It can't switch to 64 bit versions of those, which is why it fails. >The build setting is often mis-understood. It doesn't change the assembly in any way that I'm aware of, but simply sets the header to indicate the type of platform you intended the code to run on.

So choosing 'any CPU' doesn't mean the code will run on any CPU without issue. The operating systems in most cases these days are 64-bit because the hardware is 64-bit. But, individual software products may be either 32-bit or 64-bit.

It is an individual software product that is running the Access app and they are not built with the flexibility of the operating system. The 'bit' is the size of the registers that the hardware supports. Registers are what the compiled code uses to load addresses into. If I want to copy a value from a form field to a variable in memory, it is just one statement in VBA or any other high level language.

The compiled code represents a dozen machine language instructions including loading target and source registers with the actual physical memory address of the sending and receiving fields. A 64-bit register allows the program to address a larger memory space. So programs can be larger and more data can be loaded into memory (hence the humongous spreadsheets).

32-bit software works on 64-bit hardware because the operating system allows the software to 'mask' the high order bits in the register as if they didn't exist but that means that they are not addressable either. The operating system manages loading programs as they run and it knows that it has to load 32-bit programs into 'low' memory since they don't have registers large enough to address all of memory. Within that the generated code works on a base and displacement scheme. The 'base' is where I am loaded in memory and the 'displacement' is where I am within myself. So the code references things with a base register which keeps its program load address and always adds to it a displacement that comes from a different register. So, I am at position 302224 in the code but am loaded into memory at 100000 so in reality the reference is to 100000 + 302224.

At some point we'll go to 128-bit hardware and the 32-bit software will no longer be able to run in native mode just as the 16-bit software can't run natively on 64-bit hardware although there are software programs that act as wrappers to allow the old software to function.