What are cursors?
Cursors allow row-by-row processing of the result sets.
Explain different types of
cursors.
Types of cursors: Static, Dynamic, Forward-only, Keyset-driven.
See books online for more information.
What are the disadvantages of
cursors? How can you avoid cursors?
Disadvantages of cursors: Each time you fetch a row
from the cursor, it results in a network roundtrip, where as a
normal SELECT query makes only one rowundtrip, however large the
resultset is. Cursors are also costly because they require more
resources and temporary storage (results in more IO operations).
Furthere, there are restrictions on the SELECT statements that
can be used with some types of cursors.
Most of the times, set based operations can be used instead of
cursors. Here is an example:
If you have to give a flat hike to your employees using the
following criteria:
Salary between 30000 and 40000 -- 5000 hike
Salary between 40000 and 55000 -- 7000 hike
Salary between 55000 and 65000 -- 9000 hike
In this situation many developers tend to use a cursor,
determine each employee's salary and update his salary according
to the above formula. But the same can be achieved by multiple
update statements or can be combined in a single UPDATE
statement as shown below:
UPDATE tbl_emp SET salary =
CASE WHEN salary BETWEEN 30000 AND 40000 THEN salary + 5000
WHEN salary BETWEEN 40000 AND 55000 THEN salary + 7000
WHEN salary BETWEEN 55000 AND 65000 THEN salary + 10000
END
Another situation in which developers tend to use cursors: You
need to call a stored procedure when a column in a particular
row meets certain condition. You don't have to use cursors for
this. This can be achieved using WHILE loop, as long as there is
a unique key to identify each row. For examples of using WHILE
loop for row by row processing, check out the 'My code library'
section of my site or search for WHILE.
Write down the general syntax
for a SELECT statements covering all the options.
Here's the basic syntax:
SELECT select_list
[INTO new_table_]
FROM table_source
[WHERE search_condition]
[GROUP BY group_by_expression]
[HAVING search_condition]
[ORDER BY order_expression [ASC | DESC] ]
What is a join and explain different types of joins.
Joins are used in queries to explain how different tables are
related. Joins also let you select data from a table depending
upon data from another table.
Types of joins: INNER JOINs, OUTER JOINs, CROSS JOINs. OUTER
JOINs are further classified as LEFT OUTER JOINS, RIGHT OUTER
JOINS and FULL OUTER JOINS.
Can you have a nested transaction?
Yes, very much. Check out BEGIN TRAN, COMMIT, ROLLBACK, SAVE
TRAN and @@TRANCOUNT
What is an extended stored procedure?
An extended stored procedure is a function within a DLL
(written in a programming language like C, C++ using Open Data
Services (ODS) API) that can be called from T-SQL, just the way
we call normal stored procedures using the EXEC statement. See
books online to learn how to create extended stored procedures
and how to add them to SQL Server.
Can you instantiate a COM
object by using T-SQL?
Yes, you can instantiate a COM (written in languages like VB,
VC++) object from T-SQL by using sp_OACreate stored procedure.
Also see books online for sp_OAMethod, sp_OAGetProperty,
sp_OASetProperty, sp_OADestroy. For an example of creating a COM
object in VB and calling it from T-SQL, see 'My code library'
section of this site.
What is the system function to get the current user's user
id?
USER_ID(). Also check out other system functions like
USER_NAME(), SYSTEM_USER, SESSION_USER, CURRENT_USER, USER,
SUSER_SID(), HOST_NAME().
What are triggers? How many triggers you can have on a table?
How to invoke a trigger on demand?
Triggers are special kind of stored procedures that get
executed automatically when an INSERT, UPDATE or DELETE
operation takes place on a table.
In SQL Server 6.5 you could define only 3 triggers per table,
one for INSERT, one for UPDATE and one for DELETE. From SQL
Server 7.0 onwards, this restriction is gone, and you could
create multiple triggers per each action. But in 7.0 there's no
way to control the order in which the triggers fire. In SQL
Server 2000 you could specify which trigger fires first or fires
last using sp_settriggerorder
Triggers can't be invoked on demand. They get triggered only
when an associated action (INSERT, UPDATE, DELETE) happens on
the table on which they are defined.
Triggers are generally used to implement business rules,
auditing. Triggers can also be used to extend the referential
integrity checks, but wherever possible, use constraints for
this purpose, instead of triggers, as constraints are much
faster.
Till SQL Server 7.0, triggers fire only after the data
modification operation happens. So in a way, they are called
post triggers. But in SQL Server 2000 you could create pre
triggers also. Search SQL Server 2000 books online for INSTEAD
OF triggers.
There is a trigger defined for INSERT operations on a table, in
an OLTP system. The trigger is written to instantiate a COM
object and pass the newly insterted rows to it for some custom
processing. What do you think of this implementation? Can this
be implemented better?
Instantiating COM objects is a time consuming process and since
you are doing it from within a trigger, it slows down the data
insertion process. Same is the case with sending emails from
triggers. This scenario can be better implemented by logging all
the necessary data into a separate table, and have a job which
periodically checks this table and does the needful.
What is a self join? Explain it with an example.
Self join is just like any other join, except that two instances
of the same table will be joined in the query. Here is an
example: Employees table which contains rows for normal
employees as well as managers. So, to find out the managers of
all the employees, you need a self join.
CREATE TABLE emp
(
empid int,
mgrid int,
empname char(10)
)
INSERT emp SELECT 1,2,'Vyas'
INSERT emp SELECT 2,3,'Mohan'
INSERT emp SELECT 3,NULL,'Shobha'
INSERT emp SELECT 4,2,'Shridhar'
INSERT emp SELECT 5,2,'Sourabh'
SELECT t1.empname [Employee], t2.empname [Manager]
FROM emp t1, emp t2
WHERE t1.mgrid = t2.empid
Here's an advanced query using a LEFT OUTER JOIN that even
returns the employees without managers (super bosses)
SELECT t1.empname [Employee], COALESCE(t2.empname, 'No manager')
[Manager]
FROM emp t1
LEFT OUTER JOIN
emp t2
ON
t1.mgrid = t2.empid |