Newbie question on stored procedures and linked servers

I have a "main" SQL Server 2005 server and several "farm" SQL Servers using
2005.
I'd like to be able to create stored procedures on the main server and run
them from the farm server against the farm server. For example, one stored
procedure would create a database and tables. I'd like it to live on the main
server and create the database and tables on the farm server.
Is this possible? If so, are there any examples available?
John
In general, stored procedures executing on remote servers are restricted
from changed the schema on the remote server. It's a good security
consideration.
Now there are many 'work-a-rounds'. One that I employ is having the 'main'
server create a SQL script file, dropping that in a location available to
the remote server, and then executing a job that looks for file(s) in that
location (perhaps filtered by naming conventions, etc.), and then executes
that script file.
Perhaps if you provided a bit more details about what you are attempting to
accomplish, someone here will have a better solution.
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
"JColaizzi" <JColaizzi@.discussions.microsoft.com> wrote in message
news:009DE414-CED1-4882-B8F6-FA314C8643BE@.microsoft.com...
> I have a "main" SQL Server 2005 server and several "farm" SQL Servers
> using
> 2005.
> I'd like to be able to create stored procedures on the main server and run
> them from the farm server against the farm server. For example, one stored
> procedure would create a database and tables. I'd like it to live on the
> main
> server and create the database and tables on the farm server.
> Is this possible? If so, are there any examples available?
> John
|||"Arnie Rowland" wrote:
> Perhaps if you provided a bit more details about what you are attempting to
> accomplish, someone here will have a better solution.
>
The main server is a data warehouse storing metadata and fact data for
approximately 1000 cubes that have to be produced monthly. The farm servers
are the servers where the cubes will be produced. (We do this now with
Oracle and are moving to SS05.)
I want to avoid having multiple farm servers where if a stored procedure is
changed it has to be propagated to mulitple servers. So in the example above
the stored procedure would accept some variables and create the database and
tables on the farm server that are used to create one of the thousand cubes.
So in essence I want a local server to call a remote server stored procedure
that will create a database and tables on the local server.
John
|||You may wish to look into aspects of schema replication.
With SQL Server 2005, you can replicate Stored Procedures. So you would only
have to manage the main server, and yes, propagation is involved, but it
becomes a background process and part of the database 'system' itself. Not
something that would have to be managed manually.
Calling those replicated 'remote' procedures is, perforce, a normal
operation.
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
"JColaizzi" <JColaizzi@.discussions.microsoft.com> wrote in message
news:3ABDDDF1-C638-4FAA-BBE1-A10581257EED@.microsoft.com...
> "Arnie Rowland" wrote:
> The main server is a data warehouse storing metadata and fact data for
> approximately 1000 cubes that have to be produced monthly. The farm
> servers
> are the servers where the cubes will be produced. (We do this now with
> Oracle and are moving to SS05.)
> I want to avoid having multiple farm servers where if a stored procedure
> is
> changed it has to be propagated to mulitple servers. So in the example
> above
> the stored procedure would accept some variables and create the database
> and
> tables on the farm server that are used to create one of the thousand
> cubes.
> So in essence I want a local server to call a remote server stored
> procedure
> that will create a database and tables on the local server.
> John
sql

Newbie question on stored procedures and linked servers

