UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> Unhiding Hidden Tables, Access 2016    
 
   
azizrasul
post Feb 14 2019, 11:41 AM
Post#1



Posts: 1,463
Joined: 18-July 00
From: Faisalabad, Pakistan


I have the following code from which I am trying to unhide the two tables given below. But it doesn't show the two tables?

CODE
    CurrentDb.TableDefs("tblUtilities").Attributes = dbHiddenObject
    CurrentDb.TableDefs("tblDatabaseUsers").Attributes = dbHiddenObject

    Application.SetOption "Show Hidden Objects", True


I may have in my rummaging set the two tables as system tables. When find the attributes of the two tables I get a 1.

When I tried running

CODE
Application.SetHiddenAttribute acTable, "tblUtilities", False


I get the error that I can't modify the attributes of a system table. However when I use the following line, the two tables still don't appear.

CODE
Application.SetOption "Show System Objects", True


The object of my exercise, whether it's possible or not, is to prevent a user from creating a new db and importing db objects from my db. I know I can password protect my db, but I am assuming that the rogue user is able to get the password cracked.
Hope that makes sense.
This post has been edited by azizrasul: Feb 14 2019, 11:55 AM

--------------------
Aziz
Go to the top of the page
 
theDBguy
post Feb 14 2019, 12:27 PM
Post#2


Access Wiki and Forums Moderator
Posts: 76,000
Joined: 19-June 07
From: SunnySandyEggo


Hi. The problem with your first approach is it doesn't modify the "hidden attribute" you may have been thinking of - the one you see when you go to the Table Properties window. That one is modified by using this code instead of the one you first tried:

CODE
Application.SetHiddenAttribute acTable, "YourTable", True

What you discovered by using the Attributes property is the "other way" of hiding a table, which is not affected by the Show Hidden Objects settings. So, if you truly want to hide the table from your users, using your first code would be better than the one I just showed you.

--------------------
Just my 2 cents... "And if I claim to be a wise man, it surely means that I don't know" - Kansas
Access Website | Access Blog | Email
Go to the top of the page
 
theDBguy
post Feb 14 2019, 12:30 PM
Post#3


Access Wiki and Forums Moderator
Posts: 76,000
Joined: 19-June 07
From: SunnySandyEggo


PS. Just a quick caveat...

If the table you're trying to hid already has other attributes assigned, using your code will replace those. So, in effect, the code you were using is incomplete. That's probably why the "System" attribute got affected by your code. Just a guess...

--------------------
Just my 2 cents... "And if I claim to be a wise man, it surely means that I don't know" - Kansas
Access Website | Access Blog | Email
Go to the top of the page
 
azizrasul
post Feb 14 2019, 03:30 PM
Post#4



Posts: 1,463
Joined: 18-July 00
From: Faisalabad, Pakistan


Are you saying that the code you used in your post is the one I should be using?

--------------------
Aziz
Go to the top of the page
 
theDBguy
post Feb 14 2019, 03:35 PM
Post#5


Access Wiki and Forums Moderator
Posts: 76,000
Joined: 19-June 07
From: SunnySandyEggo


It depends on what you're trying to accomplish. If you merely want to automate the process of going to the Table Properties window and checking the Hidden checkbox and also want to make sure you can see the "hidden" table when you check the Show Hidden Objects in the Options window, then yes, you should use the code I posted. Otherwise, you'll need a better code than the one you originally used to "really" hide the tables.

--------------------
Just my 2 cents... "And if I claim to be a wise man, it surely means that I don't know" - Kansas
Access Website | Access Blog | Email
Go to the top of the page
 
azizrasul
post Feb 14 2019, 04:24 PM
Post#6



Posts: 1,463
Joined: 18-July 00
From: Faisalabad, Pakistan


Well I want to prevent others from importing the tables. Is that possible?

--------------------
Aziz
Go to the top of the page
 
theDBguy
post Feb 14 2019, 04:56 PM
Post#7


Access Wiki and Forums Moderator
Posts: 76,000
Joined: 19-June 07
From: SunnySandyEggo


