I am working on a database that I will developing while it's being
used. There are things I'd like to do to keep users out of areas they
shouldn't be in (such as disabling autoexec bypass, hiding the database
window, toolbars, etc.), but when I'm working on a database and
frequently saving it as an in-production mde, these things can be an
inconvenience for me. I keep the mdb on my local computer, then save
an mde of it to a shared network folder (which then gets copied
automatically to individual workstations by Tony Toews' Auto FE
Updater). I wanted to be able to update the whole process, so I could
have a hidden button that would programmatically set all these
attributes, save it as an mde, then switch them back in my mdb. But it
seems that the automated way of saving an mde can't be used on the
current database. Is there a command to determine whether or not the
current db is an mde vs. an mdb? Perhaps I could use that to set these
attributes, since I'm the only one who will be working in the mdb.

Anyone have any tips they want to share in making this a little easier?

Thanks!

No doubt you already have code that performs the "lock down" functions
you require. Conditionally check to see what type of file is running
and enable or disable your features as required.
Is there a command to determine whether or not the current db is an mde
vs. an mdb?

Select Case Right(CurrentProject.Name, 3)
Case "mdb"
MsgBox CurrentProject.Name & " is editable."
Case "mde"
MsgBox CurrentProject.Name & " is not editable."
Case Else
MsgBox CurrentProject.Name & " does not meet naming conventions."
End Select

You most certainly can, and should hide all of the ms-access interface. The
options to complete hide and keep people out of the ms-access interface can
easily be done using the tools->start-up options. Using those options allows
you to complete hide the ms-access interface (tool bars, database window
etc). Also, using these options means you do not have to bother setting up
security.

Try downloading and running the 3rd example at my following web site that
shows a hidden ms-access interface, and NO CODE is required to do
this....but just some settings in the start-up.

Check out:

http://www.members.shaw.ca/AlbertKal...s/DownLoad.htm

After you try the application, you can exit, and then re-load the
application, but hold down the shift key to by-pass the start-up options. If
want, you can even disable the shift key by pass. I have a sample mdb file
that will let you "set" the shift key bypass on any application you want.
You can get this at:

http://www.members.shaw.ca/AlbertKal.../msaccess.html

Of course, during development, you will hold down the shift key so your
startup settings don't run. You then develop for awhile, and then to test in
"user" mode, you exit..and then re-enter the application without the shift
key bypassed. You will likely do this dance all day long as you run/test as
user mode, and then flip back in to developer mode (shift key used..so you
don't get the main custom menu). So, you can't develop, or really modify
things when you run your application with the startup settings...so you must
shift-by-pass them when you want to work.

And, in fact, I use alt-f4 to exit the application...the mdb file should
still
be highlighted in the windows explore..so, then you hit enter key (and, hold
down shift key if you need be). This key stroke sequence and exiting and
re-entering the application will occur CONSTANTLY all day long when you
are developing. When you finally have things just right...you create the mde
you plan to distribute...




--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
(E-Mail Removed)
http://www.members.shaw.ca/AlbertKallal

Or, how about this?

Function IsMDE() As Boolean
Dim strMDE As String

On Error Resume Next
strMDE = CurrentDb.Properties("MDE")

If Err = 0 And strMDE = "T" Then
' This is an MDE database.
IsMDE = True
Else
IsMDE = False
End If

End Function



Tom

http://www.access.qbuilt.com/html/ex...tributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________


"Anton" wrote:

> No doubt you already have code that performs the "lock down" functions
> you require. Conditionally check to see what type of file is running
> and enable or disable your features as required.
> Is there a command to determine whether or not the current db is an mde
> vs. an mdb?
>
> Select Case Right(CurrentProject.Name, 3)
> Case "mdb"
> MsgBox CurrentProject.Name & " is editable."
> Case "mde"
> MsgBox CurrentProject.Name & " is not editable."
> Case Else
> MsgBox CurrentProject.Name & " does not meet naming conventions."
> End Select
>
>

You REALLY should not allow your users to have access to anything but
an MDE version. Here is how we control access to forbidden features
in the MDE:

ChangeProperty "StartupShowDBWindow", dbBoolean, False
ChangeProperty "StartupShowStatusBar", dbBoolean, True
ChangeProperty "AllowBuiltinToolbars", dbBoolean, False
ChangeProperty "AllowFullMenus", dbBoolean, False
ChangeProperty "AllowBreakIntoCode", dbBoolean, False
ChangeProperty "AllowSpecialKeys", dbBoolean, False
ChangeProperty "StartupShowDBWindow", dbBoolean, False
ChangeProperty "AllowShortcutMenus", dbBoolean, False

' Change this one to false just prior to MDE creation:
ChangeProperty "AllowBypassKey", dbBoolean, True

Here is the "ChangeProperty" Sub:

Function ChangeProperty(strPropName As String, varPropType As Variant,
_
varPropValue As Variant) As Integer
Dim dbs As Database
Dim prp As Property
Const conPropNotFoundError = 3270

Set dbs = CurrentDb
On Error GoTo Change_Err
dbs.Properties(strPropName) = varPropValue
ChangeProperty = True

Change_Bye:
Exit Function

Change_Err:
If Err = conPropNotFoundError Then ' Property not
found.
Set prp = dbs.CreateProperty(strPropName, _
varPropType, varPropValue, True)
dbs.Properties.Append prp
Resume Next
Else
' Unknown error.
ChangeProperty = False
Resume Change_Bye
End If
End Function

If you do the above in a basGlobal module, you users will not have
access to any of the forbidden objects.




On 20 Feb 2006 09:01:05 -0800, (E-Mail Removed) wrote:

>I am working on a database that I will developing while it's being
>used. There are things I'd like to do to keep users out of areas they
>shouldn't be in (such as disabling autoexec bypass, hiding the database
>window, toolbars, etc.), but when I'm working on a database and
>frequently saving it as an in-production mde, these things can be an
>inconvenience for me. I keep the mdb on my local computer, then save
>an mde of it to a shared network folder (which then gets copied
>automatically to individual workstations by Tony Toews' Auto FE
>Updater). I wanted to be able to update the whole process, so I could
>have a hidden button that would programmatically set all these
>attributes, save it as an mde, then switch them back in my mdb. But it
>seems that the automated way of saving an mde can't be used on the
>current database. Is there a command to determine whether or not the
>current db is an mde vs. an mdb? Perhaps I could use that to set these
>attributes, since I'm the only one who will be working in the mdb.
>
>Anyone have any tips they want to share in making this a little easier?
>
>Thanks!