I have a "main" SQL Server 2005 server and several "farm" SQL Servers using
2005.
I'd like to be able to create stored procedures on the main server and run
them from the farm server against the farm server. For example, one stored
procedure would create a database and tables. I'd like it to live on the mai
n
server and create the database and tables on the farm server.
Is this possible? If so, are there any examples available?
JohnIn general, stored procedures executing on remote servers are restricted
from changed the schema on the remote server. It's a good security
consideration.
Now there are many 'work-a-rounds'. One that I employ is having the 'main'
server create a SQL script file, dropping that in a location available to
the remote server, and then executing a job that looks for file(s) in that
location (perhaps filtered by naming conventions, etc.), and then executes
that script file.
Perhaps if you provided a bit more details about what you are attempting to
accomplish, someone here will have a better solution.
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
"JColaizzi" <JColaizzi@.discussions.microsoft.com> wrote in message
news:009DE414-CED1-4882-B8F6-FA314C8643BE@.microsoft.com...
> I have a "main" SQL Server 2005 server and several "farm" SQL Servers
> using
> 2005.
> I'd like to be able to create stored procedures on the main server and run
> them from the farm server against the farm server. For example, one stored
> procedure would create a database and tables. I'd like it to live on the
> main
> server and create the database and tables on the farm server.
> Is this possible? If so, are there any examples available?
> John|||"Arnie Rowland" wrote:
> Perhaps if you provided a bit more details about what you are attempting t
o
> accomplish, someone here will have a better solution.
>
The main server is a data warehouse storing metadata and fact data for
approximately 1000 cubes that have to be produced monthly. The farm servers
are the servers where the cubes will be produced. (We do this now with
Oracle and are moving to SS05.)
I want to avoid having multiple farm servers where if a stored procedure is
changed it has to be propagated to mulitple servers. So in the example abov
e
the stored procedure would accept some variables and create the database and
tables on the farm server that are used to create one of the thousand cubes.
So in essence I want a local server to call a remote server stored procedure
that will create a database and tables on the local server.
John|||You may wish to look into aspects of schema replication.
With SQL Server 2005, you can replicate Stored Procedures. So you would only
have to manage the main server, and yes, propagation is involved, but it
becomes a background process and part of the database 'system' itself. Not
something that would have to be managed manually.
Calling those replicated 'remote' procedures is, perforce, a normal
operation.
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
"JColaizzi" <JColaizzi@.discussions.microsoft.com> wrote in message
news:3ABDDDF1-C638-4FAA-BBE1-A10581257EED@.microsoft.com...
> "Arnie Rowland" wrote:
> The main server is a data warehouse storing metadata and fact data for
> approximately 1000 cubes that have to be produced monthly. The farm
> servers
> are the servers where the cubes will be produced. (We do this now with
> Oracle and are moving to SS05.)
> I want to avoid having multiple farm servers where if a stored procedure
> is
> changed it has to be propagated to mulitple servers. So in the example
> above
> the stored procedure would accept some variables and create the database
> and
> tables on the farm server that are used to create one of the thousand
> cubes.
> So in essence I want a local server to call a remote server stored
> procedure
> that will create a database and tables on the local server.
> John

Newbie question on stored procedures and linked servers

I have a "main" SQL Server 2005 server and several "farm" SQL Servers using
2005.
I'd like to be able to create stored procedures on the main server and run
them from the farm server against the farm server. For example, one stored
procedure would create a database and tables. I'd like it to live on the main
server and create the database and tables on the farm server.
Is this possible? If so, are there any examples available?
JohnIn general, stored procedures executing on remote servers are restricted
from changed the schema on the remote server. It's a good security
consideration.
Now there are many 'work-a-rounds'. One that I employ is having the 'main'
server create a SQL script file, dropping that in a location available to
the remote server, and then executing a job that looks for file(s) in that
location (perhaps filtered by naming conventions, etc.), and then executes
that script file.
Perhaps if you provided a bit more details about what you are attempting to
accomplish, someone here will have a better solution.
--
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
"JColaizzi" <JColaizzi@.discussions.microsoft.com> wrote in message
news:009DE414-CED1-4882-B8F6-FA314C8643BE@.microsoft.com...
> I have a "main" SQL Server 2005 server and several "farm" SQL Servers
> using
> 2005.
> I'd like to be able to create stored procedures on the main server and run
> them from the farm server against the farm server. For example, one stored
> procedure would create a database and tables. I'd like it to live on the
> main
> server and create the database and tables on the farm server.
> Is this possible? If so, are there any examples available?
> John|||"Arnie Rowland" wrote:
> Perhaps if you provided a bit more details about what you are attempting to
> accomplish, someone here will have a better solution.
>
The main server is a data warehouse storing metadata and fact data for
approximately 1000 cubes that have to be produced monthly. The farm servers
are the servers where the cubes will be produced. (We do this now with
Oracle and are moving to SS05.)
I want to avoid having multiple farm servers where if a stored procedure is
changed it has to be propagated to mulitple servers. So in the example above
the stored procedure would accept some variables and create the database and
tables on the farm server that are used to create one of the thousand cubes.
So in essence I want a local server to call a remote server stored procedure
that will create a database and tables on the local server.
John|||You may wish to look into aspects of schema replication.
With SQL Server 2005, you can replicate Stored Procedures. So you would only
have to manage the main server, and yes, propagation is involved, but it
becomes a background process and part of the database 'system' itself. Not
something that would have to be managed manually.
Calling those replicated 'remote' procedures is, perforce, a normal
operation.
--
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
"JColaizzi" <JColaizzi@.discussions.microsoft.com> wrote in message
news:3ABDDDF1-C638-4FAA-BBE1-A10581257EED@.microsoft.com...
> "Arnie Rowland" wrote:
>> Perhaps if you provided a bit more details about what you are attempting
>> to
>> accomplish, someone here will have a better solution.
> The main server is a data warehouse storing metadata and fact data for
> approximately 1000 cubes that have to be produced monthly. The farm
> servers
> are the servers where the cubes will be produced. (We do this now with
> Oracle and are moving to SS05.)
> I want to avoid having multiple farm servers where if a stored procedure
> is
> changed it has to be propagated to mulitple servers. So in the example
> above
> the stored procedure would accept some variables and create the database
> and
> tables on the farm server that are used to create one of the thousand
> cubes.
> So in essence I want a local server to call a remote server stored
> procedure
> that will create a database and tables on the local server.
> John

