MDE question

[SQLdba]

Can someone explain to me the benefit of an MDE.

It looks to me like it's a one way street: Develop an app, release it,
never do anything with it again. You can't even get the data out for an
upgrade...

Thanks to all.
--

 

[B_A_R_T_M_A_N]

Biggest one is to make it hard for someone to steal your code or
program. The code is not included in an mde, whereas an mdb is easy
to get into and also allow the User to modify/copy.

 

[Dirk Goldgar]

In

Can someone explain to me the benefit of an MDE.

It looks to me like it's a one way street: Develop an app, release
it, never do anything with it again. You can't even get the data out
for an upgrade...

I don't know what you mean by that last sentence. Sure you can get the
data out of an MDE -- the tables aren't protected in any special way,
unless you've chosen to do so via user-level security. It's the source
code and design elements that are stripped out of an MDE.

 

[Tony Toews [MVP]]

Can someone explain to me the benefit of an MDE.

It looks to me like it's a one way street: Develop an app, release it,
never do anything with it again. You can't even get the data out for an
upgrade...

As stated the users can't update the forms, reports or VBA code.

You must retain the MDB to make any changes in the future and then
send out the new MDE again.

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

 

[Albert D. Kallal]

Can someone explain to me the benefit of an MDE.

It looks to me like it's a one way street: Develop an app, release it,
never do anything with it again. You can't even get the data out for an
upgrade...

the above is correct. The problem is that you not thinking as a developer.
To effective use a mde, even for single user clients, you must use a split
database. Else, how do you expect to deploy new updates, and bug fixes to
your deployed applications?

So, read the following article..and it will all make sense....

http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm

You can easily update your clients applications using a mde..but, you have
to think like a developer to be able to accomplish this...

 

['69 Camaro]

Hi.

You can't even get the data out for an
upgrade...

If you mean that you're trying to upgrade the MDE database file to a newer
version of Access, then no, one cannot upgrade the application objects, but
the database objects can be upgraded into a newer version database file.
You should have a split database file, with the back end containing the
tables and relationships, and the front end containing the forms, queries,
reports, modules, and macros. The front end can remain in the MDE database
format, while the back end should be in an MDB database format. The back
end can easily be converted to a newer version database format, as long as
it doesn't have User-Level Security applied. Otherwise, it's best to remove
the security, then upgrade, then reapply the security to the new version.

Of course, the old MDE front end won't be able to access the newer version
back end unless the version of Access installed on the computer can
accommodate it. In other words, if the back end is upgraded from Access
2000 database format to Access 2002-2003 database format, only Access 2002
and 2003 users will be able to connect to the database back end. The Access
2000 users will receive an "Unrecognized database format" error when trying
to connect to the back end, even though the front end MDE opens just fine
for them. (This assumes that the front end is an Access 2000 MDE database
file.)

However, if you mean that you're trying to upsize the MDE database file to
SQL Server, then one cannot use the "Create a new Access client/server
application" option, because the Upsizing Wizard requires access to objects
that were removed during the conversion to the MDE database format. In this
case, upsize the MDB file that the MDE database file was created from.

One must choose either the "No application changes" or else the "Link SQL
Server tables to an existing application" options when upsizing an MDE
database file. If you intend to create a client/server architecture from
this database file, then you must upsize the original MDB file, not the MDE
database file. In other words, it should have already been split into a
front end and back end, where you're upsizing the back end MDB file, not the
front end MDE database file.

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com
http://www.Access.QBuilt.com/html/expert_contributors2.html for contact
info.

 

[David W. Fenton]

In

I don't know what you mean by that last sentence. Sure you can
get the data out of an MDE -- the tables aren't protected in any
special way, unless you've chosen to do so via user-level
security. It's the source code and design elements that are
stripped out of an MDE.

Dirk has obviously not absorbed what an MDE is. It affects only
code-bearing objects, because all it does is strip out the VBA code
and leave the compiled code. Any object type that doesn't have code
modules is still going to be editable.

And because every app except the most trivial single-user app should
be split, your data tables should never be in an MDE, anyway (though
you might haves some static tables for lookups and meta information
in your front end).

 

[Douglas J. Steele]

Dirk has obviously not absorbed what an MDE is. It affects only
code-bearing objects, because all it does is strip out the VBA code
and leave the compiled code. Any object type that doesn't have code
modules is still going to be editable.

Strikes me that Dirk's reply indicates that he's fulling aware of what an
MDE is. He says "you can get the data out of an MDE".

And because every app except the most trivial single-user app should
be split, your data tables should never be in an MDE, anyway (though
you might haves some static tables for lookups and meta information
in your front end).

No argument on this point! <g>

 

[David W. Fenton]

Strikes me that Dirk's reply indicates that he's fulling aware of
what an MDE is. He says "you can get the data out of an MDE".

You're right -- I picked up the wrong attribution, and meant the
comment about Burt King, instead.