Advice on upgrading 97 runtime app to 2003

[Owen Jenkins]

I have an Access application that is being used by 150+ clients. I
develop in 97, convert to 2000 and distribute as a 97 or 2000 mde, or 97
runtime. This limits me to 97 functions. My clients may use any one of
Access 97, 2000, 2002, 2003 or 97 runtime.

So that I'm not lingering too far behind, I'm thinking of developing in
2003, using 2000 file format and distributing a 2000 mde for users of
Access 2000+. (I understand I'll need to use A2000 to create the mde.)
So what about my 97 and 97 runtime users? Is it reasonable to consider
distributing a 2003 runtime for these people, and leaving 97 behind
entirely? Can you forsee problems with this? (I must say that my 97
runtime application runs best of all versions.) Would there be any
problems with clients who have a retail version of Access 97, having to
install the 2003 runtime to run my app? Or should I distribute a 2000
runtime.I have the 2000 Dev edition, but have never used it as such
owing to the various issues identified by the extremely clever and
generous contributers to this newsgroup.

Also, I've been using the 97 setup wizard for distributing apps. I'm
planning to go over to QSetup soon
(http://www.pantaray.com/qsetup.html). I know I'll need the 2003 VSTools
for the 2003 runtime, but will I need to use the P & D wizard to create
the runtime files? Can I use the VS functions to create the runtime,
then package these with QSetup?
Owen Jenkins

[Rick Brandt]

"Owen Jenkins" <[e-mail]> wrote in message
news:43***********************@news.optusnet.com.a u...

I have an Access application that is being used by 150+ clients. I develop in
97, convert to 2000 and distribute as a 97 or 2000 mde, or 97 runtime. This
limits me to 97 functions.
Can you list the specific post 97 functions that you really miss?
(just curious)
My clients may use any one of Access 97, 2000, 2002, 2003 or 97 runtime.
Exactly what I do. Works great doesn't it?
So that I'm not lingering too far behind, I'm thinking of developing in 2003,
using 2000 file format and distributing a 2000 mde for users of Access 2000+.
(I understand I'll need to use A2000 to create the mde.) So what about my 97
and 97 runtime users? Is it reasonable to consider distributing a 2003 runtime
for these people, and leaving 97 behind entirely? Can you forsee problems with
this? (I must say that my 97 runtime application runs best of all versions.)
Not at all suprised. That is my experience as well.

Users currently using 97 (runtime or retail) might very well have a version of
Windows that won't run 2003. You have to have Windows 2000 (SP3?) or higher to
run 2003. Are you going to ask them to upgrade their OS as well? For some that
might mean new hardware is also required.
Would there be any problems with clients who have a retail version of Access
97, having to install the 2003 runtime to run my app?
Your app will step on the toes of Access 97 a bit. The most noticeable thing is
that double-clicking an MDB after running your app will attempt to use the 2003
runtime instead of Access 97. They will have to learn to open Access 97 first
and then specify the file from there. Big deal? Hard to say. Many people who
have the licensed version of Access on their PCs have never even opened it.
Those people would not be bothered.
Or should I distribute a 2000 runtime.I have the 2000 Dev edition, but have
never used it as such owing to the various issues identified by the extremely
clever and generous contributers to this newsgroup.
The 2000 runtime solves some of the problems caused by using the 2003 runtime.
It at least runs on more versions of Windows (but is buggier).
Also, I've been using the 97 setup wizard for distributing apps. I'm planning
to go over to QSetup soon (http://www.pantaray.com/qsetup.html). I know I'll
need the 2003 VSTools for the 2003 runtime, but will I need to use the P & D
wizard to create the runtime files? Can I use the VS functions to create the
runtime, then package these with QSetup?

Sorry, can't help you with that.

Just my opinion, but when distributing to a diverse target group what you are
currently doing; offering the 97 runtime, a 97 MDE and a 2000 MDE and letting
the user choose as appropriate is the best way to go. You are able to run on
any 32 bit Windows box, and can service any version of Access that is out there.
I distribute an app to almost 300 users with a similar variety of hardware, OS,
and Office installed (or not) and have had zero problems with this setup.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[lylefair]

Owen Jenkins wrote:

So that I'm not lingering too far behind, I'm thinking of developing in
2003, using 2000 file format and distributing a 2000 mde for users of
Access 2000+. (I understand I'll need to use A2000 to create the mde.)
So what about my 97 and 97 runtime users?

How about a wreath or a nice lily?

[Owen Jenkins]

Thanks for your comments.

Because I develop in 97, I haven't actually used 2000+ too much. The
main thing I'm missing in the user interface is conditional formatting,
which would be very useful to my app. Code-wise, I think the File System
Object would be very handy. My 97 app uses function calls to open folder
dialogs etc.

Just my opinion, but when distributing to a diverse target group what you are
currently doing; offering the 97 runtime, a 97 MDE and a 2000 MDE and letting
the user choose as appropriate is the best way to go. You are able to run on
any 32 bit Windows box, and can service any version of Access that is out there.
I distribute an app to almost 300 users with a similar variety of hardware, OS,
and Office installed (or not) and have had zero problems with this setup.

This is why I haven't moved from 97 yet. Maybe I should stick with it
for the present. I'm just a bit worried about using 'old technology'.

Owen

[Rick Brandt]

"Owen Jenkins" <[e-mail]> wrote in message
news:43***********************@news.optusnet.com.a u...

Thanks for your comments.

Because I develop in 97, I haven't actually used 2000+ too much. The main
thing I'm missing in the user interface is conditional formatting, which would
be very useful to my app. Code-wise, I think the File System Object would be
very handy. My 97 app uses function calls to open folder dialogs etc.

Just my opinion, but when distributing to a diverse target group what you are
currently doing; offering the 97 runtime, a 97 MDE and a 2000 MDE and letting
the user choose as appropriate is the best way to go. You are able to run on
any 32 bit Windows box, and can service any version of Access that is out
there. I distribute an app to almost 300 users with a similar variety of
hardware, OS, and Office installed (or not) and have had zero problems with
this setup.

This is why I haven't moved from 97 yet. Maybe I should stick with it for the
present. I'm just a bit worried about using 'old technology'.

I wouldn't be concerned with the "fashion" aspects.

Depending on your circumstances you could freeze the 97 app as far as adding new
functionality, but continue to have it on the distribution disk and just move
forward only with the newer versions. That would at least allow users of the 97
version to have some time (and an incentive) to upgrade without cutting their
feet out from under them all at once.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[David W. Fenton]

Owen Jenkins <[e-mail]> wrote in
news:43***********************@news.optusnet.com.a u:

Because I develop in 97, I haven't actually used 2000+ too much.
The main thing I'm missing in the user interface is conditional
formatting, which would be very useful to my app. Code-wise, I
think the File System Object would be very handy. My 97 app uses
function calls to open folder dialogs etc.

If I'm not mistaken, the file system object is provided by the
Windows Scripting Host and should be usable in A97 as well. However,
keep in mind that some system administrators put policies in place
that prohibit the WSH from running at all.

I'd stick with API calls, myself, since they will always work, no
matter what.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Owen Jenkins]

David W. Fenton wrote:

Owen Jenkins <[e-mail]> wrote in
news:43***********************@news.optusnet.com. au:

Because I develop in 97, I haven't actually used 2000+ too much.
The main thing I'm missing in the user interface is conditional
formatting, which would be very useful to my app. Code-wise, I
think the File System Object would be very handy. My 97 app uses
function calls to open folder dialogs etc.

If I'm not mistaken, the file system object is provided by the
Windows Scripting Host and should be usable in A97 as well. However,
keep in mind that some system administrators put policies in place
that prohibit the WSH from running at all.

I'd stick with API calls, myself, since they will always work, no
matter what.

Thanks. I feel a little better about not going on the upgrade path just
yet. A97 and API calls certainly work well. I might just stick to them.

Re conditional formatting, I thought I might put in some code like the
following into my app, so that 2000+ users could use this feature. I
have to put this into my 97 app since I don't want to have multiple
development versions. However, the following won't compile in A97
(obviously since A97 doesn't recognize .FormatConditions!). Is there any
way around this that you can suggest?

In the form open event ...

If SysCmd(acSysCmdAccessVer) > 7 Then
With [PaymentStatus].FormatConditions _
.Add(acExpression, , "[PaymentStatus] Like ""*overdue*"" OR
[PaymentStatus] Like ""*reminder*""")
.BackColor = vbRed
End With
End If
Owen

[lylefair]

Owen Jenkins wrote:

Thanks. I feel a little better about not going on the upgrade path just
yet. A97 and API calls certainly work well. I might just stick to them.

Absolutely; my direct writes to the Commodore 64 kernel addresses
certainly work well and are lightning fast. Why change?

What, me worry?

[david epsom dot com dot au]

Conditional formating is still pretty limited.
When we looked at it we realised it still would
not do the things we wanted to do (like changing
the format string of the control so that it
showed $100.00 only for $ currencies). If all
you want is conditional backcolor, you can do
that the old fashioned way.

(david)
"Owen Jenkins" <[e-mail]> wrote in message
news:43***********************@news.optusnet.com.a u...

Thanks for your comments.

Because I develop in 97, I haven't actually used 2000+ too much. The main
thing I'm missing in the user interface is conditional formatting, which
would be very useful to my app. Code-wise, I think the File System Object
would be very handy. My 97 app uses function calls to open folder dialogs
etc.

Just my opinion, but when distributing to a diverse target group what you
are currently doing; offering the 97 runtime, a 97 MDE and a 2000 MDE and
letting the user choose as appropriate is the best way to go. You are
able to run on any 32 bit Windows box, and can service any version of
Access that is out there. I distribute an app to almost 300 users with a
similar variety of hardware, OS, and Office installed (or not) and have
had zero problems with this setup.

This is why I haven't moved from 97 yet. Maybe I should stick with it for
the present. I'm just a bit worried about using 'old technology'.

Owen

[David W. Fenton]

Owen Jenkins <[e-mail]> wrote in
news:43**********************@news.optusnet.com.au :

Re conditional formatting, I thought I might put in some code like
the following into my app, so that 2000+ users could use this
feature. I have to put this into my 97 app since I don't want to
have multiple development versions. However, the following won't
compile in A97 (obviously since A97 doesn't recognize
.FormatConditions!). Is there any way around this that you can
suggest?

There's a way to do conditional compiling with the # symbol, but
I've never done it myself. Perhaps someone here could explain it.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Rick Brandt]

David W. Fenton wrote:

Owen Jenkins <[e-mail]> wrote in
news:43**********************@news.optusnet.com.au :

Re conditional formatting, I thought I might put in some code like
the following into my app, so that 2000+ users could use this
feature. I have to put this into my 97 app since I don't want to
have multiple development versions. However, the following won't
compile in A97 (obviously since A97 doesn't recognize
.FormatConditions!). Is there any way around this that you can
suggest?

There's a way to do conditional compiling with the # symbol, but
I've never done it myself. Perhaps someone here could explain it.

I use the Terminal font in a TextBox with a contrasting ForeColor like
yellow and an expression like this...

=IIf(AnyDataTestYouLike, Null,"ÛÛÛÛÛÛÛÛÛ")

In Terminal font the Û character is displayed as a solid block. If you
string enough of these characters together and place this TextBox behind
your others and make them have transparent backgrounds then rows that
satisfy the test will have a yellow background. You could layer as many of
these controls as you need and theoretically have as many different
background colors as you like. Of course you have to be careful to deal with
situations where more than one test could be satisfied as the background
color TextBox that is "on top" will win out.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[David W. Fenton]

"Rick Brandt" <ri*********@hotmail.com> wrote in
news:sW*******************@newssvr21.news.prodigy. com:

David W. Fenton wrote:

Owen Jenkins <[e-mail]> wrote in
news:43**********************@news.optusnet.com.au :

Re conditional formatting, I thought I might put in some code
like the following into my app, so that 2000+ users could use
this feature. I have to put this into my 97 app since I don't
want to have multiple development versions. However, the
following won't compile in A97 (obviously since A97 doesn't
recognize .FormatConditions!). Is there any way around this that you can suggest?
There's a way to do conditional compiling with the # symbol, but
I've never done it myself. Perhaps someone here could explain

it.
I use the Terminal font in a TextBox with a contrasting ForeColor
like yellow and an expression like this...

=IIf(AnyDataTestYouLike, Null,"ÛÛÛÛÛÛÛÛÛ")

In Terminal font the Û character is displayed as a solid block.
If you string enough of these characters together and place this
TextBox behind your others and make them have transparent
backgrounds then rows that satisfy the test will have a yellow
background. You could layer as many of these controls as you need and theoretically have as many different background colors as you
like. Of course you have to be careful to deal with situations
where more than one test could be satisfied as the background
color TextBox that is "on top" will win out.

Er, that's an answer of how to do conditional *formatting*. I was
talking about conditional *compiling*, in VBA code.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Rick Brandt]

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@216.196. 97.142...

"Rick Brandt" <ri*********@hotmail.com> wrote in
news:sW*******************@newssvr21.news.prodigy. com:

David W. Fenton wrote:

Owen Jenkins <[e-mail]> wrote in
news:43**********************@news.optusnet.com.au :

Re conditional formatting, I thought I might put in some code
like the following into my app, so that 2000+ users could use
this feature. I have to put this into my 97 app since I don't
want to have multiple development versions. However, the
following won't compile in A97 (obviously since A97 doesn't
recognize .FormatConditions!). Is there any way around this that you can suggest?

There's a way to do conditional compiling with the # symbol, but
I've never done it myself. Perhaps someone here could explain

it.

I use the Terminal font in a TextBox with a contrasting ForeColor
like yellow and an expression like this...

=IIf(AnyDataTestYouLike, Null,"ÛÛÛÛÛÛÛÛÛ")

In Terminal font the Û character is displayed as a solid block.
If you string enough of these characters together and place this
TextBox behind your others and make them have transparent
backgrounds then rows that satisfy the test will have a yellow
background. You could layer as many of these controls as you

need

and theoretically have as many different background colors as you
like. Of course you have to be careful to deal with situations
where more than one test could be satisfied as the background
color TextBox that is "on top" will win out.

Er, that's an answer of how to do conditional *formatting*. I was
talking about conditional *compiling*, in VBA code.

Oops, all of the posts prior to yours only mentioned conditional formatting
so I guess I missed the change.

[Owen Jenkins]

Rick Brandt wrote:

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@216.196 .97.142...

"Rick Brandt" <ri*********@hotmail.com> wrote in
news:sW*******************@newssvr21.news.prodig y.com:

David W. Fenton wrote:
Owen Jenkins <[e-mail]> wrote in
news:43**********************@news.optusnet.co m.au:

>Re conditional formatting, I thought I might put in some code
>like the following into my app, so that 2000+ users could use
>this feature. I have to put this into my 97 app since I don't
>want to have multiple development versions. However, the
>following won't compile in A97 (obviously since A97 doesn't
>recognize .FormatConditions!). Is there any way around this
>
>

that

>you can suggest?
>
>
There's a way to do conditional compiling with the # symbol, but
I've never done it myself. Perhaps someone here could explain

it.

I use the Terminal font in a TextBox with a contrasting ForeColor
like yellow and an expression like this...

=IIf(AnyDataTestYouLike, Null,"ÛÛÛÛÛÛÛÛÛ")

In Terminal font the Û character is displayed as a solid block.
If you string enough of these characters together and place this
TextBox behind your others and make them have transparent
backgrounds then rows that satisfy the test will have a yellow
background. You could layer as many of these controls as you

need

and theoretically have as many different background colors as you
like. Of course you have to be careful to deal with situations
where more than one test could be satisfied as the background
color TextBox that is "on top" will win out.

Er, that's an answer of how to do conditional *formatting*. I was
talking about conditional *compiling*, in VBA code.

Oops, all of the posts prior to yours only mentioned conditional formatting
so I guess I missed the change.

I've tried the following code and it will allow the 97 app to compile.
However, when converted to 2000, the same code doesn't run. It behaves
as if the procedure doesn't exist.
Dim AccVer As Single
AccVer = SysCmd(acSysCmdAccessVer)

'Only compile this if pgm is Access 2000 or later
#If AccVer > 8 Then
With [PaymentStatus].FormatConditions _
.Add(acExpression, , "[PaymentStatus] Like ""*overdue*"" OR
[PaymentStatus] Like ""*reminder*""")
.BackColor = 13421823
End With
With [PaymentStatus].FormatConditions _
.Add(acExpression, , "[PaymentStatus] Like ""*ready to send*""")
.BackColor = vbGreen
End With

With [TotalReceived].FormatConditions _
.Add(acFieldValue, acGreaterThan, 0)
.BackColor = vbGreen
End With
#End If
Owen

[RoyVidar]

Owen Jenkins wrote in message
<43***********************@news.optusnet.com.au> :

I've tried the following code and it will allow the 97 app to compile.
However, when converted to 2000, the same code doesn't run. It behaves as if
the procedure doesn't exist.
Dim AccVer As Single
AccVer = SysCmd(acSysCmdAccessVer)
'Only compile this if pgm is Access 2000 or later
#If AccVer > 8 Then
With [PaymentStatus].FormatConditions _
.Add(acExpression, , "[PaymentStatus] Like ""*overdue*"" OR
[PaymentStatus] Like ""*reminder*""")
.BackColor = 13421823
End With
With [PaymentStatus].FormatConditions _
.Add(acExpression, , "[PaymentStatus] Like ""*ready to send*""")
.BackColor = vbGreen
End With
With [TotalReceived].FormatConditions _
.Add(acFieldValue, acGreaterThan, 0)
.BackColor = vbGreen
End With
#End If
Owen

I picked up the following from somewhere:

#If CBool(VBA6) Then
' 2000+
#Else
' 97 and lower
#End If

--
Roy-Vidar

[david epsom dot com dot au]

> There's a way to do conditional compiling with the # symbol,

I've never done it myself. Perhaps someone here could explain
Conditional compiling works OK in A97, except
that when you make an MDE, you have to declare
the conditional parameters in code (rather than
as database options in the options dialog).

In A2K, Access always compiles all of the code,
so you can't make an MDE with invalid code at
all (A97 specific code or unloaded references).

#Const A97 = True
#If A97 Then

'a97 code here, must compile in A2K
#Else

'A2K code does not have to compile in A97
#End If
(david)
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@216.196. 97.142... Owen Jenkins <[e-mail]> wrote in
news:43**********************@news.optusnet.com.au :

Re conditional formatting, I thought I might put in some code like
the following into my app, so that 2000+ users could use this
feature. I have to put this into my 97 app since I don't want to
have multiple development versions. However, the following won't
compile in A97 (obviously since A97 doesn't recognize
.FormatConditions!). Is there any way around this that you can
suggest?

There's a way to do conditional compiling with the # symbol, but
I've never done it myself. Perhaps someone here could explain it.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[david epsom dot com dot au]

Normally, cbool is not required.

#If VBA6 Then

VBA6 is defined something like this

#Constant VBA6 = -1

Which means that on a #IF line it has a value of -1/True,
and on all normal lines it is undefined.

(david)

"RoyVidar" <ro*************@yahoo.no> wrote in message
news:mn***********************@yahoo.no...

Owen Jenkins wrote in message
<43***********************@news.optusnet.com.au> :

I've tried the following code and it will allow the 97 app to compile.

I picked up the following from somewhere:

#If CBool(VBA6) Then
' 2000+
#Else
' 97 and lower
#End If

--
Roy-Vidar

[Owen Jenkins]

david epsom dot com dot au wrote:

Normally, cbool is not required.

#If VBA6 Then

VBA6 is defined something like this

#Constant VBA6 = -1

Which means that on a #IF line it has a value of -1/True,
and on all normal lines it is undefined.

(david)

Thanks. I'll try the various suggestions and see what works best.

Owen