runtime switch misses some bugs

I have been testing an app (2003, Win 2000) with the runtime switch on my
development computer. When the app is installed on another computer (XP &
A2003 runtime installed), linking with back end throws an error and shuts the
app down. On the development computer opening the app with the runtime
switch, the same error doesn't occur and even when I deliberately move the
back end to a different directory the process works as expected. Is this
normal for testing with the runtime switch? Are there other known bugs that
are not picked up by testing with the runtime switch?

Hi, Liz.

Is this
normal for testing with the runtime switch?

If you test on a computer system that is not configured identically to the
target computer system, then you are entitled to endless hours of wild goose
chase fun. Applications built for the Access Runtime must be much more
robust than an application built for a retail version of Access, which is why
many developers won't build a runtime version unless there's at least 10 or
15 workstation licenses involved, because it's just not cost effective for
the customer.

If you can't test in an environment that is identical to the target
environment, then test in an environment as close as possible to the target
environment -- and cross your fingers. Check the following:

1.) Are the same operating systems and service packs installed on both
computers?

2.) Are the same versions of Access and their service packs installed on
both computers?

3.) Are all installed versions of MS Office located in the same directories
on both computers? (It's best to have only one version of Office installed
on each computer.)

4.) Are both computers configured with the same versions of MDAC? (Use
MDAC 2.8 SP-1.)

5.) Are both computers configured with the same versions of Jet? (Use Jet
4.0 SP-8.)

6.) Are the same security applications (firewall, antivirus, et cetera)
installed on both computers, and with the same settings?

7. Are the same network settings and Windows security permissions assigned
to directory and files on both computers?

Now check your database application intended to be run in the Access Runtime:

1.) Are there any macros? Replace them all with VBA code equivalents,
complete with error handling. Unhandled errors will usually crash the
application.

2.) Do all procedures have error handling? Make it so.

3.) Count how many instances of "On Error Resume Next" are found. If you
find any, replace this code with error handling and replace the programmer
with an experienced developer.

4.) Are there any library references other than the default libraries?
Consider removing the non-default libraries and replacing the relevant VBA
code with code that uses objects with late-binding.

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)

- - -
When you see correct answers to your question posted in Microsoft's Online
Community, please sign in to the Community and mark these posts as "Answers,"
so that all may benefit by filtering on "Answered questions" and quickly
finding the right answers to similar questions. Remember that the first and
best answers are often given to those who have a history of rewarding the
contributors who have taken the time to answer questions correctly.


"Liz James" wrote:

I have been testing an app (2003, Win 2000) with the runtime switch on my
development computer. When the app is installed on another computer (XP &
A2003 runtime installed), linking with back end throws an error and shuts the
app down. On the development computer opening the app with the runtime
switch, the same error doesn't occur and even when I deliberately move the
back end to a different directory the process works as expected. Is this
normal for testing with the runtime switch? Are there other known bugs that
are not picked up by testing with the runtime switch?

Thanks, this is the most informative and clear response I have read about
developing for the runtime environment.
All you guys are great.
Liz

"'69 Camaro" wrote:

Hi, Liz.

Is this
normal for testing with the runtime switch?

If you test on a computer system that is not configured identically to the
target computer system, then you are entitled to endless hours of wild goose
chase fun. Applications built for the Access Runtime must be much more
robust than an application built for a retail version of Access, which is why
many developers won't build a runtime version unless there's at least 10 or
15 workstation licenses involved, because it's just not cost effective for
the customer.

If you can't test in an environment that is identical to the target
environment, then test in an environment as close as possible to the target
environment -- and cross your fingers. Check the following:

1.) Are the same operating systems and service packs installed on both
computers?

2.) Are the same versions of Access and their service packs installed on
both computers?

3.) Are all installed versions of MS Office located in the same directories
on both computers? (It's best to have only one version of Office installed
on each computer.)

4.) Are both computers configured with the same versions of MDAC? (Use
MDAC 2.8 SP-1.)

5.) Are both computers configured with the same versions of Jet? (Use Jet
4.0 SP-8.)

6.) Are the same security applications (firewall, antivirus, et cetera)
installed on both computers, and with the same settings?

7. Are the same network settings and Windows security permissions assigned
to directory and files on both computers?

Now check your database application intended to be run in the Access Runtime:

1.) Are there any macros? Replace them all with VBA code equivalents,
complete with error handling. Unhandled errors will usually crash the
application.

2.) Do all procedures have error handling? Make it so.

3.) Count how many instances of "On Error Resume Next" are found. If you
find any, replace this code with error handling and replace the programmer
with an experienced developer.

4.) Are there any library references other than the default libraries?
Consider removing the non-default libraries and replacing the relevant VBA
code with code that uses objects with late-binding.

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)

- - -
When you see correct answers to your question posted in Microsoft's Online
Community, please sign in to the Community and mark these posts as "Answers,"
so that all may benefit by filtering on "Answered questions" and quickly
finding the right answers to similar questions. Remember that the first and
best answers are often given to those who have a history of rewarding the
contributors who have taken the time to answer questions correctly.


"Liz James" wrote:

I have been testing an app (2003, Win 2000) with the runtime switch on my
development computer. When the app is installed on another computer (XP &
A2003 runtime installed), linking with back end throws an error and shuts the
app down. On the development computer opening the app with the runtime
switch, the same error doesn't occur and even when I deliberately move the
back end to a different directory the process works as expected. Is this
normal for testing with the runtime switch? Are there other known bugs that
are not picked up by testing with the runtime switch?

3.) Count how many instances of "On Error Resume Next" are found. If you
find any, replace this code with error handling and replace the programmer
with an experienced developer.

So, how do YOU do in line error handling? )

Seriously though, On Error Resume Next may be appropriate in context. It
just depends on the app, and the criticality of the function being executed.
Unless you're writing software for space missions, nuclear plants, or some
other highly critical function...spending huge amounts of time writing
detailed error handlers is not very cost effective.

Example

Function IsMDE(db As Database) As Boolean

Dim strMDE As String

On Error Resume Next

strMDE = db.Properties("MDE")
If Err = 0 And strMDE = "T" Then
' This is an MDE database.
IsMDE = True
Else
IsMDE = False
End If

End Function


Now, you could say that whatever called this function should know if there
was an error and what that error was. But there isn't any value in knowing
that the property doesn't exist...if the database isn't an MDE, it shouldn't
have the property. I say shouldn't...but someone may have created the
property by other means (i.e., CreateProperty) without actually making an
MDE. So, now the function shows no error and is returning an incorrect
value!

So...what's a programmer to do? It's the humans that cause all the errors!
) Kill Kill Kill lol

So...what's a programmer to do? It's the humans that cause all the
errors! ) Kill Kill Kill lol

http://soundwavs.trekkieguy.com/2/32/nomad.wav

Fred Boer