Surpress ODBC error messages...

[Neil Toulouse]

Hi there!

I have hit a snag! This could quite easily be my misunderstanding of how the command works, but I will run it by you.

Basically you run a T-SQL command, eg:

lnError = SQLEXEC( lnHandle, "SELECT * FROM MyTable WHERE 0=1", "MyCursor")

If all has gone OK lnError has a value of 1 and MyCursor will be created.

On the other hand, if there is an issue with the SQL command, lnError returns -1 and MyCursor does not get created.

As a -1 error is somewhat meaningless, to get a more meaningful error message, you submit the command:

=SQLSETPROP(lnHandle, "DispWarnings", .T.)

...before issuing the SQLEXEC() statement. To swith off this error messaging you simply then issue the command:

=SQLSETPROP(lnHandle, "DispWarnings", .F.)

Have I understood this process correctly?

My problem is I CANNOT switch off the error messaging!! I have trawled the code for the DispWarnings being .T. but to no avail. Thinking it may be just stuck on in the session I was in I rebooted my machine and restarted SQL Server, but still the error messages are being displayed.

Is there another way that may have been used but I have over looked?

BTW, Running VFP8 to SQL Server 2005 Express via Native Client ODBC.

TIA
Neil

I like work. It fascinates me. I can sit and look at it for hours...

 

[DougHennig]

Hi Neil.

To figure out why a SQLEXEC statement failed, use AERROR().

Doug

 

[Neil Toulouse]

Hi Doug!

Thanks for that. In this instance I just need to stop the errors from being displayed regardless of what the error is. All the trapping is in place to take care of it, but I cant stop the user seeing the message.

Neil

I like work. It fascinates me. I can sit and look at it for hours...

 

[Ildegardo]

Hi Neil,

To handle errors, not displaying anything, put in (the top of) your PRG

ON ERROR DO errorhandling (to even improve add WITH PROGRAM(), LINENO())
In errorhandling use AERROR() to identify and process your troubles.

Hope this helps.

 

[Mike Lewis]

Neil,

First, let me say I agree with you about using DispWarnings. When you are developing, you want to see what mistakes you have made, at the time that you make them. Using AERROR() or an ON ERROR routine is good at run time, when you want to log the error, but during testing, the immediacy of DispWarning is more appropriate.

However, you need to keep in mind that SQLSETPROP() only applies to a specific connection, and only while that connection is open. If you close the connection and re-open it, the setting returns to its default.

If you are using a connection object within a DBC, the default setting for DispWarnings will be whatever setting is stored in that object. That setting is determined at design time (in the connection designer), or by issuing DBSETPROP().

DBSETPROP affects the setting as stored in the DBC, not the setting for the active connection.

Does that help at all?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[Neil Toulouse]

Hi Mike!

Thanks for the info. Useful to know a bit more depth, but unfortunately doesn't help in my scenario. All I can think is I still have a DispWarnings set to .T. somewhere and I just can't find it (and code reference search doesn't turn up anything).

It has driven me mad all day! I'll rest my brain over the w/e (assisted by copious quantities of some sort of alcohol), and look afresh on Monday!

Cheers!

Neil

I like work. It fascinates me. I can sit and look at it for hours...