Hi ...<br><br>We are running into a problem with the behavior of VFP handling of<br>RAISERROR. We are using PastThruSQL to call all of our data modification<br>routines, for example, one of the SQL Stored Procedure uses the following<br>codes..<br><br>...<br>...<br>BEGIN TRANS<br>-- Delete associated table records<br>DELETE FROM subtableA WHERE field1 = 13234<br>-- Delete main table record<br>DELETE FROM tableA WHERE field1 = @field1<br>IF (@@error != 0)<br>BEGIN<br>ROLLBACK TRANS<br>RETURN (1)<br>END<br>COMMIT TRANS<br><br>Let say the DELETE FROM ... statement caused a Constraint Error and resulted<br>in a RAISERROR. Using SQL QA, the execution will proceed to IF<br>(@@error!=0)... and issues a ROLLBACK TRANS. However, when calling this<br>procedure from VisualFoxPro, the RAISERROR is detected but the exeution of<br>the stored procedure stopped. This resulted in the deletion of subtableA<br>not being rolled back.<br><br>Any insight and advise is greatly appreciated.<br><br>Thanks.<br><br><br>
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Problem with SQL Server RAISERROR and FoxPro PassThruSQL
- Thread starter Creeder
- Start date
Do you have a delete trigger that is explicitly calling RaiseError? If it is a simple constraint violation (not a trigger calling RaiseError) all that should happen is that you'll get a SQLEXEC() return of -1, and checking MESSAGE() will give you something like "constraint violation." <p>Robert Bradley<br><a href=mailto: > </a><br><a href= - Visual FoxPro Development</a><br>
Guest_imported
New member
- Jan 1, 1970
- 0
Thanks for the reply. I am working on the same problem with Creeder.<br><br>The problem we had was the behaviour inconsistency between running a stored procedure in SQL Query Analyzer and calling the stored procedure from VFP when it comes to RAISERROR. <br><br>In QA, the execution of the stored procedure will continue even after a RAISERROR has occur which allows for transaction ROLLBACK, if any previous change were made prior to the Constraint voilation. We are detecting the RAISERROR properly in VFP, the problem is the stored procedure code after the RAISERRROR is not executed when called from VFP.<br><br>Lin-Chow Sim<br>
Guest_imported
New member
- Jan 1, 1970
- 0
Two settings you may want to change are the connection's Asynchronous and Transactions properties.<br><br>To manually control SQL transactions, change the default 1 (automatic) to 2 (manual).<br><br>Try also changing the Asynchronous property from the default .F. to .T. Program execution continues after the SQLEXEC() call. At some point later in the program, you'll have to issue SQLMORERESULTS() to determine if processing is still running, terminated normally, or terminated in an error condition.<br><br>I hope this helps.<br>
K_hoona, you are correct about async, but I think they're saying that apparently the <b>server</b> code is not continuing, not the VFP code (in async mode, VFP code continues to run even before the server finishes executing the SQLEXEC).<br><br>How are you calling the SP? Are you using the ODBC <font color=blue><FONT FACE=monospace>{CALL My_SP}</font></font> method? <p>Robert Bradley<br><a href=mailto: > </a><br><a href= - Visual FoxPro Development</a><br>
Guest_imported
New member
- Jan 1, 1970
- 0
Unfortunately, the connection Asynchronous setting has made no difference in terms of the handling behavior of RAISERROR in the SQL7 stored procedure. We wanted the stored procedure on the SQL Server to continue execution after a RAISERROR (which using SQL7 Query Analyzer works perfectly fine) but VFP seems to close the connection right after the RAISERROR is received from the stored procedure.<br><br>All transactions are controlled within the stored procedure and is not handle by the VFP application, at this point of the development and point of design, it is not an option to move the transaction handling logic from the Server to the client program.<br><br>LC
Guest_imported
New member
- Jan 1, 1970
- 0
Robert,<br><br>Thanks for the reply again. Yes, we have tried using both the EXEC MySP and {CALL MySP} as the lcSQLString and neither is working properly with RAISERROR.<br><br>LC
Guest_imported
New member
- Jan 1, 1970
- 0
There has been a new development in the RAISERROR problem we were having. Contrary to what we thought was happening before, SQL code after a RAISERROR was indeed being executed as expected. However, the problem is no SELECT results is being returned to VFP, although the SQL Profiler shows the code being executed.<br><br>CREATE PROCEDURE TEST AS<br><br>RAISERROR (....) <br>SELECT author_id FROM authors<br><br>When this is being called from VFP, no data is being returned.
But you wouldn't want any data returned if there is an error. It seems the behavior is the (normally) desirable one.<br><br>If you have an "abnormal" requirement, consider using a return value rather than RaiseError; you could encode some special flag or whatever in the return value. <p>Robert Bradley<br><a href=mailto: > </a><br><a href= - Visual FoxPro Development</a><br>
- Status
Similar threads
