The transaction simply means that any changes are all committed at the same time. If you encounter a non-batch aborting error then any prior changes (and any that occur afterwards) will still be committed when you reach the COMMIT.
For example, take the following table and sample data:
CREATE TABLE dbo.SomeTable (ID int IDENTITY(1,1),
SomeDate date,
SomeString varchar(3));
GO
INSERT INTO dbo.SomeTable (SomeDate, SomeString)
VALUES(GETDATE(),'abc'),
(GETDATE(),'def'),
(GETDATE(),'ghi');
GO
Now I'm going to DELETE and INSERT 2 rows, effecting 1 row with each operation inside a transaction. In one I'll provide an invalid date, an aborting error, and in the other a value that will cause truncation, a non-aborting error:
BEGIN TRANSACTION
DELETE FROM dbo.SomeTable
WHERE ID = 1
INSERT INTO dbo.SomeTable (SomeDate, SomeString)
VALUES('20231301','xyz')
COMMIT;
GO
BEGIN TRANSACTION
DELETE FROM dbo.SomeTable
WHERE ID = 2
INSERT INTO dbo.SomeTable (SomeDate, SomeString)
VALUES('20231201','mnop');
COMMIT;
GO
Notice the results you get back; ID 1 remains (batched aborted) but ID 2 doesn't (batch wasn't aborted):
| ID |
SomeDate |
SomeString |
| 1 |
2023-08-04 |
abc |
| 3 |
2023-08-04 |
ghi |
| 4 |
2023-08-04 |
jkl |
If you want the transaction to be aborted when an error is encountered then use XACT_ABORT:
SET XACT_ABORT ON;
BEGIN TRANSACTION
DELETE FROM dbo.SomeTable
WHERE ID = 3
INSERT INTO dbo.SomeTable (SomeDate, SomeString)
VALUES('20231301','xyz')
COMMIT;
GO
SET XACT_ABORT ON;
BEGIN TRANSACTION
DELETE FROM dbo.SomeTable
WHERE ID = 4
INSERT INTO dbo.SomeTable (SomeDate, SomeString)
VALUES('20231201','mnop');
COMMIT;
GO
Notice that ID 4 is not DELETEd now too.