QUOTE
Well I want to prevent others from importing the tables. Is that possible?
No, it's not possible. You can spend a lot of time trying to stop it, and it might stop some people, but it won't stop all of them. Your other option is to not use Access tables and move your data into a true RDBMS server instead.

--------------------
Just my 2 cents... "And if I claim to be a wise man, it surely means that I don't know" - Kansas
Access Website | Access Blog | Email
Go to the top of the page
 
isladogs
post Feb 14 2019, 05:54 PM
Post#8


UtterAccess VIP
Posts: 1,541
Joined: 4-June 18
From: Somerset, UK


ANY table can have dbHiddenObject attribute applied whether or not they are system tables
Doing so does not make them become system tables.
Ticking show system objects' does not make them visible in the navigation pane.

It is possible to restore what I call 'deep hidden' tables (if you know how).
The attached demo contains two of these tables, one of which you can make visible on a button click
See if you can make the other table visible!

Agree with the DBGuy.
You can certainly make Access databases very difficult to crack but they can never be 100% secure.
A capable and determined hacker can break any Access database given sufficient time and motivation
However, by erecting various barriers, it is certainly possible to make the process so difficult and time consuming that it isn't normally worth attempting.

My security challenges were designed to do just that (but in the form of a 'fun' puzzle).
I believe challenges #2 & #3 took several days for those who did solve them.

However, if security is that important move the data into SQL Server
This post has been edited by isladogs: Feb 14 2019, 05:56 PM
Attached File(s)
Attached File  DeepHideTablesExample.zip ( 28.48K )Number of downloads: 22
 

--------------------
Go to the top of the page
 
azizrasul
post Feb 15 2019, 04:07 AM
Post#9



Posts: 1,463
Joined: 18-July 00
From: Faisalabad, Pakistan


But surely if we have linked SQL server tables in an MS Access db, there is nothing stopping me from creating a new MS Access database and importing the linked tables? If the db is purely in SQL Server and there is no MS Access database involved, then I understand.

isladogs, probably won't be able to meet your challenge as I have managed to hide 2 of my own tables and I can't see them anymore no matter what I do. Took theDBguy advice in which code I should use and used the following code to try to UNHIDE my two tables but with no success: -

CODE
    Application.SetHiddenAttribute acTable, "tblUtilities", False
    Application.SetHiddenAttribute acTable, "tblDatabaseUsers", False
    Application.SetOption "Show Hidden Objects", True


I have even tried to open a new MS Access db to see if I can import "tblUtilities" and "tblDatabaseUsers", but they don't appear in the list. I seem to have 'deeply hidden' my own two tables successfully. LOL. Hence I have my own personal challenge before I get on to yours isladogs.
This post has been edited by azizrasul: Feb 15 2019, 04:21 AM

--------------------
Aziz
Go to the top of the page
 
isladogs
post Feb 15 2019, 05:18 AM
Post#10


UtterAccess VIP
Posts: 1,541
Joined: 4-June 18
From: Somerset, UK


All that code will do is make tables that are hidden in the 'standard' way visible again.

I do know how to recover/view any deep hidden table including the various 'invisible' system tables.
For security reasons, I will never supply the solution online despite repeated requests to do so.

However if you can give me confirmation that the table are yours to view, I'm prepared to unhide them for you.
If you want to take up that offer, please make a copy of that database removing everything else from it.
Zip and email it to me using the link in my signature line.
Don't forget I need evidence that you are allowed to view the data it contains.

As long as its straightforward to do, I won't charge.
Alternatively companies like EverythingAccess.com will recover files for you...at a price ...but they also require proof of ownership

As for Access vs SQL Server...
If I am able to view your FE directly or indirectly, I can just export the linked tables whether Access based or in SQL Server
I can also easily find out the connection strings/password to the BE files
In fact I can do that without opening the FE in Access
However its much harder if your FE is encrypted with a password that I don't know.

One of the weaknesses in Access is that it is a file based system.
If I only had a few minute to hack your system, I could copy the FE/BE files onto a memory stick and take them away to do at my leisure.
However with SQL Server, you first need access to the server application before you can grab a backup of the datafile.
This post has been edited by isladogs: Feb 15 2019, 05:21 AM

