Yes, I would think that it is possible.

However, can't really say much more without knowing more about what the actual tables look like and the data within - along with...

Rajesh... Your method is a sure recipe for disaster. I would be very interested if you would want to (if possible) share the reasons and motifs that forces you to shell...

The Agent acoount is only used if it is a job that runs xp_cmdshell. If you run it from QA, it is the SQL Server service account. So, it depends...

Yes, you have written two select statements, so there will always be two resultsets returned (with or without rows)

If this is an exclusive case, meaning that you'll always have one...

Dunno really. Could depend on how the function is written or how you are actually calling it, or that there are some typos somewhere else around the code..? Unfortunately we...

Your reader is probably confused because of the '...rows affected' message that is returned first. To fix this, add as the first thing in your proc

<code>

AS

SET NOCOUNT ON

Declare...

No, he can't. As written it won't make any difference.

Though Phil is correct - BOL will explain why this whole naming scheme is unnecessary for local temptables. Just stating...

It seems a very awkward way shelling out to xp_cmdshell and osql only to generate the next number in a sequence.. (although I can appreciate your intentions

Well, humiliation wasn't intended

Anyways, short answer to prob 1 is - you can't. Can't update an identity - period. What you could do,...

Also, an example of the table with a few rows of data and the desired result would be helpful...

/Kenneth

So much fuzz in vain... and what if the users (who has access) fires up profiler and there sees the entire (decrypted) procedure when it's executed..

First problem: No you don't want to do that..

Assuming that ID is the primary key? It should *not* have any meaning, especially since...

Good choice!

The only place where (imo) select * is 'allowed' is in conjuntion with EXISTS / NOT EXISTS clauses. eg WHERE EXISTS (...

Can also do with a derived table - step1 inside and step2 outside.

select x.set_id, x.maxDAte, z.col1, z.col2...

from  (

        select set_id, max(entrydate) as maxDate

        from myTable

        group by set_id

      ) x

join    myTable z

on     ...

Nope, got no clue.

Is it giving you a problem, or just curious? Perhaps you better as the question in a new thread, it will be easier for others to pick...