Developing in Access 2003 for Access 97 users

[DeanL]

I know you can convert a database from Access 2003 to 97 easily but is
there anything that I should avoid doing in Access 2003 that might make
my database incompatible with Access 97?

Many thanks, Dean...

[Lyle Fairfield]

DeanL wrote:

I know you can convert a database from Access 2003 to 97 easily but is
there anything that I should avoid doing in Access 2003 that might make
my database incompatible with Access 97?

Starting.

[Allen Browne]

Dean, if you have Access 97 as well as 2003, I would agree with Lyle that it
would be better to use 97 to develop this database. I actually did a small
one earlier this year using 2003 and converting back at the end: if I had
that time again, I would do the whole thing in A97.

It kinda depends what functionality you use, but avoid stuff like:
- Conditional Formatting
- the Undo event of the form.
- OpenArgs for OpenReport.
- VBA functions such as Replace() and Split().
- ADO-specific code (especially DDL)

If you do convert back, decompile first. Avoid any references other than
VBA, Access and DAO. After conversion to A97, you will still need to change
your DAO reference to 3.51. (A2003 doesn't make that change for you.)

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Lyle Fairfield" <ly***********@aim.com> wrote in message
news:11*********************@g44g2000cwa.googlegro ups.com...

DeanL wrote:

I know you can convert a database from Access 2003 to 97 easily but is
there anything that I should avoid doing in Access 2003 that might make
my database incompatible with Access 97?

Starting.

[David W. Fenton]

"Allen Browne" <Al*********@SeeSig.Invalid> wrote in
news:43***********************@per-qv1-newsreader-01.iinet.net.au:

Dean, if you have Access 97 as well as 2003, I would agree with
Lyle that it would be better to use 97 to develop this database. I
actually did a small one earlier this year using 2003 and
converting back at the end: if I had that time again, I would do
the whole thing in A97.

It kinda depends what functionality you use, but avoid stuff like:
- Conditional Formatting
- the Undo event of the form.
Me.Undo exists in A97. But the OnDirty event does not exist.
- OpenArgs for OpenReport.
- VBA functions such as Replace() and Split().
One could easily port that code for A97.
- ADO-specific code (especially DDL)
Much of it would still work with ADO1.5
If you do convert back, decompile first. . . .
This strikes me as a waste of time, as all the compiled code will be
discarded, anyway, during the conversion.
. . . Avoid any references other than
VBA, Access and DAO. After conversion to A97, you will still need
to change your DAO reference to 3.51. (A2003 doesn't make that
change for you.)

A2K did.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Allen Browne]

In line.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"David W. Fenton" <XX*******@dfenton.com.invalid> wrote in message
news:Xn**********************************@127.0.0. 1...

"Allen Browne" <Al*********@SeeSig.Invalid> wrote in
news:43***********************@per-qv1-newsreader-01.iinet.net.au:

... avoid stuff like:
- Conditional Formatting
- the Undo event of the form.

Me.Undo exists in A97. But the OnDirty event does not exist.

Not the Undo METHOD (so you can undo the record), but the Undo EVENT of the
Form (i.e. where Access notifies you that the record has been reset.)

There was a KB article on how to simulate an undo event for the form, but it
did not work reliably. A2000 introduced a true Form_Undo event that works.

- OpenArgs for OpenReport.
- VBA functions such as Replace() and Split().

One could easily port that code for A97.

Yes, if one is aware of the issue.

- ADO-specific code (especially DDL)

Much of it would still work with ADO1.5

Yes, I did not word that clearly. I was thinking of the new JET 4 features
that don't work in the query interface or in DAO in later versions of
Access, so have to be executed via ADO.

If you do convert back, decompile first. . . .

This strikes me as a waste of time, as all the compiled code will be
discarded, anyway, during the conversion.

You may be right: I don't recall getting caught when converting back to 97.
But I have been caught several times with a database I edited in A2003 and
the user is using A2000. The silent discard is not reliable, and actually
does corrupt the database and introduce bloating and hard-to-trace bugs. The
suggestion is to force the discard before converting back to any previous
version, but I have no evidence that this would be productive for a
conversion back to 97.

. . . Avoid any references other than
VBA, Access and DAO. After conversion to A97, you will still need
to change your DAO reference to 3.51. (A2003 doesn't make that
change for you.)

A2K did.

Yes, that's the way I remember it also, so I was surprised that A2003 did
not.

[David W. Fenton]

"Allen Browne" <Al*********@SeeSig.Invalid> wrote in
news:43***********************@per-qv1-newsreader-01.iinet.net.au:

"David W. Fenton" <XX*******@dfenton.com.invalid> wrote in message
news:Xn**********************************@127.0.0. 1...

"Allen Browne" <Al*********@SeeSig.Invalid> wrote in
news:43***********************@per-qv1-newsreader-01.iinet.net.au:

... avoid stuff like:
- Conditional Formatting
- the Undo event of the form.

Me.Undo exists in A97. But the OnDirty event does not exist.

Not the Undo METHOD (so you can undo the record), but the Undo
EVENT of the Form (i.e. where Access notifies you that the record
has been reset.)

You're right -- you did say EVENT.

[]

- ADO-specific code (especially DDL)

Much of it would still work with ADO1.5

Yes, I did not word that clearly. I was thinking of the new JET 4
features that don't work in the query interface or in DAO in later
versions of Access, so have to be executed via ADO.

I know of a grand total of ONE thing that has to be done in ADO, and
that's UserRoster. What else is there?

Certainly, items that are specific to Jet 4 couldn't be back ported
to A97, anyway, so those are rather irrelevant to the basic ADO
question.

If you do convert back, decompile first. . . .

This strikes me as a waste of time, as all the compiled code will
be discarded, anyway, during the conversion.

You may be right: I don't recall getting caught when converting
back to 97. But I have been caught several times with a database I
edited in A2003 and the user is using A2000. The silent discard is
not reliable, and actually does corrupt the database and introduce
bloating and hard-to-trace bugs. The suggestion is to force the
discard before converting back to any previous version, but I have
no evidence that this would be productive for a conversion back to
97.

I decompile enough during regular development that I don't think it
necessary when converting to a new version, but I don't use any MDB
version after 2000.

In any event, converting to A97 would definitely have to discard all
the code, as everything is different, and I believe that was the
scenario this thread is about.

. . . Avoid any references other than
VBA, Access and DAO. After conversion to A97, you will still
need to change your DAO reference to 3.51. (A2003 doesn't make
that change for you.)

A2K did.

Yes, that's the way I remember it also, so I was surprised that
A2003 did not.

Two steps forward, one back, it seems.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/