Problem Converting Access 2.0 to Access 2003

[Vagabond Software]

I have successfully converted an Access 2.0 database to Access 2003 (sort
of). I still have some lingering problems. On the main application form,
clicking any of the buttons produces the following error:

"The expression OnClick you entered as the event property setting produced
the following error:
The expression you entered has a function name that Microsoft Office Access
can't find."

The OnClick Property on the original machine, which is working, has the
following text:

=UCmdOpenForm("RQ-MCC lender")

That is the same text listed in the OnClick property of the converted
database. There is a form named RQ-MCC lender in the converted database and
it opens manually without problems.

I'm not sure what I should be looking for at this point, but I think I just
need to be pointed in the right direction. Any tips or suggestions would be
greatly appreciated.

Carl

 

[Albert D.Kallal]

Well, the first thing is did you try compiling the software?

While looking at a code, you want to go debug->compile....

the above will help you find syntax errors in the code...

Fix them one by one using the above.....

The OnClick Property on the original machine, which is working, has the
following text:

=UCmdOpenForm("RQ-MCC lender")

I would simply hit ctrl-g, and in the debug window type in

ucmdopenform

place my cursor on the above...and then hit shift-f2.....

This should jump you to the above routine......does is have any compile
errors?

Do step #1 before you even start trying to check for individual routines one
by one....

UCmdOpenForm is not a regular ms-access command, so it is likely a custom
function.....

I would also try opening the form rq-mcc lender manually..and see what
happens....

 

[Vagabond Software]

Opening the RQ-MCC lender form manually works as expected.

I attempted the suggested Debug-Compile and received the following error:

Compile Error:
Sub or Function not defined.

Of course, this was not for the UCmdOpenForm, but another function in the
code called UpdateLenderTable. As expected, Shift-F2 cannot take me to the
function since it does not appear to exist.

The Access 2.0 database only has only one very brief module, which I
compiled before doing the conversion. I'm not sure where all this new
code-behind is coming from.

Any additional help is greatly appreciated. I still have the original
Access 2.0 running side-by-side with the converted Access 2003.

carl

 

[Albert D.Kallal]

While in code you can use ctrl-f to find


Search for

UpdateLenderTable

Note the options in the search to search ALL OF THE APPLICATION.....

That function should be in a standard module somewhere.....

Perhaps he definition needs to be changed to

Function UpdateLenderTable

To

Public Function UpdateLenderTable


Did you let ms-access convert this database for you, or did you simply
import to a2003?

 

[Vagabond Software]

I searched for the UpdateLenderTable function without success. I couldn't
see an "ALL OF THE APPLICATION" option, but I did select the "Current
Project" option which seemed to be the most inclusive. There is a "utility"
project that Access seems to have added as a reference and it is not
viewable.

I allowed Access to convert the database for me from the Tools-Database
Utilities-Convert Database menu option. It did so without reporting any
errors.

I did find that if I replaced the UCmdOpenForm call in the OnClick property
with the following event procedure, the click event works as expected:

Private Sub Lender_Administratio_Click()

DoCmd.OpenForm ("RQ-MCC lender")
End Sub

I still don't know where the UpdateLenderTable comes from, but it appears
only four times. Here is a sample of the calling procedure:

Private Sub billingoffice_AfterUpdate()
Screen.ActiveForm.[displaybo] =
Screen.ActiveForm![billingoffice].Column(1) & ", " &
Screen.ActiveForm![billingoffice].Column(2)
Screen.ActiveForm.[displaybo].Visible = True
Screen.ActiveForm.[displaybo].SetFocus
rval = UpdateLenderTable((Screen.ActiveForm![billingoffice].Column(0)),
"Billing Lenders")

End Sub

I really appreciate your help and feel like we are making progress.

Carl

 

[Tony Toews]

The OnClick Property on the original machine, which is working, has the
following text:

=UCmdOpenForm("RQ-MCC lender")

That is the same text listed in the OnClick property of the converted
database. There is a form named RQ-MCC lender in the converted database and
it opens manually without problems.

The problems you are having in your thread with Albert are suggestive
of a removed reference to a MDB.

If you go back to A2.0 what are your references? Unfortunately, as I
do not have A2.0 installed, I can't give you instructions as to get to
your references or to tell you what the standard references are.
However if you go to the VBA, or code module in A2.0 some poking about
on the menus should get you to the references.

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]

Search for/look for UpdateLenderTable in the access 2.0 application...can
you find it there?

These names have to be somewhere....else they would not work....

Check the references of the 2.0.....does it have reference to another
mdb/mde file?

(gee, does 2.0 even have references?)..

, but I did select the "Current

Project" option which seemed to be the most inclusive.

Yes, that is what I meant...if you use that..then all forms code, report
code, and module code is searched.....

 

[Albert D.Kallal]

I did find that if I replaced the UCmdOpenForm call in the OnClick

property with the following event procedure, the click event works as
expected:

a97 to a2003 is likey more picky with the above...

you need to use the format

=UcmdOpenForm()

As far as I know, you cna't leave out the =, nor the ()

 

[Vagabond Software]

The problems you are having in your thread with Albert are suggestive
of a removed reference to a MDB.

If you go back to A2.0 what are your references? Unfortunately, as I
do not have A2.0 installed, I can't give you instructions as to get to
your references or to tell you what the standard references are.
However if you go to the VBA, or code module in A2.0 some poking about
on the menus should get you to the references.

Tony
--

I'm not sure exactly how to view references in Access 2.0 either, but I did
find a way to browse procedures by object (a rudimentary object browser).
Using the View Procedures dialog, I was able to locate the
UpdateLenderTable, UCmdOpenForm, and what I guess will be the other
functions I am missing.

