Diwali Deal : Flat 20% off + 2 free self-paced courses + $200 Voucher - SCHEDULE CALL
Ans: The BEGIN TRANSACTION statement specifies the start of a transaction. When you use BEGIN TRANSACTION on a database connection, the Database Engine attempts to include all subsequent operations within the same transaction. The syntax for the BEGIN TRANSACTION statement is as follows:
BEGIN { TRAN | TRANSACTION } [ { transaction_name | @tran_name_variable } [ WITH MARK [ 'description' ] ] ]
In this statement, you can specify a name for the transaction using the transaction name or @tran_name_variable. Additionally, you can add a description to the transaction log, which is useful if you want to restore the database table to a specific point in time. You can learn SQL online by completing an online SQL certification.
Ans: Once you have called BEGIN TRANSACTION and performed DML (Data Manipulation Language) operations, you will want to conclude your transaction by either saving (committing) your changes or undoing them (rolling back) in case of an error. To make the changes permanent, use the following syntax in your COMMIT TRANSACTION statement:
COMMIT { TRAN | TRANSACTION } [ transaction_name | @tran_name_variable ]
Here's an example of a single explicit transaction containing two DML statements (an UPDATE and an INSERT):
BEGIN TRANSACTION UPDATE Table1 SET Column1 = 'One' INSERT INTO Table2 (Column2) VALUES ('Two') COMMIT
Ans: The @@TRANCOUNT function is used in SQL Server to return the number of active transactions for the current connection. It allows you to determine the current transaction count. The @@TRANCOUNT value increases by one every time you call BEGIN TRANSACTION. If you call BEGIN TRANSACTION within a transaction block, @@TRANCOUNT will also increase accordingly. Similarly, SQL Server decrements @@TRANCOUNT by one every time you call COMMIT TRANSACTION. The transaction remains active until @@TRANCOUNT returns to zero. When you call BEGIN TRANSACTION within an existing transaction, you create a nested transaction. However, understanding nested transactions in SQL Server requires consideration of scenarios where you want changes to be undone (rather than permanently saved) when an error occurs. For further understanding, you can explore this topic through online SQL certification courses.
Ans: If you do not want the changes to be permanent and instead want to revert the database to its previous state, you can use the ROLLBACK TRANSACTION T-SQL statement with the following syntax:
ROLLBACK { TRAN | TRANSACTION } [ transaction_name | @tran_name_variable | savepoint_name | @savepoint_variable ]
Ans: The COMMIT statement saves all transactional changes, making them permanent, whereas the ROLLBACK statement reverses all transactional changes, effectively undoing them. It is essential to explicitly issue either COMMIT or ROLLBACK in SQL Server, as it never assumes a COMMIT. If you disconnect from the server without explicitly committing the transaction, SQL Server will implicitly perform a ROLLBACK. To ensure that your desired action is taken, you should always specify COMMIT or ROLLBACK explicitly. Additionally, there are cases where SQL Server will automatically roll back a transaction if a severe error occurs during its execution. Errors with a severity level of 11 or higher will halt the current batch's execution and trigger a rollback. Errors with a severity level of 19 or higher will cause the connection to be terminated. To avoid ambiguity, it is advisable to explicitly call ROLLBACK if an error occurs. Another difference between COMMIT and ROLLBACK is that COMMIT TRANSACTION decreases @@TRANCOUNT by one, while ROLLBACK TRANSACTION always reduces @@TRANCOUNT to zero. To understand how to undo all modifications following the last COMMIT, consider enrolling in an online SQL certification course.
Ans: Nested transactions occur when you have one transaction block (BEGIN TRANSACTION) within another. However, it is essential to understand that nested transactions in SQL Server do not behave like traditional nested transactions. When you roll back a nested transaction, SQL Server rolls back to the most recent BEGIN TRANSACTION statement, reducing @@TRANCOUNT to 0. In this context, ROLLBACK takes precedence over COMMIT. This behavior is unique to SQL Server and can be considered a form of nested transactions.
Ans: Savepoints are essential in transactions, allowing you to temporarily store portions of a transaction and roll back specific parts instead of the entire transaction. Savepoints are defined using the SAVE TRANSACTION statement, which has the syntax:
SAVE { TRAN | TRANSACTION } { savepoint_name | @savepoint_variable }
Ans: When you invoke SAVE TRANSACTION during a transaction, you create a point to which you can roll back without losing everything. For example:
BEGIN TRANSACTION INSERT INTO TEST (TestColumn) VALUES (1) SAVE TRANSACTION SAVEPOINT1 INSERT INTO TEST (TestColumn) VALUES (2) ROLLBACK TRANSACTION SAVEPOINT1 COMMIT
In this code, you insert a row and create a savepoint called SAVEPOINT1. Then, you insert again, but you can roll back to the savepoint without losing the first insert because of the savepoint set before the second insert.
Ans: Implicit connection mode automatically saves changes when you use SSMS (SQL Server Management Studio) or SQL Server Data Tools (SSDT) to connect to a database and execute a DML query. By default, the connection is set to autocommit transaction mode. To set the connection to implicit transaction mode (or unset it), you can use the following syntax:
SET IMPLICIT_TRANSACTIONS {ON | OFF}
In implicit mode, a transaction is started implicitly without using a BEGIN TRANSACTION statement. You must explicitly commit or rollback the transaction to save or discard the changes.
Ans: In implicit connection mode, executing any of the following statements while the connection is not in a transaction will not commit the changes automatically: ALTER TABLE, CREATE, DELETE, DROP, FETCH, GRANT, INSERT, OPEN, REVOKE, SELECT, TRUNCATE TABLE, or UPDATE. Instead, the implicit transaction mode prevents the transaction from being committed or rolled back unless explicitly requested. If you issue an UPDATE statement, the affected data remains locked until you issue a COMMIT or ROLLBACK statement. If a user disconnects without issuing a COMMIT or ROLLBACK, the transaction is rolled back.
It is best to avoid configuring a highly concurrent database with implicit transaction mode to prevent unintentional locking of resources. Implicit transaction mode can be suitable for data warehouses where read-only access is needed, and modifying data should be avoided.
Ans: Batch-Scoped Transaction Mode refers to the state when multiple active result sets (MARS) are supported on the same connection. MARS allows multiple interleaved batches of commands to execute simultaneously, but the execution of commands is still sequential. Batch-Scoped Transaction Mode is associated with MARS connections, containing various components that define the environment in which commands run. Transactions within MARS connections are scoped to the particular batch until its execution is complete.
Ans: MARS allows for multiple interleaved batches of commands to run simultaneously on the same connection. However, MARS does not support multiple transactions on the same connection; it only supports multiple active result sets. The execution of commands is still sequential and governed by strict interleaving rules, determining which statements can overlap others.
Ans: The MARS interleaving rules govern how commands can be interleaved or blocked when multiple interleaved batches are running on a MARS connection. For instance, a command reading results can be blocked by a command attempting to modify data. However, a read operation cannot block a write operation. Additionally, BULK INSERT statements can prevent other read and write operations from occurring. The rules can lead to complex scenarios, and designing with interleaving rules in mind is crucial when using MARS.
Ans: In MARS, savepoints can cause confusion due to the interleaved execution of commands. When multiple serialized commands are executing, savepoint commands can easily interfere with each other's logic. To avoid such complexities, it is advisable to avoid using savepoints on a MARS connection.
This section has covered the topic of local transaction support in SQL Server, including the concept of MARS and batch-scoped transaction mode. Understanding MARS and transactions' intricacies can help in designing efficient and reliable database systems.
SQL Server MERGE Statement: Question and Answer
SQL CLR Deployment and Error Resolution: Question and Answer
Cyber Security
QA
Salesforce
Business Analyst
MS SQL Server
Data Science
DevOps
Hadoop
Python
Artificial Intelligence
Machine Learning
Tableau
Download Syllabus
Get Complete Course Syllabus
Enroll For Demo Class
It will take less than a minute
Tutorials
Interviews
You must be logged in to post a comment