Perhaps, it's worthwhile for others reading this thread to know that
there are those of us who do not in any way protect our applications
(not to be confused with protecting data).
I am one of those, always delivering a simple MDB file (once, once too
many actually, an ADP) with all code and objects visible and editable.
I have never had a problem as a result of this. I've toyed with the
idea of password protecting VBA projects but have yet to do so.
Why have I not had problems? I guess because the people with whom I do
business are honest and intelligent.
A couple of times IT has lost the application, and once removed all the
ISAMs. They were happy to pay my standard rate for recovery.
My basic contract generally restricts the client from making the
application available beyond his or her organization, but otherwise
gives him/her complete ownership, in so much as it does not restrict me
from using any part of the application in any way.
I never worry about being cheated; and I rarely am.

On 21 Feb 2006 21:09:43 -0800, "Lyle Fairfield"
<(E-Mail Removed)> wrote:

>Perhaps, it's worthwhile for others reading this thread to know that
>there are those of us who do not in any way protect our applications
>(not to be confused with protecting data).
>I am one of those, always delivering a simple MDB file (once, once too
>many actually, an ADP) with all code and objects visible and editable.
>I have never had a problem as a result of this. I've toyed with the
>idea of password protecting VBA projects but have yet to do so.
>Why have I not had problems? I guess because the people with whom I do
>business are honest and intelligent.

With "intelligent" being the pivotal issue. If you distribute ANY
application to the general public, one cannot depend on the honesty OR
intelligence of those who receive it. In a corporate setting, where
you know your users, and they all work in a structured, hierarchical
setting, exposing the MDB is usually safe. I did it for many years in
the corporate world and never had a problem because all users knew
that they were not to tamper with the objects and were loathe to do so
on fear of management reprisal. If you are non-employee, contracted
to deliver a corporate setting app, they SHOULD have the MDB because,
often, they literally OWN the code.

>A couple of times IT has lost the application, and once removed all the
>ISAMs. They were happy to pay my standard rate for recovery.
>My basic contract generally restricts the client from making the
>application available beyond his or her organization, but otherwise
>gives him/her complete ownership, in so much as it does not restrict me
>from using any part of the application in any way.
>I never worry about being cheated; and I rarely am.

Lauren Wilson wrote:
> On 21 Feb 2006 21:09:43 -0800, "Lyle Fairfield"
> <(E-Mail Removed)> wrote:
>
>> Perhaps, it's worthwhile for others reading this thread to know that
>> there are those of us who do not in any way protect our applications
>> (not to be confused with protecting data).
>> I am one of those, always delivering a simple MDB file (once, once
>> too many actually, an ADP) with all code and objects visible and
>> editable. I have never had a problem as a result of this. I've toyed
>> with the idea of password protecting VBA projects but have yet to do
>> so.
>> Why have I not had problems? I guess because the people with whom I
>> do business are honest and intelligent.
>
> With "intelligent" being the pivotal issue. If you distribute ANY
> application to the general public, one cannot depend on the honesty OR
> intelligence of those who receive it. In a corporate setting, where
> you know your users, and they all work in a structured, hierarchical
> setting, exposing the MDB is usually safe. I did it for many years in
> the corporate world and never had a problem because all users knew
> that they were not to tamper with the objects and were loathe to do so
> on fear of management reprisal. If you are non-employee, contracted
> to deliver a corporate setting app, they SHOULD have the MDB because,
> often, they literally OWN the code.
>
>> A couple of times IT has lost the application, and once removed all
>> the ISAMs. They were happy to pay my standard rate for recovery.
>> My basic contract generally restricts the client from making the
>> application available beyond his or her organization, but otherwise
>> gives him/her complete ownership, in so much as it does not restrict
>> me from using any part of the application in any way.
>> I never worry about being cheated; and I rarely am.

I've been brought in to recover internal apps that have been fiddled with..
a little knowledge is dangerous The most common thing is for users to
start adding their own reports... which only rarely works out.
--
regards,

Br@dley

Br@dley wrote:
>
> I've been brought in to recover internal apps that have been fiddled
> with.. a little knowledge is dangerous The most common thing is
> for users to start adding their own reports... which only rarely
> works out.

Exactly. I don't distribute MDEs to protect myself or my code. I do it to
protect users from themselves. To the extent that it benefits me it is strictly
in the reduction of tech support calls.

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

On Wed, 22 Feb 2006 12:25:18 GMT, "Rick Brandt"
<(E-Mail Removed)> wrote:

>Br@dley wrote:
>>
>> I've been brought in to recover internal apps that have been fiddled
>> with.. a little knowledge is dangerous The most common thing is
>> for users to start adding their own reports... which only rarely
>> works out.
>
>Exactly. I don't distribute MDEs to protect myself or my code. I do it to
>protect users from themselves. To the extent that it benefits me it is strictly
>in the reduction of tech support calls.

Precisely!