Disable table import?

[SimonB1978]

Hi,

My app is split into FE/BE. BE is password protected. FE is not, relies on Windows login for rights. Password to BE is "stored" in FE's table connection strings.

Importing a table from FE then gives out the password to BE. Is there a way to prevent the tables (and links) from the FE from being imported into a blank DB?

I'm looking for a solution that will not require user to use yet another password...

Thanks,

Simon B.

 

[HiTechCoach]

Assuming you have an Active Directory/Domain for authentication.

I find if I must secure the back end, I use MS SQL server with Windows Authentication (use windows security). This way the password is not visible in any manner.

Otherwise you can do a lot of coding to get your own vPPC

See:
vPPPC discussion

and also

vPPC Security Toolkit (VST)

 

[DCrake]

The easiest and quickest way to prevent imports from the front is to mark the linked tables as hidden then set Show hidden objects to False. That way if someone wants to try and import a table from the front end the import wizard doesn't find any tables. Crude but it works.

David

 

[SimonB1978]

Thank you David!

That does exactly what I wanted!!!

Simon B.

 

[SimonB1978]

Finally, not exactly what I wanted...

If the "Show hidden object" is on in the blank DB you can see the hidden tables...

Simon B.

 

[DCrake]

You are correct, I just tested it, and I am suprised it worked. Also I am even more surprised it did not ak me for the password for the back end. I suppose it is relying on the first linked mdb to retain integrity.

Sorry

David

 

[HiTechCoach]

As you have found out, using the hidden property from the database windows does not really do much. That is why I did not suggest it.

it is possible to hide a table via code that really makes it hidden.

With CurrentDB.TableDefs("tblMyTable")
  .Attributes = .Attributes or dbHiddenObject
End With

Note: There was a bug in older versions of JET that would delete the object when the database was compacted. Be sure tio test this on a copy of your front end.

You have to use code to un-hide the table also.

Using the about method hides the tables from being looked up in any way, like in the query designer. You can still use the table names in VBA code and queries will still run against the tables. With the tables hidden, development becomes very difficult. I woudl never hid table in your master/development copy with this method.

So I do not hide the tables until ready to deploy and only in the MDE. In the MDE, I run code to lock it down which includes hidden linked tables with a password by reading the MsysObjects table. I only do this in the MDE so I do not have to worry about written code to unhide the tables.

 

[SimonB1978]

Sounds interesting... I'll give that a try and let you know next week...

Thanks,

Simon B.

 

[SimonB1978]

Well...

the .Attributes method will work for "real" tables but not linked ones. I've checked the vPPC thing and it looks like a very nice solution, but WAY to much work for what I need... In fact, I don't really need security, I was more interested in how far I can protect my db...

Thanks to all,

Simon B.

 

[HiTechCoach]

Well...

the .Attributes method will work for "real" tables but not linked ones. I've checked the vPPC thing and it looks like a very nice solution, but WAY to much work for what I need... In fact, I don't really need security, I was more interested in how far I can protect my db...

Thanks to all,

Simon B.

Using some type of security model is the only way I have found to get close to any type of protection for a database.

I think of it like this: Security => protection. No security => no protection

 

[gemma-the-husky]

why load the table into the back end

load it into the front end, and then integrate the imported date into the back end

no new pwd needed in that case surely?