Newbie question here - stored procedures

Hi I just installed sql server 2005 for the first time today. Anyways I have a bunch of stored procs from an application i developed on the SQL 2000 server. Anyways I am having a problem with one of my stored procedures.

CREATE PROCEDURE ProvinceRetrieveAdHoc

(@.whereClause VARCHAR(256))

AS

EXEC("SELECT * FROM tblProvince WHERE " + @.whereClause)

RETURN

GO

However this isn't working, I am getting this error:

Incorrect syntax near 'SELECT * FROM tblProvince WHERE '.

Now I am guessing the EXEC statement must have changed, as every stored proc that uses the exec command errors out with this same error. All my other procedures run just fine. Can anyone please tell me how to fix it?

THanks

oh wow nm, i figured it out.. just replaced double quotes with single.sql

Newbie on Triggers

System Sql server 2000

Hi all

I've dipped my toe in stored procedures, I'm now having a look at triggers

If I had 2 tables and I wanted to update table 2 with some data from table
1, every time table 1 has a new entry made in it (e.g. for an audit trail) I
thought I would be able to use a trigger on table 1.

for instance

on insert of new value in table 1 execute a trigger

The trigger gets the value of the newly created primary key in table 1 (the
primary key is generated by Autonumber) and inserts a copy of the primary
key into table 2

I thought the following would work

ALTER TRIGGER update_table2
ON dbo.table1
FOR INSERT AS
begin
declare @.new_key as bigint
set @.new_key = dbo.table1(PK_test_primary_key)

INSERT INTO dbo.table2
(FK_from_table1)
VALUES (@.new_key)
end

unfortunatly I cant read the value of the newly entered primary key from
table 1. I get a message saying PK_test_primary_key doesn't exist in
dbo.table1

does anyone know if what I am trying to achieve is possible, and maybe a
clue as a good way to go about doing it?

many thanks

AndyHi just a bit more...

after some more googling I have found @.@.identity and it seems to give the
identity of the last added record in the table calling the trigger

is this correct, and is it safe to do this i.e.

ALTER TRIGGER update_table2
ON dbo.table1
FOR INSERT AS
begin

INSERT INTO dbo.table2
(FK_from_table1)
VALUES (@.@.identity)
end

I've also been playing with objConn.BeginTrans in my vb6 code and I write
lots of records to table 1 before confirming the transaction. I believe that
the autonumbers are only generated on completion of the transaction, so how
many triggers will be executed (one per transaction or 1 per new record) and
at what time (as the records are written or on compltion of the
transaction)... Will it reliably update table 2 with the correct info from
table 1 if say dozens of additions are made to table 1 from different
sources at the same time...?

