Protect MDB any MVP

It would help to know the exact error message, but I'm betting the problem
is that that routine wasn't updated to reflect the fact that ADO has a
higher precedence than DAO in newer versions of Access (In fact, DAO isn't
even enable by default in Access 2000 or 2002).

Try changing

Dim ws As Workspace
Dim db As DATABASE
Dim prop As Property

to

Dim ws As DAO.Workspace
Dim db As DAO.DATABASE
Dim prop As DAO.Property

(Actually, only the 3rd is essential: there's a Property object in both the
ADO and DAO models, but Workspace and Database are unique to DAO. Still,
it's good practice to disambiguate)

As well, the function requires 2 arguments be passed to it. The first
argument is the full path to the database, and the second argument is
whether or not you want to disable the bypass key.

In the Immediate window, you need to type:

?faq_DisableShiftKeyBypass("C:\MyDatabase.mdb", True)

(including the question mark: replace C:\MyDatabase.mdb with the appropriate
path). It should return True if successful, False if not.


--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no e-mails, please!)


"Andy" wrote in message
...
Function faq_DisableShiftKeyBypass(strDBName as String, fAllow as Boolean)
As Boolean
From:

http://support.microsoft.com/default...2F secfaq.asp

It says it can be run from the Immediate Window.

Presume I place the function in a module and then type:
faq_DisableShiftKeyBypass
Then hit the Enter key.

It causes an error. Believe that is because I need to change a line
somewhere to the name of the Dbase.

"Arvin Meyer [MVP]" wrote in
:

Is there any sensible way to prevent a user creating a new file and
importing the objects from it?

Or reading the data by linking from a new mdb. Or from Excel?

It really depends upon what you need to lock up. If it's the forms,
reports, and code, an MDE should do the job nicely. The data is only
safe if protected by a server. If you create a new database, you
cannot import or export objects from a database front-end that is
properly secured or is an MDE.

I don't really understand the protectionism about hiding VBA code; but
then again, I don't earn my living from it either. Securing data, though,
is clearly a priority in many situations and that can be done by nothing
less than user-level workgroup security -- which is where the response to
this thread came in.

As with anything, a really determined
hacker can probably get in, but the average user is kept out.

Natch.


B Wishes

Tim F

The curious part, at least to me is this:
When any of the forms were imported into a new DBase the "Design View" was
"Grayed out".

Since you can import, then likely security was indeed setup.


The computer was not set for User Level Permissions, at least in the
general
sense of having to log on, the PC always starts as administrator,
(WindowsXP
w/Access 2002).

