Test for Good Remote View Connectivity

[IForgotAgain]

Periodically we encounter a problem with Connectivity to a Remote View. In general this is due to the Remote Server being down or some other "outside" (Non-VFP Application) issue.

Rather than merely having VFP throw up a Connectivity Error message [Error 1526] and then QUIT, I'd like to handle the error in a more "graceful" manner and inform the users that its the OTHER system that is causing the problem.

If anyone has some good ideas how to Test for Good Connectivity first, before attempting to collect records from a Remote Table via a Remote View, I'd welcome the suggestions.

Thanks,
I_Forgot_Again

 

[Mike Lewis]

Why not just trap the error in the usual way, and take the graceful action?

Presumably, the error comes up when you either USE or REQUERY() the view. With VFP 8.0 and above, the easiest way of dealing with it would be with TRY/ENDTRY. With earlier versions, you would have to re-direct your erroor-handler, like so:

lcOldError = ON("ERROR")
ON ERROR llFlag = .T.
llFlag = .F.
USE MyView
ON ERROR &lcOldError
IF llFlag
  * Error opening the view (use ARROR()
  * to find the error number)
ELSE
  * all is well
ENDIF

Do something similar when you requery the view.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)

 

[IForgotAgain]

Mike - thanks for your reply.

There are 2 distinct types of Remote View errors which we encounter from time to time:

1. Connectivity Errors (due to bad or missing ODBC DSN)
2. Database fields have changed (due to changes in Remote System)

In both cases VFP throw up an error message which, from the "generic" user's perspective, is not helpful in clearly defining the source of the problem.

I created a simple ON ERROR handling test to see if this error message could be eliminated and alternative processing accomplished.

I used

ON ERROR Wait Window "Debug Test"

After having removed the associated Connect DSN from my workstation and attempting to access a Remote View the ON ERROR approach did not prevent the Connectivity Error message.

I then restored the DSN and confirmed that with the DSN in place the error message would not be generated when a "good" Remote View was accessed.

I next attempted accessing a known "bad" Remote View.

Again the ON ERROR approach did not prevent the "Database fields have changed" error message from being displayed.

My hope was to find a method in which to eliminate the default VFP error message entirely, replace it with my own "more informative" user message, and then continue processing.

Unless I am missing something, it does not look like the ON ERROR approach will do the job.

Your suggestions would be most welcome.

Thanks,
I_Forgot_Again