MDE Backend?

[mbentley]

Has anyone ever tried setting up the backend of a split database as an mde file? It occurs to be that this might be smart, but I've never tried it or heard it suggested, and I'm thinking there must be a reason.

 

[ghudson]

Why? The users can still view/modify the tables unless you are using Access security with workgroups and persmissons. MDEs do not protect tables, queries and macros...only the design of your forms, reports and modules. A typical backend will only contain tables.

HTH

 

[mbentley]

Actually, user-level security applied to the front end won't protect the backend. The backend is usually protected by operating system security.

My reasoning was from a performance standpoint. I have heard that aside from being more secure, MDE files perform better. I'm guessing that this only applies to forms, reports, and modules, but you never know.

 

[ghudson]

Actually, user-level security applied to the front end won't protect the back-end. The back-end is usually protected by operating system security.

You should also apply the security [workgroup and permission's] to the back-end to prevent someone from altering the design of the back-end and also from messing with the table data. Network security will not prevent someone who as access to the folder where the back-end sits from messing with the design of the db and/also from directly updating the tables.

My reasoning was from a performance standpoint. I have heard that aside from being more secure, MDE files perform better. I'm guessing that this only applies to forms, reports, and modules, but you never know.

The MDEs do compile the code and that is supposed to make them operate a little bit faster but I have never noticed any improvements in terms of data speed. MDEs are a cheap way of protecting the design of your forms, reports and modules. Sometimes MDEs are easier to use for a quick distribution if a runtime installation is not practicle.

HTH

 

[mbentley]

This is sort of getting off the topic, but the path to the backend is actually hidden by linking the tables in the front end directly to ther server rather than by mapping the drive on the user's system. If the front end is correctly restricted, the user cannot find the path to the backend from it.

I'm personally no expert, but everyone I've spoken to here and in other forums says that you do not apply user-level security to the backend. It has something to do with problems linking. I can't really remember off the top of my head, and don't feel like looking it up.

 

[Autoeng]

I think if proper measures are taken (as you indicate) there is no reason to waste the effort and time to secure the BE. I also make the BE files hidden just for that little bit extra.

 

[mbentley]

Thanks Autoeng. I've also heard of of making the tables themselves hidden within the backend, although I don't personally do that.

 

[pono1]

You can never win when it comes to security.

But between the two, what would you rather not say to someone for whom you built a DB?

1. "I didn't implement security on the data (BE) and now it is lost/corrupted/compromised."

2. "I didn't implement security on my code (FE) and now it is lost/corrupted/compromised."

While a fastidous network administrator can hide your DB file, I would guess that, in the end, your tables are not terribly secure. Anyone with elementary DOS skills would be able to see a hidden file. And many network admins are overstretched and prone to boo-boos while some network admins are sloppy and others just don't know security or don't care.

Yet even with a cleverly locked down network, because Access requires write and edit rights to the Access file and read-write-delete permissions to the DB folder you are always vulnerable. That doesn't mean anything will happen that you will later regret, nor does it mean the chances of anything happening are high, but it does mean a person who is determined to get access to your DB probably will -- certainly your net admins can do as they please if there's no Jet security implemented on the tables.

But here's the final catch: Jet security is not impregnable. There are "password recovery tools" available on the Internet that can retrieve VBA and workgroup passwords.

Regards,
Tim

 

[mbentley]

You'd have to be kidding yourself to think there's any real security, but it comes down to the low-hanging fruit. In the end, all we can do is make it as tight as possible.

 

[CALV]

Interesing topic which applies to my current db also, though I have the advantage of being network admin
But reading through these posts,

If the front end is correctly restricted, the user cannot find the path to the backend from it

sprang to mind, I once had a small db whose back end was on a "common" network share, all the company used this drive for "junk", the folder which contained the back end was called something odd, the dbase wasnt used for ages, then for some reason we needed some info from it, I could only find the MDE and not the unlocked mdb and couldnt remember where the tables where- easy option, unplug network cable, then fire up the dbase and you get an access error saying the file"F:\pathtodbase\etc\etc could not be found" Is there a way around this error? i.e. a custom error maybe ?

CALV

 

[mbentley]

That's a good point. I wonder if there's a way to trap that error and customize the error message...

I've now had a chance to look at this. It triggers a 3024 error that is easily trapped in the Form_Error event.