that is what I *am* doing! X and Y are in a SP with NO TRY BLOCK

but the CALLING procedure IS using a TRY block and therefore breaks the tested and working logic

my very first post explains this with working code

what MS has done is a complete mess, I have described the correct approach that they should have taken

which would allow procedures both with and without TRY blocks to work together perfectly, which I will explain again:

for code in a procedure that is outside of a LOCAL TRY block

that procedure *should* behave as it was written - no modification to existing behaviour

whether or not the CALLING procedure is using a LOCAL TRY block or not

IF the calling procedure IS using a LOCAL TRY block and calls a procedure which returns with @@error <> 0

(and severity level > 10) THEN control should be passed to the CATCH block

that is the correct, predictable and reliable way to implement it

I doubt Microsoft would have made such a terrible mistake without reason - maybe there is some insurmountable

hurdle to implementing it correctly - and they had no choice - who knows

but the purpose of my post is to warn people - beware - this behaviour is not what the majority of developers would expect

and WILL CATCH YOU OUT (no pun intended) especially if you have an existing library of stored procedures that WILL BREAK if they are called with a call stack that includes a TRY block at any level

you can not simply convert a SQL 2000 database to SQL 2005 and expect to get away with it

the only safe approach is to rewrite ALL existing stored procedures to work whether called within a TRY block or not ...

Is that common knowledge or not?

If it is common knowledge please supply a link to an explanation and I apologise

Otherwise please thank me for pointing it out

But please don't miss the point