I think I worry too much and it seems to work when I test it, but I like to
know what happens when 8-)

thanks again

Andy

"aaj" <a.b@.c.com> wrote in message
news:4028f77b$0$29799$afc38c87@.news.easynet.co.uk. ..
> System Sql server 2000
> Hi all
> I've dipped my toe in stored procedures, I'm now having a look at triggers
> If I had 2 tables and I wanted to update table 2 with some data from table
> 1, every time table 1 has a new entry made in it (e.g. for an audit trail)
I
> thought I would be able to use a trigger on table 1.
> for instance
> on insert of new value in table 1 execute a trigger
> The trigger gets the value of the newly created primary key in table 1
(the
> primary key is generated by Autonumber) and inserts a copy of the primary
> key into table 2
> I thought the following would work
> ALTER TRIGGER update_table2
> ON dbo.table1
> FOR INSERT AS
> begin
> declare @.new_key as bigint
> set @.new_key = dbo.table1(PK_test_primary_key)
> INSERT INTO dbo.table2
> (FK_from_table1)
> VALUES (@.new_key)
> end
> unfortunatly I cant read the value of the newly entered primary key from
> table 1. I get a message saying PK_test_primary_key doesn't exist in
> dbo.table1
> does anyone know if what I am trying to achieve is possible, and maybe a
> clue as a good way to go about doing it?
> many thanks
> Andy|||aaj (a.b@.c.com) writes:
> after some more googling I have found @.@.identity and it seems to give the
> identity of the last added record in the table calling the trigger
> is this correct, and is it safe to do this i.e.
> ALTER TRIGGER update_table2
> ON dbo.table1
> FOR INSERT AS
> begin
> INSERT INTO dbo.table2
> (FK_from_table1)
> VALUES (@.@.identity)
> end

No, this is not the way to go. In a trigger you have access to two
virtual tables, inserted and deleted. inserted holds the rows that
were inserted, and in case of an UPDATE statment, the values after
the update. And deleted holds the values that were removed by a DELETE
or an UPDATE statement.

Beware that trigger fires once by statement, so many rows can be affected
at once.

--
Erland Sommarskog, SQL Server MVP, sommar@.algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||> ALTER TRIGGER update_table2
> ON dbo.table1
> FOR INSERT AS
> begin
> declare @.new_key as bigint
> set @.new_key = dbo.table1(PK_test_primary_key)
> INSERT INTO dbo.table2
> (FK_from_table1)
> VALUES (@.new_key)
> end
Triggers utilize the virtual "inserted" and "deleted" tables. Check
out this article:http://www.sqlteam.com/item.asp?ItemID=3850.|||You should also not that the @.@.identity is not just the last identity
created for that table, it is the last identity created. That makes the
value of @.@.identity sort of unpredictable. The other guys are right that in
the trigger you should use INSERTED and DELETED tables, but if you need to
access the latest identity created within a given stored procedure you can
use SCOPE_IDENTITY().

