Is it considered best practice to distribute FE databases as MDEsrather than MDBs?

[Bob Alston]

Is it considered best practice to distribute FE databases as MDEs rather
than MDBs? Without flaming me for asking the question, could someone
please enumerate the key advantages?

Also I like to provide my users a mini report writer where the report
specs are stored as local data files. Can I do this in an MDE - e.g.
have local data files for the report writer spec but no queries, forms
or report changes?

Thanks.

Bob

[Rick Brandt]

Bob Alston wrote:

Is it considered best practice to distribute FE databases as MDEs
rather than MDBs? Without flaming me for asking the question, could
someone please enumerate the key advantages?

Also I like to provide my users a mini report writer where the report
specs are stored as local data files. Can I do this in an MDE - e.g.
have local data files for the report writer spec but no queries, forms
or report changes?

An MDE prevents a user form altering the design of code based objects where
they would more than likely mess them up.

In some cases you might have data inside your code that you do not want
users to see. An MDE prevents that.

An MDE is generally smaller and since it is always 100% compiled will
perform a bit better than an MDB.

Untrapped errors will cause all public variables to lose their values in an
MDB. That doesn't happen in an MDE.

If your "writer specs" are stored in a table then an MDE will still store
them. I have no idea what you do with your "specs" so beyond storing them
in a table I can't say whether an MDE will break that process. If you use
them to apply on-the-fly changes to existing reports then an MDE can still
do that. If you use them to actually create new reports then no, an MDE
will not allow that.
--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

[Tim Marshall]

Rick Brandt wrote:

In some cases you might have data inside your code that you do not want
users to see. An MDE prevents that.

A prime example of this for me would be in the storing of a connect
string with a sensitive password, such as what I use for Oracle connections.

For example, in a standard module called Mod_Constants_V ariables, where
I declare most of my app level variables and constants, I might have
something like:

Public Const cConnect = "ODBC;DSN=ABC;U ID=ABCR;PWD=som ething_sensitiv e"

Tthis connect string would be used with temporary querydefs, air code
example:

dim Qd as Dao.querydef
dim strSql as string

strsql = "insert into ABC.tbl_whateve r (ID_PK, ID, NAME) Values (123,
'Ooga booga')"

Set qd = dbs.createquery def("")
with qd
.connect = cConnect
.sql = strsql
.returnsrecords = false
.execute dbfailonerror
.close
end with

Using an mde allows me to forever keep the password secret from the user.
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[Bob Alston]

Bob Alston wrote:

Is it considered best practice to distribute FE databases as MDEs rather
than MDBs? Without flaming me for asking the question, could someone
please enumerate the key advantages?

Also I like to provide my users a mini report writer where the report
specs are stored as local data files. Can I do this in an MDE - e.g.
have local data files for the report writer spec but no queries, forms
or report changes?

Thanks.

Bob

Are MDE files more reliable and less likely to corruption than MDBs?

Bob

[Albert D. Kallal]

>Bob

Are MDE files more reliable and less likely to corruption than MDBs?

Yes, I would say they are more relabley. They are for sure compiled, and
cannot become un-compiled. I had some forms in ms-access where I open them,
and then I am asked to save them (and, not changed anything). This problem
is useally due to some compile issue (or lack of).

Furhter, since you can't build a mde with compile errors, then it really is
a nice last minuite check for you anyway.

So, they are somewhat smaller, tend to run a bit faster (and, actually a lot
faster if the mdb is not compiled). This also reduces bloat somewhat.

[Albert D. Kallal]

>Bob

Are MDE files more reliable and less likely to corruption than MDBs?

Yes, I would say they are more reliable. They are for sure compiled, and
cannot become un-compiled. I had some forms in ms-access where I open them,
and then I am asked to save them (and, not changed anything). This problem
is usually due to some compile issue (or lack of).

Further, since you can't build a mde with compile errors, then it really is
a nice last minute check for you anyway.

So, they are somewhat smaller, tend to run a bit faster (and, actually a lot
faster if the mdb is not compiled). This also reduces bloat somewhat.

I can't really say they are more reliable, but then I never taken the risk
to distribute a mdb.

The fact that users can't accident modify the application would likely be
reason enough. When you add up issue additional issue (it is compiled, it
is smaller, can't be modified...etc etc etc), then it just becomes a really
good all around practice.

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl************* ****@msn.com

[David W. Fenton]

Tim Marshall <TI****@PurpleP andaChasers.Moe rtheriumwrote in
news:ec******** **@coranto.ucs. mun.ca:

A prime example of this for me would be in the storing of a
connect string with a sensitive password, such as what I use for
Oracle connections.

Unless your MDE is encrypted, I think you should be able to view the
password with a file viewer, since constants must be compiled into
the code directly.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

Bob Alston <bo********@yah oo.comwrote in
news:16******** *****@newsfe03. lga:

Is it considered best practice to distribute FE databases as MDEs
rather than MDBs? Without flaming me for asking the question,
could someone please enumerate the key advantages?

Also I like to provide my users a mini report writer where the
report specs are stored as local data files. Can I do this in an
MDE - e.g. have local data files for the report writer spec but no
queries, forms or report changes?

You've had the answers.

I don't distribute MDEs, myself, because it finder it easier to fix
errors that pop up at runtime when I can walk the user through
editing/adding a line of code, rather than needing to send them a
new MDE.

That said, I have distributed MDEs in secured apps, but don't have
any of those in production use these days.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Tim Marshall]

David W. Fenton wrote:

>>A prime example of this for me would be in the storing of a
connect string with a sensitive password, such as what I use for
Oracle connections.

Unless your MDE is encrypted, I think you should be able to view the
password with a file viewer, since constants must be compiled into
the code directly.

Good point! I must check that. The mde is still good for most users in
my environment, but I think you're right for someone with a little more
knowledge.

I'll try it and get back...
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[Tim Marshall]

Tim Marshall wrote:

Good point! I must check that. The mde is still good for most users in
my environment, but I think you're right for someone with a little more
knowledge.

I'll try it and get back...

Yup, there is is!!!! 8( I just used MS Write, too.

Oh well, back to the drawing board.
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me