Yeah, this was one of the first things checked actually... I ran my test
connection. If you would like more details on the conditions of the test
of my library. My library is also publicly available off my schools CS
> Just one more thought...
>
> I tend to use Profiler in these situations. To the best of my knowledge,
> SCOPE_IDENTITY will provide correct information if you execute it after
> the insert and on the same connection (but watch out if the table has
> INSTEAD OF triggers). And with Profiler you can clearly see whether the
> INSERT and the SCOPE_IDENTITY is executed on the same connection.
>
> --
> Tibor Karaszi, SQL Server MVP
>
http://www.karaszi.com/sqlserver/default.asp >
http://www.solidqualitylearning.com/ > Blog:
http://solidqualitylearning.com/blogs/tibor/ >
>
> "David Gugick" <david.gugick-nospam@quest.com> wrote in message
> news:Osu11EGNGHA.3944@tk2msftngp13.phx.gbl...
>> Carlo Razzeto wrote:
>>> "David Gugick" <david.gugick-nospam@quest.com> wrote in message
>>> news:%23F$cDt5MGHA.2040@TK2MSFTNGP14.phx.gbl...
>>>> Carlo Razzeto wrote:
>>>>> "Damien" <Damien_The_Unbeliever@hotmail.com> wrote in message
>>>>> news:1140077665.238760.196360@g43g2000cwa.googlegroups.com...
>>>> That SQL Statement I believe would fail
>>>> "SET @DBProvider_last_auto_id = CAST(SCOPE_IDENTITY() AS INT )"
>>>>
>>>> What were you trying earlier? What does the @@IDENTITY-style
>>>> statement look like? Have you tried simply using SELECT
>>>> SCOPE_IDENTITY() and processing it as a result set and not as an
>>>> ExecuteNonQuery? --
>>>> David Gugick - SQL Server MVP
>>>> Quest Software
>>>>
>>>
>>> I have a quick question... I just read something off the google cache
>>> which I've been suspecting might be the case with me... A poster to a
>>> particular forum was having the same trouble that I am... I.E. on the
>>> same connection, issuing an insert query, then issueing the SELECT
>>> SCOPE_IDENTITY() and getting back null every single time. That poster
>>> found the only way to get scope_identity to work for him was to issue
>>> the query in the same command as the insert and use ExecuteScalar().
>>> The conclusing he and another gentalman came to was that some how the
>>> SELECT statement was being issued in a different scope than the
>>> INSERT statement. So what I'm wondering here is... What exactly is
>>> the scope of SCOPE_IDENTITY()? Is there a way someone can insure two
>>> consecitiive queries are issued in the same scope in this type of
>>> senario? I've tested out connecting to a specific database, and that
>>> didn't help... But at this point, I'm almost positive that some how,
>>> the scope of the select command isn't considered to be the same as
>>> the insert command dispite the fact that I'm using the same command
>>> object and connection. There really seems to be very little
>>> documentation with regard to what exactly the scope of scope_identity
>>> is....
>>
>> "A scope is a module -- a stored procedure, trigger, function, or batch."
>>
>> I haven't tried this from ADO.Net just now. But whenever I've used the
>> function in the past it has always been from within the stored procedure
>> I'm calling. I've never actually made the call to SCOPE_IDENTITY() in a
>> separate ADO command. I can tell you that from QA, I can issue a call to
>> SCOPE_IDENTITY() in another batch and still get back a valid result.
>>
>> What I meant earlier about a result set was that your code was calling
>> ExecuteNonQuery which does not process result sets and your SELECT
>> SCOPE_IDENTITY() is a result set. But it appears you've tried this and it
>> didn't work.
>>
>> Are you using stored procedures? If so, put the call the SCOPE_IDENTITY()
>> in the procedure and "return" the result using an OUTPUT parameter to the
>> procedure. For example:
>>
>> Create Proc dbo.Whatever (
>> @MyVal int,
>> @NewID int output )
>> as
>> begin
>> insert into dbo.MyTable (MyVal) Values (@MyVal)
>> Set @NewID = SCOPE_IDENTITY()
>> end
>> go
>>
>> Declare @NewID int
>> Exec dbo.Whatever(50, @NewID OUTPUT)
>> Select @NewID
>>
>> From ADO, you would declare the @NewID parameter as an input/output or
>> just output.
>>
>>
>> --
>> David Gugick - SQL Server MVP
>> Quest Software
>>
>