###BeginCaseStudy###
Case Study: 2
Scenario 2
Application Information
You have two servers named SQL1 and SQL2 that have SQL Server 2012 installed.
You have an application that is used to schedule and manage conferences.
Users report that the application has many errors and is very slow.
You are updating the application to resolve the issues.
You plan to create a new database on SQL1 to support the application. A junior database
administrator has created all the scripts that will be used to create the database. The script that
you plan to use to create the tables for the new database is shown in Tables.sql. The script
that you plan to use to create the stored procedures for the new database is shown in
StoredProcedures.sql. The script that you plan to use to create the indexes for the new
database is shown in Indexes.sql. (Line numbers are included for reference only.)
A database named DB2 resides on SQL2. DB2 has a table named SpeakerAudit that will
audit changes to a table named Speakers.
A stored procedure named usp_UpdateSpeakersName will be executed only by other stored
procedures. The stored procedures executing usp_UpdateSpeakersName will always handle
transactions.
A stored procedure named usp_SelectSpeakersByName will be used to retrieve the names of
speakers. Usp_SelectSpeakersByName can read uncommitted data.
A stored procedure named usp_GetFutureSessions will be used to retrieve sessions that will
occur in the future.
Procedures.sql
Indexes.sql
Tables.sql
###EndCaseStudy###
You need to ensure that if any of the statements in usp_UpdateSpeakerName return an
error message, all of the changes executed by usp_UpdateSpeakerName are not committed
to the database.
What should you do in Procedures.sql? (Each correct answer presents part of the solution.
Choose all that apply.)
A.
Option A
B.
Option B
C.
Option C
D.
Option D
E.
Option E
Wouldn’t it be A and E?
No the transaction must have a Name so it is B & D
There is no commit so when there is no error in try B & D will end with error
Msg 266, Level 16, State 2, Procedure usp_updatespekaername, Line 0
Transaction count after EXECUTE indicates a mismatching number of BEGIN and COMMIT statements. Previous count = 0, current count = 1.
alter procedure usp_updatespekaername
as
begin try
begin tran a
SELECT ‘foobar’
end try
begin catch
rollback tran a
end catch
go
exec usp_updatespekaername
In my opinion it should be C and D.
The scenario says:
A stored procedure named usp_UpdateSpeakersName will be executed only by other stored
procedures. The stored procedures executing usp_UpdateSpeakersName will always handle
transactions.
So our procedure usp_UpdateSpeakersName will always be called within transaction started eralier, like this:
begin tran
exec usp_UpdateSpeakersName
commit tran
and now we have to ensure that:
if any of the statements in usp_UpdateSpeakerName return an
error message, all of the changes executed by usp_UpdateSpeakerName are not committed
to the database.
but the rest of the transation should be commited. So in case of an error inside our procedure only the changes made inside that procedure must be rolled back.
See the example:
The following example shows how to use a transaction savepoint to roll back only the modifications made by a stored procedure if an active transaction is started before the stored procedure is executed.
https://msdn.microsoft.com/en-us/library/ms188378.aspx#Anchor_4
Agree/ it’s C and D
Absolutely, C & D!!
http://www.blackwasp.co.uk/SQLSavepoints.aspx