MDE question for MVP's

[Rick]

A contractor wrote an Access 97 application years ago, delivered as an MDE,
and took the source to parts unknown. The people using it are running it
on old equipment with less than 1 GB of memory. It works there, but drools
and twitches on any mahine above 1 GB. I know that Jet 3.5 and below will
not run about 1 GB, but the software installed on all these machine is SR-2
with the Jet fix, and regular MDB's work fine.

Here's the question: Does the attributes of the version that was used to
create the MDE *travel* with the it? I.e., is Jet instantiated into the DB
and run from there?

Thanks for any help you can provide!

 

[Larry Linson]

Answer to your question: No, Jet is not included in the MDE, but the MDE
itself may have idiosyncracies introduced by the Access version with which
it was created. (Frankly, however, I don't see why any answer to this
question would be helpful -- don't you really want to know "what can I do to
make this database run on equipment with more than 1 GB of memory?")

I believe there have been discussions here in this newsgroup and in the
USENET newsgroup comp.databases.ms-access about (1) third-party software
that will re-create an MDB from an MDE and (2) ways you can copy everything
but the code, and then all you have to do is figure out what the VBA code is
doing and recreate the code. In comp.databases.ms-access, our long-time
colleague and contributor to that newsgroup has discussed the issue.

My view is that, typically, an experienced Access developer can observe a
database running and, can then re-create a database to do the same function
in far less time than it took the original author -- because applying Access
to the business problem is a major factor in original development, and that
has already been done.

On the other hand, two simple approaches are (1) locate the contractor and
see if he/she has a copy of the MDB, and negotiate a price to use it, or (2)
locate the third-party software and determine if it will work for you.
Either of these is likely to be less expensive, and less frustrating, than
the alternative of either re-creating or hiring someone to re-create the
database.

Larry Linson
Microsoft Office Access MVP

 

[Tony Toews [MVP]]

A contractor wrote an Access 97 application years ago, delivered as an MDE,
and took the source to parts unknown. The people using it are running it
on old equipment with less than 1 GB of memory. It works there, but drools
and twitches on any mahine above 1 GB. I know that Jet 3.5 and below will
not run about 1 GB, but the software installed on all these machine is SR-2
with the Jet fix, and regular MDB's work fine.

Here's the question: Does the attributes of the version that was used to
create the MDE *travel* with the it? I.e., is Jet instantiated into the DB
and run from there?

I would've thought that if an A97 MDB works on a machine with > 1 Gb
then an MDE should as well.

What's the message you're getting from the MDE?

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/

 

[Rick]

I would've thought that if an A97 MDB works on a machine with > 1 Gb
then an MDE should as well.

What's the message you're getting from the MDE?

Tony

You'd think. Like I said, other apps work fine.

Wd don't get a message, such as 'out of memory', but a lock-up. He created
a tab control with about six tabs on it. The main one is a datascreen and
it just flashes an hour glass upon loading and never finishes. You can
actually navigate to the other tabs, but they all have "#error" in all
fields. It's in some sort of infinite loop trying to load data.

 

[Rick]

Answer to your question: No, Jet is not included in the MDE, but the
MDE itself may have idiosyncracies introduced by the Access version
with which it was created. (Frankly, however, I don't see why any
answer to this question would be helpful -- don't you really want to
know "what can I do to make this database run on equipment with more
than 1 GB of memory?")

I believe there have been discussions here in this newsgroup and in
the USENET newsgroup comp.databases.ms-access about (1) third-party
software that will re-create an MDB from an MDE and (2) ways you can
copy everything but the code, and then all you have to do is figure
out what the VBA code is doing and recreate the code. In
comp.databases.ms-access, our long-time colleague and contributor to
that newsgroup has discussed the issue.

My view is that, typically, an experienced Access developer can
observe a database running and, can then re-create a database to do
the same function in far less time than it took the original author --
because applying Access to the business problem is a major factor in
original development, and that has already been done.

On the other hand, two simple approaches are (1) locate the contractor
and see if he/she has a copy of the MDB, and negotiate a price to use
it, or (2) locate the third-party software and determine if it will
work for you. Either of these is likely to be less expensive, and less
frustrating, than the alternative of either re-creating or hiring
someone to re-create the database.

Larry Linson
Microsoft Office Access MVP

This little piece of heaven has popped into my work queue four or five
times in the last year. Yes, making it work is the question, but I'm also
trying to figure out the parameters of how it can run so the 50 people who
want to run it, can do so until we can replace it.

The contractor left the organization probably seven years ago. (This is
county government and the person in charge of the original project made a
foolish decison not to include the source in the contract.) We tried
several times to locate the source.

We looked for an "uncompiler" several times and never found one that
actually works. The most promising was a company in the UK, but they
stopped communicating for some reason.

In the meeting we had with the customer yesterday, I told them I would try
to find them a workaround until we can rewrite the system. With resources
extremely tight right now, it might be a while. (Project planning and
spproval, business cases, yada yada.)

When your working with a county government that interfaces with city, state
and federal agencies, nothing is simple. This actually processes files
that come from a state system written 25 years ago in COBOL.

 

[david]

Always check to see if it really is an MDE...Not just a renamed MDB.

Is it actually an A95 MDE? That would account for the flakyness.

Also, you can check the references from a script while the application is
open,

set obj = getobject(..)
msgbox obj.references(1).name & obj.references(1).major

-- not that it will do you any good unless you find some component
that needs updating

(david)

 

[David W. Fenton]

Does the attributes of the version that was used to
create the MDE *travel* with the it? I.e., is Jet instantiated
into the DB and run from there?

Jet has *nothing* to do with an MDE. The point of an MDE is to strip
out the VBA canonical code and leave only the p-code. This is not a
Jet issue at all.

However, the p-code is entirely dependent on the version of Access
in which it was compiled (not Jet, but *Access*), because each
version of Access (even service releases and patches within a single
version of Access) has different VBA subsystems underlying it, to
which the p-code is irrevocably tied. This is why MDEs are not as
cross-compatible as MDBs, because the MDBs have the canonical code
in them and can be recompiled on the fly for a different version of
VBA.

It sounds to me like you're hosed. Without the original MDB, you're
going to have to completely recreate the app from scratch. In terms
of user interface, this oughtn't be all that difficult for an
intermediate Access developer. If there's any special
code/algorithms, it can be a lot more complicated, but I suspect
that the number of apps is pretty small where there would be complex
programming and the programmer is unprofessional enough not to
provide the source MDB. In other words, the level of complexity that
would make it hard to recreate would likely be the hallmark of a
competent professional developer, who would be very unlikely to fail
to provide the MDB.

On the other hand, if the client was provided with it and lost it,
it might be time to dig back into those old backup tape archives.

 

[David W. Fenton]

The contractor left the organization probably seven years ago.
(This is county government and the person in charge of the
original project made a foolish decison not to include the source
in the contract.) We tried several times to locate the source.

FWIW, it's not just a mistake on the part of the manager -- the
developer was an asshole for not providing the MDB as a matter of
course. Unprofessional, at the very least.

 

[David W. Fenton]

In the meeting we had with the customer yesterday, I told them I
would try to find them a workaround until we can rewrite the
system. With resources extremely tight right now, it might be a
while.

Have you worked with the compatibility options that are part of the
properties of shortcuts from Win2K on? These might allow you to make
adjustments so that the app thinks it's running in some earlier
version of Windows, which might make it work.

 

[Tony Toews [MVP]]

We looked for an "uncompiler" several times and never found one that
actually works. The most promising was a company in the UK, but they
stopped communicating for some reason.

MDE to MDB Conversion Service for Microsoft® Access
http://www.everythingaccess.com/mdeconversion.htm

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/