In Access 2.0, if I hit F11 and look at the Modules, there is only one
listed. It is named Application Support and has a grand total of maybe 10
lines of code, all of them Dim statements. However, if I then click
View-Procedures from the menu to bring up the View Procedures dialog, I can
use the Databases drop-down to select something called MCCODE01, which
contains all the "lost" functions.

I searched the disk and found a file called Mccode01.mda. This could be the
missing culprit. I will move it over to the new machine and see what
happens.

Does this MDA file require conversion?

Carl

 

[Vagabond Software]

We are getting closer. Thanks to some help from Tony Toews, I found an MDA
file on the Access 2.0 machine that was not moved over to the new machine.
This MDA file contains all the "lost" functions we have been looking for.

Simply having the MDA file in the proper folder when the old database is
converted is not sufficient. Converting the MDA file seems to complete
successfully with the following warning:

"There are calls to 16-bit dynamic-link libraries in modules in this
database. Change your code to call equivalent 32-bit dynamic-link
libraries."

I then get the conversion completed successfully message box.

Unfortunately, this does not seem to fix even the missing functions problem.
I think I may now need to manually add the MCCODE01.MDA file as a reference
or something. Do you know how that is done or if that is even appropriate?

Carl

 

[Albert D.Kallal]

Does this MDA file require conversion?

yes...it does....

So, you will need the orignal mdb file...

 

[Vagabond Software]

Yes, I figured out a conversion was required and a few other steps.

I am now working through compiling all the converted modules and correcting
the various compile errors. For example, replacing MyDB.DeleteQueryDef with
MyDB.QueryDefs.Delete.

I am stuck on one particular compile error concerning a Dynaset as an
unsupported user-defined type. I assume this means the Dynaset is no longer
supported, but I am having a heck of a time finding out what replaced it.

Thanks for all the help so far. I couldn't have gotten this far without you
guys.

Carl

 

[Dirk Goldgar]

Yes, I figured out a conversion was required and a few other steps.

I am now working through compiling all the converted modules and
correcting the various compile errors. For example, replacing
MyDB.DeleteQueryDef with MyDB.QueryDefs.Delete.

I am stuck on one particular compile error concerning a Dynaset as an
unsupported user-defined type. I assume this means the Dynaset is no
longer supported, but I am having a heck of a time finding out what
replaced it.

Recordset. Specifically, "DAO.Recordset". There are several possible
subtypes of Recordset, of which one is the dynaset.

 

[Pieter Wijnen]

You have to do some research on the DLL references
ie
Declare Function & Declare sub
most of them changed from 16 bit to 32 bit
mainly all parameters of type "integer" changed to type "long" & their names
got postfixed by an A if they include strings

example:
Private Declare Function GetOpenFileName Lib "comdlg32.dll" Alias
"GetOpenFileNameA" (pOpenfilename As OpenFilename) As Long
instead of
Private Declare Function GetOpenFileName Lib "comdlg.dll" Alias
"GetOpenFileName" (pOpenfilename As OpenFilename) As Integer

HTH

Pieter

We are getting closer. Thanks to some help from Tony Toews, I found an
MDA file on the Access 2.0 machine that was not moved over to the new
machine. This MDA file contains all the "lost" functions we have been
looking for.

Simply having the MDA file in the proper folder when the old database is
converted is not sufficient. Converting the MDA file seems to complete
successfully with the following warning:

"There are calls to 16-bit dynamic-link libraries in modules in this
database. Change your code to call equivalent 32-bit dynamic-link
libraries."

I then get the conversion completed successfully message box.

Unfortunately, this does not seem to fix even the missing functions
problem. I think I may now need to manually add the MCCODE01.MDA file as a
reference or something. Do you know how that is done or if that is even
appropriate?

Carl

--

 

[Tony Toews]

However, if I then click
View-Procedures from the menu to bring up the View Procedures dialog, I can
use the Databases drop-down to select something called MCCODE01, which
contains all the "lost" functions.

I searched the disk and found a file called Mccode01.mda. This could be the
missing culprit. I will move it over to the new machine and see what
happens.

Fabulous. That's what I was thinking about.

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 Toews]

I searched the disk and found a file called Mccode01.mda. This could be the
missing culprit. I will move it over to the new machine and see what
happens.

BTW you could just import all the objects from there into your current
MDB and save some mucking about.

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 Toews]

yes...it does....

So, you will need the orignal mdb file...

Unless it's secured no because A2.0 had no ability to create MDEs.

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 Toews]

Check the references of the 2.0.....does it have reference to another
mdb/mde file?

Hah!!! My suggestion beat yours by 22 minutes. <guffaw>

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 Toews]

Simply having the MDA file in the proper folder when the old database is
converted is not sufficient. Converting the MDA file seems to complete
successfully with the following warning:

Correct. You will have to convert it.

Unfortunately, this does not seem to fix even the missing functions problem.
I think I may now need to manually add the MCCODE01.MDA file as a reference
or something. Do you know how that is done or if that is even appropriate?

Yes, you can add it as a reference but why not just import all the
objects from it into your current MDB as having two separate MDBs is
one extra complication.

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

 

[Pieter Wijnen]

OpenRecordset(<select statement>,DbOpenDynaset)
(Dynasets were available for backwards compability in 2.0!)

Pieter

Yes, I figured out a conversion was required and a few other steps.

I am now working through compiling all the converted modules and
correcting the various compile errors. For example, replacing
MyDB.DeleteQueryDef with MyDB.QueryDefs.Delete.

I am stuck on one particular compile error concerning a Dynaset as an
unsupported user-defined type. I assume this means the Dynaset is no
longer supported, but I am having a heck of a time finding out what
replaced it.

Thanks for all the help so far. I couldn't have gotten this far without
you guys.

Carl

--