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_Variables, where
I declare most of my app level variables and constants, I might have
something like:

Public Const cConnect = "ODBC;DSN=ABC;UID=ABCR;PWD=something_sensitive "

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_whatever (ID_PK, ID, NAME) Values (123,
'Ooga booga')"

Set qd = dbs.createquerydef("")
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****@PurplePandaChasers.Moertheriumwrote 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********@yahoo.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

[Bob Alston]

Tim Marshall wrote:

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.

Perhaps if you stored it embedded in a larger string and then extracted
it. Or perhaps embed in the string in two or more pieces and combine
them at run time.

Bob

[David W. Fenton]

Tim Marshall <TI****@PurplePandaChasers.Moertheriumwrote in
news:ec**********@coranto.ucs.mun.ca:

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.

Surely it isn't there if you encrypt your MDB source?

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

[Tim Marshall]

David W. Fenton wrote:

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

Oh well, back to the drawing board.

Surely it isn't there if you encrypt your MDB source?

To be honest, I've never considered encryption as I didn't think I
needed it so I don't know how it works. I must read up on it.

Does it slow an app down?
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[Bri]

Tim Marshall wrote:

David W. Fenton wrote:

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

Oh well, back to the drawing board.

Surely it isn't there if you encrypt your MDB source?

To be honest, I've never considered encryption as I didn't think I
needed it so I don't know how it works. I must read up on it.

Does it slow an app down?

Its easy to use, Tools - Security - Encrypt/Decrypt Database.

I haven't noticed any decrease in speed from it. Today's PCs bairly
notice that extra processing. What it does do is make the mdb
non-compressable. So if you are distributing it via some method that
benefits from a smaller compressed file (in a ZIP file for example) then
you won't get any compression. In most cases this isn't even an issue.

--
Bri

[Tim Marshall]

Bri wrote:

>Does it slow an app down?

Its easy to use, Tools - Security - Encrypt/Decrypt Database.

I haven't noticed any decrease in speed from it. Today's PCs bairly

Thanks, Bri.
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[Earthlink news]

"Bob Alston" <bo********@yahoo.comwrote in message
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?

I personally prefer distributing an .mdb because I've noticed problems with
mdes when businesses have had different versions of Access on different
machines in their office.

Back five years ago, it wasn't a problem at all, but for some reason, which
I haven't bothered to track down, I have had real probles with use .mde
files lately.

I have a personal relationship with my clients, and if there is an error, I
like being able to either look at it, or talk to them over the phone, and
debug it on the spot.

If you are working in a bigger shop, where you can put more resources into
QA, this is less of an issue.

I'm also not too concerned about someone pinching my code, or screwing up by
work, although in the past, when those have been issues, I used .mdes.

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?

I've never tried it by changing the report definitions, I've only ever used
the report specs as arguments to queries and variables, and it works fine.

I've never tried creating and deleting or hiding and showing different
sections of a report in an .mde file, though. Don't know if that would
work.