"aaj" <a.b@.c.com> wrote in message
news:4028fa81$0$29827$afc38c87@.news.easynet.co.uk. ..
> Hi just a bit more...
> after some more googling I have found @.@.identity and it seems to give the
> identity of the last added record in the table calling the trigger
> is this correct, and is it safe to do this i.e.
> ALTER TRIGGER update_table2
> ON dbo.table1
> FOR INSERT AS
> begin
> INSERT INTO dbo.table2
> (FK_from_table1)
> VALUES (@.@.identity)
> end
>
> I've also been playing with objConn.BeginTrans in my vb6 code and I write
> lots of records to table 1 before confirming the transaction. I believe
that
> the autonumbers are only generated on completion of the transaction, so
how
> many triggers will be executed (one per transaction or 1 per new record)
and
> at what time (as the records are written or on compltion of the
> transaction)... Will it reliably update table 2 with the correct info
from
> table 1 if say dozens of additions are made to table 1 from different
> sources at the same time...?
> I think I worry too much and it seems to work when I test it, but I like
to
> know what happens when 8-)
> thanks again
> Andy
>
> "aaj" <a.b@.c.com> wrote in message
> news:4028f77b$0$29799$afc38c87@.news.easynet.co.uk. ..
> > System Sql server 2000
> > Hi all
> > I've dipped my toe in stored procedures, I'm now having a look at
triggers
> > If I had 2 tables and I wanted to update table 2 with some data from
table
> > 1, every time table 1 has a new entry made in it (e.g. for an audit
trail)
> I
> > thought I would be able to use a trigger on table 1.
> > for instance
> > on insert of new value in table 1 execute a trigger
> > The trigger gets the value of the newly created primary key in table 1
> (the
> > primary key is generated by Autonumber) and inserts a copy of the
primary
> > key into table 2
> > I thought the following would work
> > ALTER TRIGGER update_table2
> > ON dbo.table1
> > FOR INSERT AS
> > begin
> > declare @.new_key as bigint
> > set @.new_key = dbo.table1(PK_test_primary_key)
> > INSERT INTO dbo.table2
> > (FK_from_table1)
> > VALUES (@.new_key)
> > end
> > unfortunatly I cant read the value of the newly entered primary key from
> > table 1. I get a message saying PK_test_primary_key doesn't exist in
> > dbo.table1
> > does anyone know if what I am trying to achieve is possible, and maybe a
> > clue as a good way to go about doing it?
> > many thanks
> > Andy|||Jason Sauer (jason.sauer@.fuse.net) writes:
> You should also not that the @.@.identity is not just the last identity
> created for that table, it is the last identity created. That makes the
> value of @.@.identity sort of unpredictable. The other guys are right that
> in the trigger you should use INSERTED and DELETED tables, but if you
> need to access the latest identity created within a given stored
> procedure you can use SCOPE_IDENTITY().

In this particular case @.@.identity is the only choice. scope_identity()
will return NULL, because there have been no inserts into a table
with an identity column in the current scope, that is the trigger.

The only time @.@.identity will not return the right value, is when there
are more than one trigger on the table, and the other trigger executes
first and that trigger too inserts into a table with a identity column.
Maybe not the most likely scenario.

--
Erland Sommarskog, SQL Server MVP, sommar@.algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp

newbie ? about stored procedures

I currently have several sprocs that require a variable which determines
which set of fields get returned. For ex: X returns fields 1, 2, 3 and Y
returns fields 4, 5, 6. When I run the sprocs the appropriate fields show up
in the results window but when I refresh the fields, reguardless of what
variable I used it displays X's fields in the fields window. Can I not create
two datasets running the same sproc using different variables. If not is this
so this something that I'll be able to do in the near future? Any help would
be most appreciated.Hey there,
As far as I know Reporting Services scans the Stored Procedure, caches the
field names and uses those.
Why don't you have your stored procedure return generic colum names such as
"Col1", "Col2", "Col3" and then apply some conditional formatting on those
column headers when they're placed on the report. Something like this:
txtColumn1.Value = IIF(Parameters!MyCondition.Value = "X", "Zip Code",
"Postal Code")
I'm pretty sure that this is by design since Reporting Services needs to
know the column names.
Hopefully I'm on the same page as you...
Ben
"Arly" <Arly@.discussions.microsoft.com> wrote in message
news:045E8DA3-0DA9-4EAE-9A7E-91343815D69D@.microsoft.com...
> I currently have several sprocs that require a variable which determines
> which set of fields get returned. For ex: X returns fields 1, 2, 3 and Y
> returns fields 4, 5, 6. When I run the sprocs the appropriate fields show
up
> in the results window but when I refresh the fields, reguardless of what
> variable I used it displays X's fields in the fields window. Can I not
create
> two datasets running the same sproc using different variables. If not is
this
> so this something that I'll be able to do in the near future? Any help
would
> be most appreciated.|||Thanks, Ben but that would mean changing hundreds of sprocs that are being
used by our VB programmers as well. Any other ideas?
"Benjamin Pierce" wrote:
> Hey there,
> As far as I know Reporting Services scans the Stored Procedure, caches the
> field names and uses those.
> Why don't you have your stored procedure return generic colum names such as
> "Col1", "Col2", "Col3" and then apply some conditional formatting on those
> column headers when they're placed on the report. Something like this:
> txtColumn1.Value = IIF(Parameters!MyCondition.Value = "X", "Zip Code",
> "Postal Code")
> I'm pretty sure that this is by design since Reporting Services needs to
> know the column names.
> Hopefully I'm on the same page as you...
>
> Ben
>
> "Arly" <Arly@.discussions.microsoft.com> wrote in message
> news:045E8DA3-0DA9-4EAE-9A7E-91343815D69D@.microsoft.com...
> > I currently have several sprocs that require a variable which determines
> > which set of fields get returned. For ex: X returns fields 1, 2, 3 and Y
> > returns fields 4, 5, 6. When I run the sprocs the appropriate fields show
> up
> > in the results window but when I refresh the fields, reguardless of what
> > variable I used it displays X's fields in the fields window. Can I not
> create
> > two datasets running the same sproc using different variables. If not is
> this
> > so this something that I'll be able to do in the near future? Any help
> would
> > be most appreciated.
>
>

