Quote:
> - The old DAO used in the application has to get replaced.
> The client wants it to get converted directly to ADO.
I wonder why they want to do this? There is no real reason to convert this
code to ado. There is certainly no performance advantage. If you have a lot
of DAO code, then you will have to re-write a lot of code for absolute zero
benefit, and good chance that many bugs and fixes you have made over the
years will be lost. I see no reason why to convert the code from dao to ado.
You will still be using JET, and that thus means you have DAO installed on
your pc.
It is your responsibility to inform the client of this. I suppose if you
need lots more work then you can most certainly re-write your dao code, but
I see no reason to convert the code.
Quote:
> - The VBA Object Library is changed, and some things are
> no longer supported. For example, the application current
> uses Format$ which causes an error in Access 2002.
Hum, you might want to show what that format command looks like. I have had
ZERO trouble with the format in a2002.
Quote:
> - There are some additional reserved words which may cause
> problems with variables that have the same names.
There is not many. I just converted a access97 application to a2002.
The follow stats (lines of VB code) are:
forms code = 15822
reports code = 2127
code in Modules = 8072
-----------
total lines of code = 26021
number of Forms = 158
number of Reports = 68
number of tables = 62
number of modules = 22
number of Queries = 175
So, you can see that I had 22 modules of code (3 class objects), and 26,000
lines of code.
The whole application converted flawlessly without even so much as a hiccup.
That 26,000 lines of code EXTENSIVELY used dao, and it all works just fine.
That above code even has some old legacy QuickBasic code hat uses the old
open "some file" for input as #1
The above type of code worked on the first gw-basic that came out for the
IBM pc in 1982. So, while I can't say that all conversions from a97 to a2002
will be as flawless as the above, not ONE error has come to light so far.
About the worst thing I saw was that a2002 uses the VB message box, and a97
uses a different msg box (its own). The stupid "application title" in a2002
is thus NOT the default for a msg box when you leave it blank. So, I will
eventually have to get around to fixing some of the msg boxes. I fixed about
12 of them in 5 minutes. The result of this is that you see "Microsoft
access" in the title bar of the msgbox when not set (it used to show your
anymore also. (you can use the Eval() function to still use the old msgbox,
but that is really silly). So, the msgbox title problem is hardly a bad
thing, and does not effect operation of the application.
The fixing of the msgbox stuff can wait as that is such a trivial thing.
While the msgbox was trivial, it was the worst problem I encounter!!
Having said all of the above, you do seem to be doing some planning, and
testing before the conversion. Hats off to your for taking a VERY serious
approach here. Often people think that it is simple conversion, and most of
the time this is the case. However, some testing as you are doing is
certainly recommended. Any company upgrading the office suite has to sit
down and plan the migration, as it can be a lot of work.
The other issue that came to light was that the mail merge to ms-word does
not now show the "Insert Merge Field" (it is now a icon in wordxp...dumb
change!!).
Right now, the conversion for me was 100% trouble free, and as mentioned,
the only thing that I *will* change is the msgbox code.
I consider myself a good developer, and course things like word automation
code did use late binding, but all good developers use late binding anyway.
I had just finished writing a calendar 8 replacement, and I had thus removed
the calendar 8 control from the a97 application before converting. (again,
probably would not have been a problem, but I seen WAY too many activeX
problems..and thus avoid them).
Besides, if I was a bad developer, and stuff like word automation code was
not late binding, I bet it would have worked anyway. (however, I can't admit
to ever wanting to find this out).
At the end of the day, if you followed good solid development practices,
then the conversion will go well.
here is one article of use for you:
Office 97 to Microsoft Office XP Migration Issues
http://www.microsoft.com/office/ork/xp/journ/Xpdelta.htm
Good luck, as my conversion was a very positive experience.
--
Albert D. Kallal
Edmonton, Alberta Canada
http://www.attcanada.net/~kallal.msn