Recently I inherited a new ASP web application that merely allows customers to pay their outstanding invoices online. The application was poorly designed and did not have a payment history table. The entire payments table was deleted by the web service that transports the payment records to the accounting system of record.
I just created a simple trigger on the Payments table that simply copies the data from the Payments table into a Payment_Log table. Initially, the trigger just did a select * on inserted to copy the data. However, I just modified the trigger to insert the date of the payment into the Payment_Log table since one of our customers is having some issues that I need to debug. The new trigger is below. My question is that I have noticed that with this new version of the trigger, the rows are being inserted into the middle of the table (i.e. not at the end). Can someone explain why this is happening?
ALTER trigger [dbo].[PaymentHistory] on [dbo].[Payments]
for insert as
Declare @InvoiceNo nvarchar(255),
@CustomerName nvarchar(255),
@PaymentAmount float,
@PaymentRefNumber nvarchar(255),
@BulkPaid bit,
@PaymentType nvarchar(255),
@PaymentDate datetime
Select @InvoiceNo = InvoiceNo,
@CustomerName = CustomerName,
@PaymentAmount = PaymentAmount,
@PaymentRefNumber = PaymentRefNumber,
@BulkPaid = BulkPaid,
@PaymentType = PaymentType
from inserted
Set @PaymentDate = GETDATE()
Insert into Payment_Log
values (@InvoiceNo, @CustomerName, @PaymentAmount, @PaymentRefNumber, @BulkPaid, @PaymentType, @PaymentDate)
Below is a screenshot of SQL Server Management Studio that shows the rows being inserted into the middle of the table data. Thanks in advance for the help guys.

Datasets don’t have an order. This means that
SELECT * FROM xcan return the results in a different order every time.The only time that data is guaranteed to come back in the same order is when you specify an
ORDER BYclause.That said, there are circumstances that make the data normally come back in a certain order. The most visible one is with a clustered index.
This makes me wonder if the two tables have a Primary Key or not. Check all the indexes on each table and, at the very least, enforce a Primary Key.
As an aside, triggers in SQL Server are not fired for each row, but each batch. This can mean that the
insertedtable can contain more than just one row. (For example, when bulk inserting test data, or re-loading a large batch of transactions.)For this reason, copying the data into variable is not a standard practice. Instead, you could just do the following…