Question about .MDE file

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

azu_daioh@yahoo.com - 28 Mar 2007 23:17 GMT

I'm trying to figure out if creating an MDE file is advisable in this
scenario:

Our database contains records from 2002-current (about 10,000 records
right now) If I save a MDE file of this database, how would I be able
to convert it back to MDB to change the design layout?

If I cannot convert the MDE back to MDB, how do I make design changes
in the MDE file?

And if I have to use the original MDB to make design changes then save
it as another MDE file -- what would be the easier approach to
transfer the 'new' records that were added in the first MDE file?

My problem is I cannot use the backend and frontend environment at
work -- for some reason, I keep getting complaints that this method is
tooo slow for our network. So, we changed it back to just sharing 1
mdb file located centrally. I know the MDE file works best in b/e and
f/e.

Thank you,
Sharon

Reply to this Message

ruralguy - 29 Mar 2007 00:43 GMT

Sharon,

You can NEVER loose the mdb file! It is the *only* way to make changes. An
mde deletes all of the source code in the file and just leaves the compiled
code. It is GONE from the mde and can not be recovered. Does that help in
your decision process? Here's some suggestions on performance:
http://www.granite.ab.ca/access/performancefaq.htm

I suspect strongly that you can achieve very good performance on you network
with a BE/FE Application.

>I'm trying to figure out if creating an MDE file is advisable in this
>scenario:
[quoted text clipped - 18 lines]
>Thank you,
>Sharon

Signature

HTH - RuralGuy (RG for short) acXP WinXP Pro
Please post back to this forum so all may benefit.

Reply to this Message

Tony Toews [MVP] - 29 Mar 2007 00:45 GMT

There are a wide number of reasons why you want to split the MDB into
a FE and BE. And your problem is one of those.

>My problem is I cannot use the backend and frontend environment at
>work -- for some reason, I keep getting complaints that this method is
>tooo slow for our network.

The three most common performance problems in Access 2000 or newer
are:
- LDB locking which a persistent recordset connection or an always
open bound form corrects (multiple users)
- sub datasheet Name property set to [Auto] should be [None]
- Track name AutoCorrect should be off

If the problem is for everyone when starting up the MDB then it likely
needs a decompile.

For more information on these, less likely causes, other tips and
links to MS KB articles visit my Access Performance FAQ page at
http://www.granite.ab.ca/access/performancefaq.htm

Tony

Signature

Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

Reply to this Message

Albert D. Kallal - 29 Mar 2007 09:02 GMT

> I'm trying to figure out if creating an MDE file is advisable in this
> scenario:
[quoted text clipped - 5 lines]
> If I cannot convert the MDE back to MDB, how do I make design changes
> in the MDE file?

A great question. and,the answer is that you can't!!!

since you can't convert back to a mdb, then it is a one-way street.

> And if I have to use the original MDB to make design changes then save
> it as another MDE file -- what would be the easier approach to
> transfer the 'new' records that were added in the first MDE file?

You are 100% correct in the above. So, for your case, a mde does not
make a lot of sense.

> My problem is I cannot use the backend and frontend environment at
> work -- for some reason, I keep getting complaints that this method is
[quoted text clipped - 4 lines]
> Thank you,
> Sharon

There is a performance hit. Usually, it not too large. And, useally it
is the network more then that you split. In some cases, you find the split
actually does load some forms faster.

I have a good article
that explains the use of a mde (and splitting here). It is good read, and
not only "tells" you about splitting, but gives insight as to why this is
done.

You can find this article here (it a easy read):

Grab you coffie...and relax..and read away:
http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm

Signature

Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@msn.com

Reply to this Message