INSERTED Table - When it gets populated with single or multiple rows?

Question

Hi,
I'm trying to create a trigger which then insert to a table. i'm wondering when does the INSERTED table gets populated with single or multiple rows?
Should I always assume that the INSERTED Table will contains several rows? What does the scope of the INSERTED table in the trigger, isn't based on the user session?
 The reason why i asked this is because as far as i know inserted table may contain several table when the trigger fires which is why I use cursor to insert  records in the table ( there's a behind why i use cursor).
But if the inserted table will only contain a single record during the session of the trigger then i can avoid the cursor.
Thanks.

Answer 1

But since we control the transaction process and we know for a fact that user will only be able to save a record one at a time, do we still expect multiple rows? I just want to have a clear concept on the INSERTED table.
...and then the DBA or someone else sees fit to enter a number of rows directly from a query window. And don't laugh. That is bound to happen sooner or later.
However, just because this can (and will) happen does not mean that you need to handle it on equal footing with the normal case user entering data through the application. What you cannot permit yourself to is to drop the DBA case on the floor, that is write
the trigger as if there would either be single-row inserts and produce incorrect results for multi-row inserts.
But, yes, allowing yourself to use a cursor, if you want to reuse the existing stored procedure is feasible. That is also the more drastic solution suggested by Tom to add an explicit check that disallows multi-row inserts.
Finally, permit me to comment on this:
Additionally, it's  difficult to use the code below as i need to pass the identity id of tbl_A to tbl_B
You can use the OUTPUT clause to capture the values, but that requires that you have something you can map the identity values to in the columns you insert, and this is not always the case. However, there is a lot simpler solution to the problem: don't
use IDENTITY. IDENTITY is one of these over-used and over-abused features in SQL Server. You need it when you want to support high-concurrency inserts, because rolling your own requires a serialisation point. But with a moderate insertion frequency, IDENTITY
only gives you headache.
Erland Sommarskog, SQL Server MVP, [email protected]