Don't confuse windows security with ms-access security, they are SEPARATE
issues. ms-access security (workgroup) does NOT use, or have ANY relation to
windows security. It is *still* possible (in fact likely) that workgroup
security was used. When you run ms-access, you ALWAYS MUST HAVE a workgroup
file. (ms-access WILL NOT START if you don't). Further, when you run
ms-access you ALWAYS MUST HAVE a user name. That default user name is
"admin". If the workgroup user password for admin is blank, then that is the
reason WHY you are not getting a logon prompt.

One more item:
Function faq_DisableShiftKeyBypass(strDBName as String, fAllow as Boolean)
As Boolean
From:
http://support.microsoft.com/default...2F secfaq.asp

It says it can be run from the Immediate Window.

Presume I place the function in a module and then type:
faq_DisableShiftKeyBypass
Then hit the Enter key.

Yes, the function obviously requites you to enter the name. Note

Function faq_DisableShiftKeyBypass(strDBName as String, fAllow as Boolean)

Look at the above....it needs two parameters.

Note that if you put the code in side of a database, then obviously it is
only going to be of "use" ONLY the next time launch the database. (since
you are already in). So, if you lock yourself out, then you need some "door"
(a special key, or hidden button, or something that you do to un-shift the
application). If you don't want to use the trap door, then grab my sample,
as it lets you "browse" to a given file, and change the setting. It uses the
above code.


There must be a way to block design changes in forms and reports, know
that
because I've seen it. Have yet to find a way to repeat it. Maybe this
"Kid" created his own code.
Don't know that. Do know this; I will learn how to do it again.

Since you *can* import forms, then it can't be a mde file. (if you make a
mde, then forms + reports don't import). So, logically, then it means that
security was used on this file..........

If you read the security document (found here)

http://www.mvps.org/access/resources/techpapers.htm

It does explain how to setup security, and not requite a user to logon....

Read the above.

If you open up user security settings, you should be able to see the
permsisons set for those forms.

Regardless, read the secrty faq. there is both a on-line, and downloadable
links can be found in the above...

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

http://www.members.shaw.ca/AlbertKallal

Hi;

Tried a suggestion from Marshall, renamed the extension MDE to MDB and was
still able to import the data from my "MDB" into a new DBase.

Andy

"Tim Ferguson" wrote in message
...
"Arvin Meyer [MVP]" wrote in
:

Is there any sensible way to prevent a user creating a new file and
importing the objects from it?

Or reading the data by linking from a new mdb. Or from Excel?

It really depends upon what you need to lock up. If it's the forms,
reports, and code, an MDE should do the job nicely. The data is only
safe if protected by a server. If you create a new database, you
cannot import or export objects from a database front-end that is
properly secured or is an MDE.

I don't really understand the protectionism about hiding VBA code; but
then again, I don't earn my living from it either. Securing data, though,
is clearly a priority in many situations and that can be done by nothing
less than user-level workgroup security -- which is where the response to
this thread came in.

As with anything, a really determined
hacker can probably get in, but the average user is kept out.

Natch.


B Wishes

Tim F

Albert;

Thank You. That was something I didn't know. I was confusing Windows Users
with Access Users.

The picture keeps getting clearer.

Andy


"Albert D.Kallal" wrote in message
...
The curious part, at least to me is this:
When any of the forms were imported into a new DBase the "Design View"
was
"Grayed out".

Since you can import, then likely security was indeed setup.


The computer was not set for User Level Permissions, at least in the
general
sense of having to log on, the PC always starts as administrator,
(WindowsXP
w/Access 2002).

Don't confuse windows security with ms-access security, they are SEPARATE
issues. ms-access security (workgroup) does NOT use, or have ANY relation
to
windows security. It is *still* possible (in fact likely) that workgroup
security was used. When you run ms-access, you ALWAYS MUST HAVE a
workgroup
file. (ms-access WILL NOT START if you don't). Further, when you run
ms-access you ALWAYS MUST HAVE a user name. That default user name is
"admin". If the workgroup user password for admin is blank, then that is
the
reason WHY you are not getting a logon prompt.

One more item:
Function faq_DisableShiftKeyBypass(strDBName as String, fAllow as
Boolean)
As Boolean
From:

http://support.microsoft.com/default...2F secfaq.asp

It says it can be run from the Immediate Window.

Presume I place the function in a module and then type:
faq_DisableShiftKeyBypass
Then hit the Enter key.

Yes, the function obviously requites you to enter the name. Note

Function faq_DisableShiftKeyBypass(strDBName as String, fAllow as
Boolean)

Look at the above....it needs two parameters.

Note that if you put the code in side of a database, then obviously it is
only going to be of "use" ONLY the next time launch the database. (since
you are already in). So, if you lock yourself out, then you need some
"door"
(a special key, or hidden button, or something that you do to un-shift the
application). If you don't want to use the trap door, then grab my sample,
as it lets you "browse" to a given file, and change the setting. It uses
the
above code.


There must be a way to block design changes in forms and reports, know
that
because I've seen it. Have yet to find a way to repeat it. Maybe this
"Kid" created his own code.
Don't know that. Do know this; I will learn how to do it again.

Since you *can* import forms, then it can't be a mde file. (if you make a
mde, then forms + reports don't import). So, logically, then it means that
security was used on this file..........

If you read the security document (found here)

http://www.mvps.org/access/resources/techpapers.htm

It does explain how to setup security, and not requite a user to logon....

Read the above.

If you open up user security settings, you should be able to see the
permsisons set for those forms.

Regardless, read the secrty faq. there is both a on-line, and downloadable
links can be found in the above...

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

http://www.members.shaw.ca/AlbertKallal

It's not even necessary to rename the file: you can import data from an .MDE

--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no e-mails, please!)



"Andy" wrote in message
...
Hi;

Tried a suggestion from Marshall, renamed the extension MDE to MDB and was
still able to import the data from my "MDB" into a new DBase.

Andy

Hi;

THANK ALL OF YOU!!!

Learned alot and was able to secure the database.

Still in "Quick Sand"
Function faq_DisableShiftKeyBypass(strDBName As String, fAllow As Boolean)
As Boolean
(From MSFT's Security FAQ)

Learned from Albert that the code had 2 parameters.
1 it needed the Dbase name in the strDBName. Did that.
The 2nd parameter isn't "Revealing" itself. What is it?

Also Getting Compile errors in Debug.
The Function includes these:
Dim ws As Workspace
Dim db As DATABASE

Both Workspace and DATABASE are returning "User Defined type Not Defined".
Highlighted each in turn and hit the F1 key, result for both "Keyword Not
Found".

Seemed to me that: Dim ws As Workspace was referrig to an Excel worksheet.
Re-read the section in FAQ and it only refers to Access and not Excel.
Added referrence: Microsoft DAO 3.6 Object Library
And the Compile worked.

Ran:
faq_DisableShiftKeyBypass
From the Immediate Window and got: "Compile Error Argument not Optional."

Moved strDBName As String, fAllow As Boolean from Function's name and
created:
Dim strDBName As String
Dim fAllow As Boolean

The code runs and returns ERR msg:
"Function DisableShiftKeyBypass did not complete successfully."
That is normal. Comment states it will occur the first time the code is
run.
Ran it twice and even 3 times still get same ERR.

Went to: http://www.mvps.org/access/general/gen0040.htm
And tried to use a version of Michael Kaplan's example.
It runs without errors but still can open using the ShiftKey.

Also tried opening the Dbase exclusively and running the code. Same
results.

Learned a lot. THANK YOU.

Please be so kind and provide a little more guidance.

Andy




"Albert D.Kallal" wrote in message
...
The curious part, at least to me is this:
When any of the forms were imported into a new DBase the "Design View"
was
"Grayed out".

Since you can import, then likely security was indeed setup.


The computer was not set for User Level Permissions, at least in the
general
sense of having to log on, the PC always starts as administrator,
(WindowsXP
w/Access 2002).

Don't confuse windows security with ms-access security, they are SEPARATE
issues. ms-access security (workgroup) does NOT use, or have ANY relation
to
windows security. It is *still* possible (in fact likely) that workgroup
security was used. When you run ms-access, you ALWAYS MUST HAVE a
workgroup
file. (ms-access WILL NOT START if you don't). Further, when you run
ms-access you ALWAYS MUST HAVE a user name. That default user name is
"admin". If the workgroup user password for admin is blank, then that is
the
reason WHY you are not getting a logon prompt.

One more item:
Function faq_DisableShiftKeyBypass(strDBName as String, fAllow as
Boolean)
As Boolean
From:

http://support.microsoft.com/default...2F secfaq.asp

It says it can be run from the Immediate Window.

Presume I place the function in a module and then type:
faq_DisableShiftKeyBypass
Then hit the Enter key.

Yes, the function obviously requites you to enter the name. Note

Function faq_DisableShiftKeyBypass(strDBName as String, fAllow as
Boolean)

Look at the above....it needs two parameters.

Note that if you put the code in side of a database, then obviously it is
only going to be of "use" ONLY the next time launch the database. (since
you are already in). So, if you lock yourself out, then you need some
"door"
(a special key, or hidden button, or something that you do to un-shift the
application). If you don't want to use the trap door, then grab my sample,
as it lets you "browse" to a given file, and change the setting. It uses
the
above code.


There must be a way to block design changes in forms and reports, know
that
because I've seen it. Have yet to find a way to repeat it. Maybe this
"Kid" created his own code.
Don't know that. Do know this; I will learn how to do it again.

Since you *can* import forms, then it can't be a mde file. (if you make a
mde, then forms + reports don't import). So, logically, then it means that
security was used on this file..........

If you read the security document (found here)

http://www.mvps.org/access/resources/techpapers.htm

It does explain how to setup security, and not requite a user to logon....

Read the above.

If you open up user security settings, you should be able to see the
permsisons set for those forms.

Regardless, read the secrty faq. there is both a on-line, and downloadable
links can be found in the above...

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

http://www.members.shaw.ca/AlbertKallal

Hi again.

Read through all these posts and the primary thing that stuck with me was
that the shift key would not be able ot open an MDE exposing the database
window.

Yet it does on my computer. Is that because it is the same Access2k
package?

And it really is protected as an MDE.

Andy

"Andy" wrote in message
...
Hi;

THANK ALL OF YOU!!!

Learned alot and was able to secure the database.

Still in "Quick Sand"
Function faq_DisableShiftKeyBypass(strDBName As String, fAllow As Boolean)
As Boolean
(From MSFT's Security FAQ)

Learned from Albert that the code had 2 parameters.
1 it needed the Dbase name in the strDBName. Did that.
The 2nd parameter isn't "Revealing" itself. What is it?

Also Getting Compile errors in Debug.
The Function includes these:
Dim ws As Workspace
Dim db As DATABASE

Both Workspace and DATABASE are returning "User Defined type Not Defined".
Highlighted each in turn and hit the F1 key, result for both "Keyword Not
Found".

Seemed to me that: Dim ws As Workspace was referrig to an Excel worksheet.
Re-read the section in FAQ and it only refers to Access and not Excel.
Added referrence: Microsoft DAO 3.6 Object Library
And the Compile worked.

Ran:
faq_DisableShiftKeyBypass
From the Immediate Window and got: "Compile Error Argument not Optional."

Moved strDBName As String, fAllow As Boolean from Function's name and
created:
Dim strDBName As String
Dim fAllow As Boolean

The code runs and returns ERR msg:
"Function DisableShiftKeyBypass did not complete successfully."
That is normal. Comment states it will occur the first time the code is
run.
Ran it twice and even 3 times still get same ERR.

Went to: http://www.mvps.org/access/general/gen0040.htm
And tried to use a version of Michael Kaplan's example.
It runs without errors but still can open using the ShiftKey.

Also tried opening the Dbase exclusively and running the code. Same
results.

Learned a lot. THANK YOU.

Please be so kind and provide a little more guidance.

Andy




"Albert D.Kallal" wrote in message
...
The curious part, at least to me is this:
When any of the forms were imported into a new DBase the "Design View"
was
"Grayed out".

Since you can import, then likely security was indeed setup.


The computer was not set for User Level Permissions, at least in the
general
sense of having to log on, the PC always starts as administrator,
(WindowsXP
w/Access 2002).

Don't confuse windows security with ms-access security, they are
SEPARATE
issues. ms-access security (workgroup) does NOT use, or have ANY
relation
to
windows security. It is *still* possible (in fact likely) that workgroup
security was used. When you run ms-access, you ALWAYS MUST HAVE a
workgroup
file. (ms-access WILL NOT START if you don't). Further, when you run
ms-access you ALWAYS MUST HAVE a user name. That default user name is
"admin". If the workgroup user password for admin is blank, then that is
the
reason WHY you are not getting a logon prompt.

One more item:
Function faq_DisableShiftKeyBypass(strDBName as String, fAllow as
Boolean)
As Boolean
From:


http://support.microsoft.com/default...2F secfaq.asp

It says it can be run from the Immediate Window.

Presume I place the function in a module and then type:
faq_DisableShiftKeyBypass
Then hit the Enter key.

Yes, the function obviously requites you to enter the name. Note

Function faq_DisableShiftKeyBypass(strDBName as String, fAllow as
Boolean)

Look at the above....it needs two parameters.

Note that if you put the code in side of a database, then obviously it
is
only going to be of "use" ONLY the next time launch the database.
(since
you are already in). So, if you lock yourself out, then you need some
"door"
(a special key, or hidden button, or something that you do to un-shift
the
application). If you don't want to use the trap door, then grab my
sample,
as it lets you "browse" to a given file, and change the setting. It uses
the
above code.


There must be a way to block design changes in forms and reports, know
that
because I've seen it. Have yet to find a way to repeat it. Maybe
this
"Kid" created his own code.
Don't know that. Do know this; I will learn how to do it again.

Since you *can* import forms, then it can't be a mde file. (if you make
a
mde, then forms + reports don't import). So, logically, then it means
that
security was used on this file..........

If you read the security document (found here)

http://www.mvps.org/access/resources/techpapers.htm

It does explain how to setup security, and not requite a user to
logon....

Read the above.

If you open up user security settings, you should be able to see the
permsisons set for those forms.

Regardless, read the secrty faq. there is both a on-line, and
downloadable
links can be found in the above...

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

http://www.members.shaw.ca/AlbertKallal

Andy wrote:
Hi again.

Read through all these posts and the primary thing that stuck with me
was that the shift key would not be able ot open an MDE exposing the
database window.

Sorry, but an MDE has absolutely nothing to do with the shift key. An MDE
locks all code-based objects (Forms, Reports, and Modules) so their design
can neither be viewed nor changed. It does nothing to hide the db window
and provides zero protection for queries, macros, or tables.

You CAN hide the db window on startup and disable the shift bypass key, but
that is completely separate from making an MDE as you can also do those on
an MDB.

In addition if you disable the shift bypass key and don't also secure the
database then anyone who knows how can re-enable the bypass key by running
code from another file.

In any case all queries and tables can be imported or viewed from other
files unless User Level Security is set up.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

Hi;

A question about an MDE believe that any Object in an MDE should not be
importable into a new DBase.

Can import any Objects from an MDE created on my PC. Is that because its
the same Access(2k), Package and it won't be importable in another Access
package?

Andy
"Andy" wrote in message
...
Hi;

THANK ALL OF YOU!!!

Learned alot and was able to secure the database.

Still in "Quick Sand"
Function faq_DisableShiftKeyBypass(strDBName As String, fAllow As Boolean)
As Boolean
(From MSFT's Security FAQ)

Learned from Albert that the code had 2 parameters.
1 it needed the Dbase name in the strDBName. Did that.
The 2nd parameter isn't "Revealing" itself. What is it?

Also Getting Compile errors in Debug.
The Function includes these:
Dim ws As Workspace
Dim db As DATABASE

Both Workspace and DATABASE are returning "User Defined type Not Defined".
Highlighted each in turn and hit the F1 key, result for both "Keyword Not
Found".

Seemed to me that: Dim ws As Workspace was referrig to an Excel worksheet.
Re-read the section in FAQ and it only refers to Access and not Excel.
Added referrence: Microsoft DAO 3.6 Object Library
And the Compile worked.

Ran:
faq_DisableShiftKeyBypass
From the Immediate Window and got: "Compile Error Argument not Optional."

Moved strDBName As String, fAllow As Boolean from Function's name and
created:
Dim strDBName As String
Dim fAllow As Boolean

The code runs and returns ERR msg:
"Function DisableShiftKeyBypass did not complete successfully."
That is normal. Comment states it will occur the first time the code is
run.
Ran it twice and even 3 times still get same ERR.

Went to: http://www.mvps.org/access/general/gen0040.htm
And tried to use a version of Michael Kaplan's example.
It runs without errors but still can open using the ShiftKey.

Also tried opening the Dbase exclusively and running the code. Same
results.

Learned a lot. THANK YOU.

Please be so kind and provide a little more guidance.

Andy




"Albert D.Kallal" wrote in message
...
The curious part, at least to me is this:
When any of the forms were imported into a new DBase the "Design View"
was
"Grayed out".

Since you can import, then likely security was indeed setup.


The computer was not set for User Level Permissions, at least in the
general
sense of having to log on, the PC always starts as administrator,
(WindowsXP
w/Access 2002).

Don't confuse windows security with ms-access security, they are
SEPARATE
issues. ms-access security (workgroup) does NOT use, or have ANY
relation
to
windows security. It is *still* possible (in fact likely) that workgroup
security was used. When you run ms-access, you ALWAYS MUST HAVE a
workgroup
file. (ms-access WILL NOT START if you don't). Further, when you run
ms-access you ALWAYS MUST HAVE a user name. That default user name is
"admin". If the workgroup user password for admin is blank, then that is
the
reason WHY you are not getting a logon prompt.

One more item:
Function faq_DisableShiftKeyBypass(strDBName as String, fAllow as
Boolean)
As Boolean
From:


http://support.microsoft.com/default...2F secfaq.asp

It says it can be run from the Immediate Window.

Presume I place the function in a module and then type:
faq_DisableShiftKeyBypass
Then hit the Enter key.

Yes, the function obviously requites you to enter the name. Note

Function faq_DisableShiftKeyBypass(strDBName as String, fAllow as
Boolean)

Look at the above....it needs two parameters.

Note that if you put the code in side of a database, then obviously it
is
only going to be of "use" ONLY the next time launch the database.
(since
you are already in). So, if you lock yourself out, then you need some
"door"
(a special key, or hidden button, or something that you do to un-shift
the
application). If you don't want to use the trap door, then grab my
sample,
as it lets you "browse" to a given file, and change the setting. It uses
the
above code.


There must be a way to block design changes in forms and reports, know
that
because I've seen it. Have yet to find a way to repeat it. Maybe
this
"Kid" created his own code.
Don't know that. Do know this; I will learn how to do it again.

Since you *can* import forms, then it can't be a mde file. (if you make
a
mde, then forms + reports don't import). So, logically, then it means
that
security was used on this file..........

If you read the security document (found here)

http://www.mvps.org/access/resources/techpapers.htm

It does explain how to setup security, and not requite a user to
logon....

Read the above.

If you open up user security settings, you should be able to see the
permsisons set for those forms.

Regardless, read the secrty faq. there is both a on-line, and
downloadable
links can be found in the above...

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

http://www.members.shaw.ca/AlbertKallal