I need to upgrade an application from Access 2.0 to Access 2003. The
application contains macros. When I upgrade the database or try to
import any macro into a 2003 database, Access crashes ("Microsoft
Office Access has encountered a problem and needs to close. We are
sorry for the inconvenience.").

I have several questions:

1. Is this the expected behavior? (i.e. Is Access 2003 known to be
unable to upgrade Access 2.0 macros?)

2. If Access 2003 is incapable of upgrading macros from Access 2.0, is
there some other (automated) way to do it?

3. If there is no way to upgrade the macros automatically, I will have
to recreate them manually. In order to do that, I need to read the
macros. I don't have Access 2.0. Is there any way to read Access 2.0
macros without using Access 2.0?

4. If I can't upgrade the macros automatically and if Access 2.0 is
required to view the macros, then I will need the help of someone who
owns Access 2.0. Can anyone suggest how I might find an individual or
a company who will document the macros for me so I can proceed with
the manual upgrade?


-TC

I've been itching to install win 3.1 on my new machine as another boot
option. I also have the retail box of A2.0.

I assume these are complex macros?

Access97 or Access95 if you can find a copy; should open Access 2.

"TC" <existential.philosophy (AT) gmail (DOT) com> wrote

"TC" wrote in message
news:1d0adc01-6c45-4a39-94cc-14a264a8a524 (AT) r28g2000prb (DOT) googlegroups.com...

I believe you should be able to import them. I cannot remember if 2.0 had
macros as opposed to older vba?

Do you have the 2.0 add in for 2003? there also one for 2007. The 2003
add-in to read+ open 2.0 files is here:

http://office.microsoft.com/en-us/ac...740.aspx?CTT=1


macros. I don't have Access 2.0. Is there any way to read Access 2.0
macros without using Access 2.0?

I think I would work on #2, and see if the add-in for 2003 works.

owns Access 2.0. Can anyone suggest how I might find an individual or
a company who will document the macros for me so I can proceed with
the manual upgrade?

Hum, I have a copy somewhere. I suggest that if you cannot get the 2.0 addin
to work with 2003 or 2007, then I would try Access 97, and see if it can
convert + upgrade. Finding 97 would be more easy, and I would attempt to 97
before I go the "manual" open and find someone with 2.0. So, make the 2.0
idea your last choice....


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
Pleasenospam_kallal (AT) msn (DOT) com

On Jul 22, 1:46*pm, "Albert D. Kallal" <PleaseNOOOsPAMmkal... (AT) msn (DOT) com>
wrote:

Ron, Christian, and Albert,

Thank you for the helpful replies.

I found a solution. I discovered that, even though Access 2003 crashes
when importing macros from 2.0, it seems to successfully import one
macro per crash. I used AutoHotkey (a keyboard automator) to open
Access, import one macro, recover from the crash, and repeat until all
macros were successfully imported. (There are more than 300 of them.)

Albert, I think you're right -- Access 2003 should be able to import
Access 2.0 macros; the crashing is probably the result of some quirk
on my system. (And yes, I do have the 2.0 converter.)


-TC


PS: Sadly, now that the application is functional, I can see what a
mess it is. Unless the client pays for a complete rewrite, there is no
way I'm going to touch this monster. Sigh...

On Fri, 22 Jul 2011 15:08:44 -0700 (PDT), TC
<existential.philosophy (AT) gmail (DOT) com> wrote:

Now that's understandable.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

"TC" <existential.philosophy (AT) gmail (DOT) com> wrote

Hmm. Sounds the same as several projects that recruiters and contract
brokers tried to persuade me to take on (often they would have liked a
fixed-fee): "Shouldn't take more than two weeks, it's 90% done, just finish
it and write a few reports."

Translation: "This customer's prevous contractor fled screaming into the
night, they don't have any idea of what has been done, nor do they have any
documentation on what they want. Just sign on this dotted line for a
lifetime of indentured servitude."

I'd put a <GRIN> in here, but it's not funny. In some of those cases, I
know that unwary developers new to the contracting business actually took on
the project -- with results that you and I can predict from the preceding
paragraph.

--
Larry Linson, Microsoft Office Access MVP
Co-author: "Microsoft Access Small Business Solutions", published by Wiley
Access newsgroup support is alive and well in USENET
comp.databases.ms-access

"Access Developer" <accdevel (AT) gmail (DOT) com> wrote in
news:991qjiFk4aU1 (AT) mid (DOT) individual.net:

On the other hand, some of my best projects have come from clients
with Access databases that nobody would touch with a 10-foot pole --
everyone contacted by them said "Oh, it has to be rewritten in
VB.NET/Tomcat with a distributed SQL Server back end, blah, blah,
blah, and will cost $1 million".

I come in, on the other hand, and tell them I can do what they want
and can do it in small increments, a few hundred dollars at a time.
Sometimes these projects are nasty messes, but usually they are just
the type of thing that people could get away with back in the late
90s before people figured out that an Access app held together with
macros and almost no code was pretty hard to maintain.

I enjoy these projects, as the clients are particularly grateful.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

The "red flag" in what I quoted is they begin with "Shouldn't take more than
two weeks", thus establishing their (most often their customer/client's)
expectation of an upper limit. I've investigated a few of these, and, unlike
David, have almost always found that the only reasonable approach was to (1)
obtain and document clear requirements, (2) give them an accurate estimate,
and (3) start from scratch if they did not go into shock at the estimate.

I did work on one modest-size database that had been initiated by someone
who was not an Access developer that was a success. But, he was an
engineer, computer literate, had used Access quite a lot, and knew the
subject matter (tracking engineering projects from pre-proposal to
completion). And, the client knew that it was not a trivial project. Nor,
did they start with "Should only take...".

They were a pleasure to work with, the project ran until their "busy" season
when the engineers who were involved with requirements and reviewing
incremental development were busy in the field overseeing projects. Between
then and the next off-season, they realized that they didn't really need
"quality points" for tracking the projects so closely and decided against
additional enhancements. But, because we had been proceeding with
incremental development/enhancement, they had a (smoothly-) working database
that had already addressed and resolved the weakest links in their project
tracking and reporting -- preparing the proposal, assigning personnel, and
initiating design work.

I've also worked on several that were as you described. Again, they knew it
was not a trivial matter, and instead of stating unrealistic expectations,
usually indicated they knew what they wanted, but also knew the "mess" would
probably have to be redone or require major modifications (before I even
looked at the projects and had to be the bearer of the bad financial and
chronological news).

--
Larry Linson, Microsoft Office Access MVP
Co-author: "Microsoft Access Small Business Solutions", published by Wiley
Access newsgroup support is alive and well in USENET
comp.databases.ms-access

Albert Kallal wrote:

On the other hand, I actually have a love for walking into really big piles
of haystacks that need to be tightly bundled up and placed into nice little
tidy bales of hay all stacked up like beautiful little building blocks that
I used to play with as a child.

In other words, if they want everything for free and there's no budgets to
get the job done correctly, then I agree with you run for the hills!

On the other hand, if budget and resources and commitments to excellence are
in place? Oh my, then there is nothing more rewarding than taking something
that really wasn't that well done, smelled rather bad, and turning the whole
process into a wonderful bed of tranquility and beautiful great smelling
roses.

On Sun, 24 Jul 2011 16:22:33 -0500, "Access Developer"
<accdevel (AT) gmail (DOT) com> wrote:

I looked at one system where it was not documented, no one had
supported it for some time, and there were parts of the program that
had never worked right.

I proposed to start by doing some basic documentation of tables
and processes. A few days later, the secretary called back and said
that they were looking for someone who could "just jump in". I think
I dodged a bullet.

[snip]

Sincerely,

Gene Wirchenko