Splitting vs MDE

[Jake F]

I finished creating a database that will be used by many people. The
database is in 2002-2003 version but I run it from 2007 just because I've
gotten used to how 2007 operates. I was not able to make and MDE file in
2007 but was able to split the database using 2003. Will it be sufficient
enough to have my tables somewhere else or do I need to figure out an MDE
file so that my modules are blocked as well? Let me know if I'm way off base
here. Thanks.

 

[Klatuu]

In a multi user environment, splitting is an absolute must.
Using an mde would be best, but the file version and the Access version have
to be the same before you can create an mde. In 2007 it is an accde.

Why not just convert everything to 2007?
Are you aware the 2007 Developer's extensions can be downloaded from
Microsoft free? That gives you the ability to create an accde and deliver
the 2007 runtime if you have users that don't have 2007.

 

[John W. Vinson]

I finished creating a database that will be used by many people. The
database is in 2002-2003 version but I run it from 2007 just because I've
gotten used to how 2007 operates. I was not able to make and MDE file in
2007 but was able to split the database using 2003. Will it be sufficient
enough to have my tables somewhere else or do I need to figure out an MDE
file so that my modules are blocked as well? Let me know if I'm way off base
here. Thanks.

Only the frontend will contain any modules (likewise macros, forms, queries
and reports). The backend will contain only the tables, so there's nothing to
block. It can be a .mdb; there's no advantage to making it a .mde.

 

[Tony Toews [MVP]]

I finished creating a database that will be used by many people. The
database is in 2002-2003 version but I run it from 2007 just because I've
gotten used to how 2007 operates. I was not able to make and MDE file in
2007

You will have to convert the MDB into A2007 format before you can make
it an MDE in A2007. However this means that your users will have to
have either A2007 or A2007 runtime installed. They won't be able to
run an A2007 MDE in A2003 or older.

Alternatively you could wander over to a users system with A2003 and
make your MDE there. Then both A2003 and A2007 users could run it.

Tony
--
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
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Jake F]

Thanks to everyone for the help. Most of my users will have A2003 and if
they have to download something it might make more of a problem for me
because they'll be weary of downloading rules. I'll give making an mde in
A2003 a shot and see what happens there. Will that allow multiple users to
access the mde file at the same time from a network drive, or will they need
to have the MDE on their computer and I send them updates from time to time?

 

[John W. Vinson]

will they need
to have the MDE on their computer and I send them updates from time to time?

That's the preferred approach. If you go to Tony's website you can find a good
review of the process:

http://www.granite.ab.ca/access/splitapp.htm

 

[David W. Fenton]

Only the frontend will contain any modules (likewise macros,
forms, queries and reports). The backend will contain only the
tables, so there's nothing to block. It can be a .mdb; there's no
advantage to making it a .mde.

Read the help file topic on what an MDE is, then you'll understand
that making an MDB with nothing but data tables in it is a complete
waste of time. An MDE is only relevant to code-bearing objects,
i.e,. forms/reports/modules.

 

[David W. Fenton]

I'll give making an mde in
A2003 a shot and see what happens there. Will that allow multiple
users to access the mde file at the same time from a network
drive, or will they need to have the MDE on their computer and I
send them updates from time to time?

You're confusing two completely orthogonal issues, i.e., splitting
and making an MDE.

They have NOTHING to do with each other.

On the subject of splitting:

Every Access application with more than one user should be split. NO
EXCEPTIONS.

Every Access application where the user needs to get updates to the
forms/reports from someone else should be split, even if it has only
one user. NO EXCEPTIONS.

Every replicated Access app should be split. NO EXCEPTIONS.

On the subject of MDE:

An MDE is only relevant to your front-end objects,
forms/reports/modules -- it has absolutely no effect on
non-code-bearing objects (tables/queries).

Thus, converting a back end to an MDE is a complete waste of time,
as there should be nothing in the back end that is altered one iota
by the conversion to MDE.

Making an MDE of a front end strips out the canonical VBA code and
leaves only the compiled version. This effectively secures your
programming from prying eyes.

It also makes your front end unalterable by the end users (or anyone
else).

As a side effect, your front end may run faster. It may bloat less.

It is also more resistent to code resets, since your in-memory
variables and structures are not erased.

In summary:

Notice that none of the items about MDEs have anything to do with
the items under splitting.

 

[BruceM]

I don't see in the help files that "making an MDB with nothing but data
tables in it is a complete waste of time", nor do I agree. Of course it
wouldn't be phrased like that in Help, but even so I do not see information
to that effect. If you meant "making an MDE with nothing but data tables in
it is a complete waste of time", isn't that what John was saying?

 

[BruceM]

I didn't mean to misquote John, who said "there's no advantage to making it
a .mde." I should have said something like: "Isn't that the effect of what
John was saying" or something like that.

I don't see in the help files that "making an MDB with nothing but data
tables in it is a complete waste of time", nor do I agree. Of course it
wouldn't be phrased like that in Help, but even so I do not see information
to that effect. If you meant "making an MDE with nothing but data tables
in it is a complete waste of time", isn't that what John was saying?

 

[David W. Fenton]

If you meant "making an MDE with nothing but data tables in
it is a complete waste of time", isn't that what John was saying?

Yes, I meant "MDE" -- I need to fire my typist.

John just said there's no advantage. I made a much stronger
statement, one which reflects my impatience with those who try to
use MDEs without first understanding what they are and what they are
useful for.

 

[John W. Vinson]

John just said there's no advantage. I made a much stronger
statement, one which reflects my impatience with those who try to
use MDEs without first understanding what they are and what they are
useful for.

Point taken... "no advantage" was indeed an understatement.

 

[Steve in MN]

So when you make an MDE file, the only way to "update" the front end is to
make changes in the original file and create a new MDE file?

 

[Arvin Meyer [MVP]]

Yes, that is correct. You can use an automatic updater like Tony Toew's
AutoFE to get the updates automatically:

http://www.granite.ab.ca/access/autofe.htm