Newb with a serious Trigger question.

Ok I am stumped. I am a newbie in terms of triggers and procedures and am
used to writing inline sql statements , so here is my situation.
I have an audit table for all the updates , inserts and deletes throughout
one of my application database(SQL2005).
Whenever something happens a record gets inserted into this table(this was
all accomplished by an external dll coded somewhere else that i found on the
internet - and all this works fantastically.)
The problem i have is that after the insert into the audit table occurs, i
want to be able to do this...
have a second trigger for the insert on the audit table
this will go out using the Primary key of the edited table (eg. tasks) and
the table name (eg tasks_) and operation type (eg UPDATE< INSERT whatever)
and get these values that are now in the new audit table record.
then i want to use these values to dynamically select a created_By field
from say the tasks table and update the audit record with this new
created_By field.
the theory is that the dll works but puts dbo in for the user all the time,
so i want to go into the application side and grab the user who entered the
info and update the audit trail records.
Is this clear and concise or am i mumbling?
Any help would be vastly appreciated.
Thanks in advance,
COlinColin Smart (csmart@.nf.sympatico.ca) writes:
> I have an audit table for all the updates , inserts and deletes throughout
> one of my application database(SQL2005).
> Whenever something happens a record gets inserted into this table(this was
> all accomplished by an external dll coded somewhere else that i found on
> the internet - and all this works fantastically.)
> The problem i have is that after the insert into the audit table occurs, i
> want to be able to do this...
> have a second trigger for the insert on the audit table this will go out
> using the Primary key of the edited table (eg. tasks) and the table name
> (eg tasks_) and operation type (eg UPDATE< INSERT whatever) and get
> these values that are now in the new audit table record.
> then i want to use these values to dynamically select a created_By field
> from say the tasks table and update the audit record with this new
> created_By field.
> the theory is that the dll works but puts dbo in for the user all the
> time, so i want to go into the application side and grab the user who
> entered the info and update the audit trail records.
From exactly where is this DLL invoked?
This sounds like a solution for SQL 2000 or earlier. That trigger
would be messy to code. It sounds as if the DLL runs as dbo, in
which case you could use dynamic SQL. But if any of the tables does
not have a Created_by column, it will bloe up at run-time. A better
solution would be to pass the DLL the value of original_login() somehow.
(On SQL 2005 you should use original_login(), rather than SYSTEM_USER.)
On SQL 2005, the xml column can be very good for auditing. It depends
exactly what you will use the audit data for, but if you are not going
to run any searches on other data than the table name and key values,
you can use an xml column. The nice thing is that you can do a
SELECT ... FROM inserted FOR XML, and the triggers can be quite generic.
Even nicer is that you can make an entire generic program that reads
the log table, and presents the differences between two log records.
If you insert directly into the auditlog, there is not any problem of
retrieving the current user.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx