>Well, Charles, I'm glad you asked that question
>
>It seems somewhere between 2006 when even Ander Altberg was giving completely wrong answers to this question, insisting on not understanding the differences between remote views and SPT or suggesting going for @@identity with the known problems with triggers, there is a value IDENT_CURRENT(tablename) which gives you exactly what you need.

We're using SELECT @@IDENTITY right after the statement, but we use this only on the tables that don't have triggers. I don't like this solution much, but I don't see a better alternative. IDENT_CURRENT has its own problems.


>
>Since you are known to be somewhat senile and will probably ask this question again I hope you will find this useful when you search for it.
>
>( but my , you are looking good ... )
>
>>Feel like somebody here knows the answer to this :
>
>>
>>If I send an update to the backend with SPT I can pull back the SCOPE_IDENTITY() so I can set the FKs in children before I save them.
>>
>>But if I am calling Tableupdate() the SPT is created for me from the remote view and I haven't figured out how to get back the PK of the record just added.
>>
>>My framework uses remote views and ultimately Tableupdate() to insert a new record on the back end. Is there a way to get the remote views themselves to return the pk value?
>>
>>Once the tableupdate() returns true or false I no longer can send SPT that will see SCOPE_IDENTITY(). Do I need to munge up something with a candidate key generated on the front end in order to get back the pk of the record just inserted?
>>
>>Remember, these are remote views. I understand how to do it in SPT but the tableupdate doesn't provide a place I can see to ask for scope_identity in the same scope.
>>
>>TIA