--------------------
Go to the top of the page
 
azizrasul
post Feb 15 2019, 09:37 AM
Post#11



Posts: 1,463
Joined: 18-July 00
From: Faisalabad, Pakistan


Thanks for the offer isladogs.

Actually I was trying to create a demo MS Access db everything to do with security so that I could implement that security on the MS Access db (which contain SQL server linked tables) at work as there is no security and the data is sensitive and would be useful to a competitor. There is no one here that I think will 'steal' the data, but as a developer I thought it my duty to point out to the employers that there is a potential risk even though everyone is beyond reproach.

I was able to solve my problem by simply re-importing the two tables and when the dialog box appeared to say that the tables already existed do I want to overwrite, I said Yes and voila it worked.
I don't know what I did that led me to not recover the original tables as I was messing around with various stuff and must have hit a combination that led to it. However by re-importing, problem solved.

In addition, I was thinking of producing, insha-allaah, my own applications using the MS Access runtime environment. In this case, I may want to introduce some form of table protection for the purchaser in case there data was important.
So far, I have been able to prevent anyone from opening the database using the SHIFT, although I accept that can be overcome. Also in hiding the navigation pane, toolbars and menubars. The last thing was to protect the data. I understand why you can't give details here, so I'll carry on and see what I can do.

When I get time I will look at the challenge you sent me. Can't wait.
This post has been edited by azizrasul: Feb 15 2019, 09:39 AM

--------------------
Aziz
Go to the top of the page
 
theDBguy
post Feb 15 2019, 11:21 AM
Post#12


Access Wiki and Forums Moderator
Posts: 76,000
Joined: 19-June 07
From: SunnySandyEggo


Hi. I think if you really want to protect the data, then you should encrypt it. Anyone, not using your front end to connect to the data, will not be able to get it. If they use your front end, then your front end should restrict what they can and cannot do to avoid exporting the data out of the system.

--------------------
Just my 2 cents... "And if I claim to be a wise man, it surely means that I don't know" - Kansas
Access Website | Access Blog | Email
Go to the top of the page
 
isladogs
post Feb 15 2019, 11:51 AM
Post#13


UtterAccess VIP
Posts: 1,541
Joined: 4-June 18
From: Somerset, UK


Glad you have a solution to your current issue.

QUOTE
When I get time I will look at the challenge you sent me. Can't wait.


Have fun, That's the easiest of all the challenges. Only one hurdle to overcome - unhide the second deep hidden table.
If you succeed, please send me a PM or email to tell me how you solved it.
PLEASE do NOT publish the solution online or you will be helping others break your security

As DBG stated you really must encrypt your application with a password.
If unclear why it matters, please read this fairly lengthy article on my website: Compare Access file security
This post has been edited by isladogs: Feb 15 2019, 11:51 AM

--------------------
Go to the top of the page
 
gemmathehusky
post Apr 25 2019, 01:46 PM
Post#14


UtterAccess VIP
Posts: 4,725
Joined: 5-June 07
From: UK


I haven't checked that this is the correct object to use, but if you want to set that attribute, it's probably

CurrentDb.TableDefs("tblUtilities").Attributes = CurrentDb.TableDefs("tblUtilities").Attributes OR dbHiddenObject

This way, you are just setting a bit, rather than overwriting the entire bit map.


To read the attribute use AND. The brackets are optional but will make it clearer what is going on.

HiddenTable = (CurrentDb.TableDefs("tblUtilities").Attributes AND dbHiddenObject) = 1


[edit]
To remove the hidden attribute use XOR, which acts like a toggle, turning the bit on/off with each successive use.

CurrentDb.TableDefs("tblUtilities").Attributes = (CurrentDb.TableDefs("tblUtilities").Attributes XOR dbHiddenObject) = 1


I assume you can use this syntax directly, without using SET to set a pointer to the table def.
I also assume you can do this with linked tables, as you are hiding the table in the current database.

--------------------
Dave (Male)

(Gemma was my dog)
Go to the top of the page
 


Custom Search


RSSSearch   Top   Lo-Fi    18th August 2019 - 06:25 PM