tdfLocal.Attributes = tdfLocal.Attributes Or dbHiddenObject
I get the error 3001 - "Invalid Argument"
However, I found the following in a previous post, but beware, it also
stated that after compacting you may lose your table; Test Test TEST!
CurrentDb.TableDefs("<YourTableName>").Attributes = dbHiddenObject
"For example John Smith" <som...@microsoft.com> wrote in message
news:3f16cfff$0$18748$afc3...@news.easynet.co.uk...
Don't bother with the hard stuff. Someone helped me out this one a
short time ago. Prefix your table filename with Usys. If your system
files are hidden, so will the Usys.
It's quite pointless "hiding" tables.
What's to stop the user *un*-hiding them?
TC
Bit like a padlock, stops the casual thief but what's to stop real
criminal picking the lock?
--
Ride Free (but you still have to pay for the petrol)
(replace sithlord with trevor for email)
True. A small amount of effort stops 99% of would-be hackers, and *no*
amount of effort stops the other 1%. But hiding tables seems so lame! If the
users don't have access to the db window, hiding windows is pointless
(because they can not see them anyway). If they *do* have access to the db
window, the unhide option is just a click or two away. It's like locking the
drawer with a padlock, but taping the key to the side of the padlock! :-)
TC
If you are controlling the database window, then you do not need to hide a
table, since everything is displayed in your forms. That is, unless you let
users select tables for ad-hoc queries, in which case you may want to hide
some tables/queries and prevent the Add Table list from being overwhelming
with too many tables. Of course, the users can always open your backend
database and view anything they want.
In Access 97, you can use SendKeys temporarily in a development environment,
if you are careful about not opening other applications. (SendKeys can be
dangerous, and it is NOT suitable in a production runtime application!) In
Access 2000, you can use SetHiddenAttribute. Here is some sample code:
Private Sub HideObject(lngObjectType As AcObjectType, strObjectName As
String, db As Database)
#If isAccess97 Then ' use SendKeys for Access 97 only
If isObjectListed(lngObjectType, strObjectName, db) Then ' check if
object exists
If Not (isHidden(lngObjectType, strObjectName, db)) Then ' check
MSysObjects for the flags
DoCmd.SelectObject lngObjectType, strObjectName, True
SendKeys "%{Enter}%d{Enter}", True
End If
End If
#Else ' Access 2000 has a direct method
If isObjectListed(lngObjectType, strObjectName, db) Then
SetHiddenAttribute lngObjectType, strObjectName, True
End If
#End If
End Sub
- Steve
"TC" <a...@b.c.d> wrote in message news:1058511489.590850@teuthos...
(snip)
> More sophisticated systems (RSA, SSL, etc.) have been
> cracked in periods *FAR* under the "several billion
> years" statements companies usually state.
Often, though, this is due to errors in the cipher implementation: not
weaknesses in the cipher itself.
For example, the first version of Access encryption used a single RC4 key to
encrypt the whole database. Unfortunately, with a symmetric cipher such as
RC4, you should never use the same key to encrypt different messages (or in
this case, databases). If you do, the encrytion can be trivially & instantly
broken using a so-called "known plaintext" attack.
The first version of Access encryption was instantly cracked, using that
method. But that was not a crack of, or weakness in, RC4. It was a
"schoolboy howler" mistake in how microsoft chose to use that cipher :-)
TC