Wow... can you explain the logic of this one??

WOW... always another way .

CREATE TABLE #xyzout ...

Insert into #xyzout (FieldName) EXECUTE master..xp_cmdshell 'xyz.exe

Select * from #xyzout

This will help you :

Dynamic Search Conditions in T-SQL

#5 is about the same as #3...

It depends only on the other params of the insert... if they are static, then I'd go with #3, else #5.

You can't return something else than an interger in a stored proc. You'll have to use either a function or an output parameter in the proc.

Sounds like a good plan... except for the part where the history of the table is kept in the master table. I can't imagine having to go through millions...

What code gives you the error?

Not really, the simple version :

Declare @Par as varchar(10)

Declare @Return as varchar(10)

Declare @Int as int

set @Par = '123456-01'

set @Int = CAST(right(@Par, 2) AS INT)

set @Int = @Int - 1

set @Return...

run sp_updatestats on the server to update the statistics, then recompile the proc.

If it happens again, post back on this board with the keywords parameter sniffing, and we'll be able...

How did you execute it in QA

Did you manually set the parameters' value?

Always a good quality in a query .

Well in that case... The safest way to handle this is too create a table with a single line with a flag.

When the trigger is called, update the flag...

I'm assuming that this is the id of the table.

I would split the id in 2 columns like :

order id = 123456

item number = 1

Am I understanding your situation...

You don't have access to the application and need to have it modified outside of your office?