>>Naomi, one thing I'm sure about, TRY...CATCH came out in SQL 2005.
>>
>>I never used VFP and SQL together in any serious way until either VFP8 or VFP9.....but truthfully, I'd be a bit surprised if VFP 6 could handle any of the exception handling that was in SQL Server from 2005 on (and maybe even going back to SQL 2000).
>>
>>I could be wrong - but I'd be surprised (and impressed) if VFP 6 could handle any of it.
>
>Back in the dawn of time (about 20 years ago, dang I'm old!), I wrote an application in VFP 3 that got ported up to 6 and then to VFP 9. During its life, it also had modifications done to it so other areas within the department could use it. Iirc, when it went from VFP 3 to VFP 6 was when I converted from a VFP backend to an SQL backend. Again, dawn of time and I've slept (a lot) since then, but I seem to remember using RAISERROR to 1) handle the error within SQL (depending on the error) and 2) send an error number back to VFP.
>
>Again, this was a few years ago, but I'm pretty sure (85% +) of this, since the app spent many, many years in VFP 6 and the port to 9 was primarily just a recompile.

Hey Doris

I attempted a simple THROW and then a raiseError (grrrrr - spelling check much Microsoft?) and it was not giving me consistent sqlexec -1 return values, nor even aerror content. Also - I was building the entire structure as a Dynamic SQL, not in a sproc. Using Fox's own functions work well.

I did

BEGIN TRY
BEGIN TRANSACTION
EXECUTABLE COMMAND such as SELECT 1/0
COMMIT TRANSACTION
END TRY
BEGIN CATCH
IF @@TRANCOUNT>0
ROLLBACK TRANSACTION
THROW
END CATCH

Many times there was only a sqlexec return value of 1 and no aerror. It isn't even a simple fix it across the board. They have done a requery, then scan the results, alter them, which causes a duplicate record upon leaving the record.

Working with something like MaxFrame really compartmentalizes the code, so this kind of insanity is not easy to do.