Increase field size AND linked tables

I would like to increase a field size to allow input of up to 16 characters
versus the current 11, but the message is that I can't do the modification
due to linked tables. I believe the modification must be done at the server
,
but I wouldn't know where to start. It would seem that it should be an easy
fix if someone could point me in the right direction. I hate to call the
tech guys out to open a couple windows and type 16. The database was done i
n
access converted to SQL.
ThanksDear rtucker913,
Please post DDL or any example which clarifies your request.
Thanks in advance,
"rtucker913" wrote:

> I would like to increase a field size to allow input of up to 16 character
s
> versus the current 11, but the message is that I can't do the modification
> due to linked tables. I believe the modification must be done at the serv
er,
> but I wouldn't know where to start. It would seem that it should be an ea
sy
> fix if someone could point me in the right direction. I hate to call the
> tech guys out to open a couple windows and type 16. The database was done
in
> access converted to SQL.
> Thankssql

Inconsistent Results with TRY - CATCH and Linked Server

Hi
I'm not sure if this is the right Newsgroup for this question, apologies if
it's off topic.
I've got a stored procedure that calls a second stored procedure on a linked
server. My local stored procedure encloses the call to the remote stored
procedure in a try - catch block. I have deliberately introduced an error
into the remote stored procedure to check whether the local try - catch bloc
k
handles it. Unfortunately the try - catch block appears to exhibit
inconsistent behaviour under identical conditions.
At the moment it appears a little like black magic - could anyone explain
what might be going on?
SET UP
--
Here's a snippet of code from the local stored procedure. The code snippet
exhibits the same inconsistent behaviour as the full stored procedure:
LOCAL CODE SNIPPET STARTS
=====================
declare @.DeviceID NVARCHAR(10),
@.RunID NVARCHAR(10),
@.CourierID NVARCHAR(10)
set @.DeviceID = 'TestDev1'
set @.RunID = 'TestRun1'
set @.CourierID = '99999'
DECLARE
@.RetVal INT,
@.StoredProcErrNum INT,
@.SqlErrMsg VARCHAR(200)
SET @.RetVal = 0
SET @.StoredProcErrNum = 0
SET @.SqlErrMsg = N''
DECLARE @.nCID INT
SET @.nCID = CAST(@.CourierID AS INT)
select @.RunID, @.nCID
DECLARE @.fail bit
DECLARE @.Profile TABLE ( profile_desc VARCHAR(40), Street BIT, [Print] B
IT,
t3_run_type CHAR(1) )
SET XACT_ABORT ON
SET @.RetVal = NULL
BEGIN TRY
INSERT INTO @.Profile
EXEC @.RetVal = cme.cme.dbo.spd_t3_login_driver_details @.RunID, @.nCID, @.fail
OUTPUT
END TRY
BEGIN CATCH
IF @.@.TRANCOUNT > 0 ROLLBACK TRANSACTION
SET @.RetVal = 1
SET @.StoredProcErrNum = ERROR_NUMBER()
SET @.SqlErrMsg = ERROR_MESSAGE()
END CATCH
IF @.RetVal IS NULL SET @.RetVal = 1
select @.RetVal AS RetVal, @.fail AS Fail, @.StoredProcErrNum AS
StoredProcErrNum, @.SqlErrMsg AS SqlErrMsg
select * from @.Profile
================
CODE SNIPPET ENDS
Here is the remote stored procedure that is called by the above code snippet
:
REMOTE STORED PROCEDURE CODE STARTS
===============================
ALTER PROCEDURE [dbo].[spd_t3_login_driver_details] ( @.run_no VARCHA
R(40),
@.driver_id INT, @.failure BIT OUTPUT )
AS
--select 100/0
IF NOT EXISTS ( SELECT * FROM run r INNER JOIN driver d ON r.default_driver
= d.driver_id
INNER JOIN run_profiles rp ON r.profile_id = rp.run_profile_id
WHERE run_no = @.run_no
AND d.driver_id = @.driver_id )
BEGIN
SELECT @.failure = 1
END
ELSE
BEGIN
SELECT @.failure = 0
SELECT profile_desc, ISNULL(street, 1) AS 'Street', ISNULL(van_print, 1) AS
'Print', ISNULL(t3_run_type, 'M') AS 't3_run_type'
FROM run r INNER JOIN driver d ON r.default_driver = d.driver_id
INNER JOIN run_profiles rp ON r.profile_id = rp.run_profile_id
WHERE run_no = @.run_no
AND d.driver_id = @.driver_id
END
=================
CODE ENDS
The commented line in the remote stored procedure allows me to introduce a
divide by zero error.
The remote stored procedure is pretty simple and I don't expect much trouble
with it. However there are many remote stored procedures running on the
linked server. I just used this one to test whether we could deal with
errors that may arise in any of the remote stored procedures.
Unfortunately we have no control over the remote stored procedures. They
were developed and are maintained by another company, and are running on
their server which we have only limited rights to. We have a test
environment with a duplicate of the production remote server. This is how
I've played around with the remote stored procedure above. However the
production versions of the remote stored procedures are set in stone.
BEHAVIOUR:
--
When I uncomment the select 100/0 and run the alter procedure script for
spd_t3_login_driver_details on the remote server, then run the code snippet
on the local server, this is the behaviour I expect:
The code snippet runs to the end and returns the following recordsets:
(no column name) (no column name)
-- --
TestRun1 99999
RetVal Fail StoredProcErrNum SqlErrMsg
-- -- -- --
1 NULL 8134 Divide by zero error encountered.
profile_desc Street Print t3_run_type
-- -- -- --
<no rows returned>
However, this desired behaviour happens only about one time in ten. Most of
the time when I run the code snippet it aborts when it tries to call the
remote stored procedure.
The following recordset is returned:
(no column name) (no column name)
-- --
TestRun1 99999
I also get the following messages:
(1 row(s) affected)
(0 row(s) affected)
Msg 1206, Level 18, State 118, Line 28
The Microsoft Distributed Transaction Coordinator (MS DTC) has cancelled the
distributed transaction.
ATTEMPTED INVESTIGATION:
--
Initially I thought adding the IF @.@.TRANCOUNT > 0 ROLLBACK TRANSACTION to
the CATCH block solved the problem by rolling back the implicit transaction.
However I soon discovered the problem came back again. I also thought the SE
T
XACT_ABORT ON might be the problem. I set it to OFF instead. Then the code
snippet seemed to
always run to completion but it was not picking up the error message and
error number from ERROR_MESSAGE() and ERROR_NUMBER().
Can anyone explain the inconsistent behaviour of this code? Why does the try
- catch block work sometimes but not others?
Cheers
SiI don't know why it would be inconsistent but This may be why the
transaction aborts without going to the catch:
Attentions will terminate a batch even if the batch is within the scope of a
TRY.CATCH construct. This includes an attention sent by the Microsoft
Distributed Transaction Coordinator (MS DTC) when a distributed transaction
fails. MS DTC manages distributed transactions.
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"SimonDev" <SimonDev@.discussions.microsoft.com> wrote in message
news:7F48371C-890D-40F9-8E5C-D40C92F4C043@.microsoft.com...
> Hi
> I'm not sure if this is the right Newsgroup for this question, apologies
> if
> it's off topic.
> I've got a stored procedure that calls a second stored procedure on a
> linked
> server. My local stored procedure encloses the call to the remote stored
> procedure in a try - catch block. I have deliberately introduced an error
> into the remote stored procedure to check whether the local try - catch
> block
> handles it. Unfortunately the try - catch block appears to exhibit
> inconsistent behaviour under identical conditions.
> At the moment it appears a little like black magic - could anyone explain
> what might be going on?
> SET UP
> --
> Here's a snippet of code from the local stored procedure. The code snippet
> exhibits the same inconsistent behaviour as the full stored procedure:
> LOCAL CODE SNIPPET STARTS
> =====================
> declare @.DeviceID NVARCHAR(10),
> @.RunID NVARCHAR(10),
> @.CourierID NVARCHAR(10)
> set @.DeviceID = 'TestDev1'
> set @.RunID = 'TestRun1'
> set @.CourierID = '99999'
> DECLARE
> @.RetVal INT,
> @.StoredProcErrNum INT,
> @.SqlErrMsg VARCHAR(200)
> SET @.RetVal = 0
> SET @.StoredProcErrNum = 0
> SET @.SqlErrMsg = N''
> DECLARE @.nCID INT
> SET @.nCID = CAST(@.CourierID AS INT)
> select @.RunID, @.nCID
> DECLARE @.fail bit
> DECLARE @.Profile TABLE ( profile_desc VARCHAR(40), Street BIT, [Print]
> BIT,
> t3_run_type CHAR(1) )
> SET XACT_ABORT ON
> SET @.RetVal = NULL
> BEGIN TRY
> INSERT INTO @.Profile
> EXEC @.RetVal = cme.cme.dbo.spd_t3_login_driver_details @.RunID, @.nCID,
> @.fail
> OUTPUT
> END TRY
> BEGIN CATCH
> IF @.@.TRANCOUNT > 0 ROLLBACK TRANSACTION
> SET @.RetVal = 1
> SET @.StoredProcErrNum = ERROR_NUMBER()
> SET @.SqlErrMsg = ERROR_MESSAGE()
> END CATCH
> IF @.RetVal IS NULL SET @.RetVal = 1
> select @.RetVal AS RetVal, @.fail AS Fail, @.StoredProcErrNum AS
> StoredProcErrNum, @.SqlErrMsg AS SqlErrMsg
> select * from @.Profile
> ================
> CODE SNIPPET ENDS
> Here is the remote stored procedure that is called by the above code
> snippet:
> REMOTE STORED PROCEDURE CODE STARTS
> ===============================
> ALTER PROCEDURE [dbo].[spd_t3_login_driver_details] ( @.run_no VARC
HAR(40),
> @.driver_id INT, @.failure BIT OUTPUT )
> AS
> --select 100/0
> IF NOT EXISTS ( SELECT * FROM run r INNER JOIN driver d ON
> r.default_driver
> = d.driver_id
> INNER JOIN run_profiles rp ON r.profile_id = rp.run_profile_id
> WHERE run_no = @.run_no
> AND d.driver_id = @.driver_id )
> BEGIN
> SELECT @.failure = 1
> END
> ELSE
> BEGIN
> SELECT @.failure = 0
>
> SELECT profile_desc, ISNULL(street, 1) AS 'Street', ISNULL(van_print, 1)
> AS
> 'Print', ISNULL(t3_run_type, 'M') AS 't3_run_type'
> FROM run r INNER JOIN driver d ON r.default_driver = d.driver_id
> INNER JOIN run_profiles rp ON r.profile_id = rp.run_profile_id
> WHERE run_no = @.run_no
> AND d.driver_id = @.driver_id
> END
> =================
> CODE ENDS
> The commented line in the remote stored procedure allows me to introduce a
> divide by zero error.
> The remote stored procedure is pretty simple and I don't expect much
> trouble
> with it. However there are many remote stored procedures running on the
> linked server. I just used this one to test whether we could deal with
> errors that may arise in any of the remote stored procedures.
> Unfortunately we have no control over the remote stored procedures. They
> were developed and are maintained by another company, and are running on
> their server which we have only limited rights to. We have a test
> environment with a duplicate of the production remote server. This is
> how
> I've played around with the remote stored procedure above. However the
> production versions of the remote stored procedures are set in stone.
> BEHAVIOUR:
> --
> When I uncomment the select 100/0 and run the alter procedure script for
> spd_t3_login_driver_details on the remote server, then run the code
> snippet
> on the local server, this is the behaviour I expect:
> The code snippet runs to the end and returns the following recordsets:
> (no column name) (no column name)
> -- --
> TestRun1 99999
> RetVal Fail StoredProcErrNum SqlErrMsg
> -- -- -- --
> 1 NULL 8134 Divide by zero error encountered.
> profile_desc Street Print t3_run_type
> -- -- -- --
> <no rows returned>
> However, this desired behaviour happens only about one time in ten. Most
> of
> the time when I run the code snippet it aborts when it tries to call the
> remote stored procedure.
> The following recordset is returned:
> (no column name) (no column name)
> -- --
> TestRun1 99999
> I also get the following messages:
> (1 row(s) affected)
> (0 row(s) affected)
> Msg 1206, Level 18, State 118, Line 28
> The Microsoft Distributed Transaction Coordinator (MS DTC) has cancelled
> the
> distributed transaction.
> ATTEMPTED INVESTIGATION:
> --
> Initially I thought adding the IF @.@.TRANCOUNT > 0 ROLLBACK TRANSACTION to
> the CATCH block solved the problem by rolling back the implicit
> transaction.
> However I soon discovered the problem came back again. I also thought the
> SET
> XACT_ABORT ON might be the problem. I set it to OFF instead. Then the code
> snippet seemed to
> always run to completion but it was not picking up the error message and
> error number from ERROR_MESSAGE() and ERROR_NUMBER().
> Can anyone explain the inconsistent behaviour of this code? Why does the
> try
> - catch block work sometimes but not others?
> Cheers
> Si|||Thanks for your reply, Roger.
What exactly is an attention? Sorry if this is a newbie sort of question.
I had assumed that since the severity level of the error was less than 20 it
would have been caught by the catch block. What is the difference between a
n
error and an attention? Books online mentions examples of attentions being
client-interrupt requests and broken client connections but that doesn't
really help me to understand them.
Is there any way of trapping attentions or will they always break T-SQL
code, no matter what the severity level is?
Cheers
Simon
"Roger Wolter[MSFT]" wrote:

> I don't know why it would be inconsistent but This may be why the
> transaction aborts without going to the catch:
> Attentions will terminate a batch even if the batch is within the scope of
a
> TRY.CATCH construct. This includes an attention sent by the Microsoft
> Distributed Transaction Coordinator (MS DTC) when a distributed transactio
n
> fails. MS DTC manages distributed transactions.|||Our DBA pointed out I have missed one very important piece of information:
Although the local server is SQL Server 2005, the linked server (cme) that i
t
calls to is SQL Server 2000 SP4.
Si|||Further progress: I've tried to find information about attention events.
Pretty hard to track down but as I understand them, attention events are jus
t
requests from a client to cancel the currently running query.
I discovered Profiler can track Attention events so ran Profiler traces on
both local and linked servers. There were no attention events raised on
either server when the MS DTC cancelled the distributed transaction. On the
linked server an exception was raised: Error: 8134, Severity: 16, State: 1
(as far as I can recall 8134 is a divide by zero error). On the local serve
r
an exception was raised: Error: 1206, Severity: 18, State: 199. This was
followed by a user error message "The Microsoft Distributed Transaction
Coordinator (MS DTC) has cancelled the distributed transaction.".
Now that it's finally occurred to me to use Profiler I'll continue using it
while playing with SET XACT_ABORT to see if I can make any further progress.
Cheers
Simon

Inconsistent Results with TRY - CATCH and Linked Server

Hi
I'm not sure if this is the right Newsgroup for this question, apologies if
it's off topic.
I've got a stored procedure that calls a second stored procedure on a linked
server. My local stored procedure encloses the call to the remote stored
procedure in a try - catch block. I have deliberately introduced an error
into the remote stored procedure to check whether the local try - catch block
handles it. Unfortunately the try - catch block appears to exhibit
inconsistent behaviour under identical conditions.
At the moment it appears a little like black magic - could anyone explain
what might be going on?
SET UP
Here's a snippet of code from the local stored procedure. The code snippet
exhibits the same inconsistent behaviour as the full stored procedure:
LOCAL CODE SNIPPET STARTS
=====================
declare @.DeviceID NVARCHAR(10),
@.RunID NVARCHAR(10),
@.CourierID NVARCHAR(10)
set @.DeviceID = 'TestDev1'
set @.RunID = 'TestRun1'
set @.CourierID = '99999'
DECLARE
@.RetVal INT,
@.StoredProcErrNum INT,
@.SqlErrMsg VARCHAR(200)
SET @.RetVal = 0
SET @.StoredProcErrNum = 0
SET @.SqlErrMsg = N''
DECLARE @.nCID INT
SET @.nCID = CAST(@.CourierID AS INT)
select @.RunID, @.nCID
DECLARE @.fail bit
DECLARE @.Profile TABLE ( profile_desc VARCHAR(40), Street BIT, [Print] BIT,
t3_run_type CHAR(1) )
SET XACT_ABORT ON
SET @.RetVal = NULL
BEGIN TRY
INSERT INTO @.Profile
EXEC @.RetVal = cme.cme.dbo.spd_t3_login_driver_details @.RunID, @.nCID, @.fail
OUTPUT
END TRY
BEGIN CATCH
IF @.@.TRANCOUNT > 0 ROLLBACK TRANSACTION
SET @.RetVal = 1
SET @.StoredProcErrNum = ERROR_NUMBER()
SET @.SqlErrMsg = ERROR_MESSAGE()
END CATCH
IF @.RetVal IS NULL SET @.RetVal = 1
select @.RetVal AS RetVal, @.fail AS Fail, @.StoredProcErrNum AS
StoredProcErrNum, @.SqlErrMsg AS SqlErrMsg
select * from @.Profile
================
CODE SNIPPET ENDS
Here is the remote stored procedure that is called by the above code snippet:
REMOTE STORED PROCEDURE CODE STARTS
===============================
ALTER PROCEDURE [dbo].[spd_t3_login_driver_details] ( @.run_no VARCHAR(40),
@.driver_id INT, @.failure BIT OUTPUT )
AS
--select 100/0
IF NOT EXISTS ( SELECT * FROM run r INNER JOIN driver d ON r.default_driver
= d.driver_id
INNER JOIN run_profiles rp ON r.profile_id = rp.run_profile_id
WHERE run_no = @.run_no
AND d.driver_id = @.driver_id )
BEGIN
SELECT @.failure = 1
END
ELSE
BEGIN
SELECT @.failure = 0
SELECT profile_desc, ISNULL(street, 1) AS 'Street', ISNULL(van_print, 1) AS
'Print', ISNULL(t3_run_type, 'M') AS 't3_run_type'
FROM run r INNER JOIN driver d ON r.default_driver = d.driver_id
INNER JOIN run_profiles rp ON r.profile_id = rp.run_profile_id
WHERE run_no = @.run_no
AND d.driver_id = @.driver_id
END
=================
CODE ENDS
The commented line in the remote stored procedure allows me to introduce a
divide by zero error.
The remote stored procedure is pretty simple and I don't expect much trouble
with it. However there are many remote stored procedures running on the
linked server. I just used this one to test whether we could deal with
errors that may arise in any of the remote stored procedures.
Unfortunately we have no control over the remote stored procedures. They
were developed and are maintained by another company, and are running on
their server which we have only limited rights to. We have a test
environment with a duplicate of the production remote server. This is how
I've played around with the remote stored procedure above. However the
production versions of the remote stored procedures are set in stone.
BEHAVIOUR:
When I uncomment the select 100/0 and run the alter procedure script for
spd_t3_login_driver_details on the remote server, then run the code snippet
on the local server, this is the behaviour I expect:
The code snippet runs to the end and returns the following recordsets:
(no column name) (no column name)
-- --
TestRun1 99999
RetVal Fail StoredProcErrNum SqlErrMsg
-- -- -- --
1 NULL 8134 Divide by zero error encountered.
profile_desc Street Print t3_run_type
-- -- -- --
<no rows returned>
However, this desired behaviour happens only about one time in ten. Most of
the time when I run the code snippet it aborts when it tries to call the
remote stored procedure.
The following recordset is returned:
(no column name) (no column name)
-- --
TestRun1 99999
I also get the following messages:
(1 row(s) affected)
(0 row(s) affected)
Msg 1206, Level 18, State 118, Line 28
The Microsoft Distributed Transaction Coordinator (MS DTC) has cancelled the
distributed transaction.
ATTEMPTED INVESTIGATION:
Initially I thought adding the IF @.@.TRANCOUNT > 0 ROLLBACK TRANSACTION to
the CATCH block solved the problem by rolling back the implicit transaction.
However I soon discovered the problem came back again. I also thought the SET
XACT_ABORT ON might be the problem. I set it to OFF instead. Then the code
snippet seemed to
always run to completion but it was not picking up the error message and
error number from ERROR_MESSAGE() and ERROR_NUMBER().
Can anyone explain the inconsistent behaviour of this code? Why does the try
- catch block work sometimes but not others?
Cheers
Si
I don't know why it would be inconsistent but This may be why the
transaction aborts without going to the catch:
Attentions will terminate a batch even if the batch is within the scope of a
TRY.CATCH construct. This includes an attention sent by the Microsoft
Distributed Transaction Coordinator (MS DTC) when a distributed transaction
fails. MS DTC manages distributed transactions.
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"SimonDev" <SimonDev@.discussions.microsoft.com> wrote in message
news:7F48371C-890D-40F9-8E5C-D40C92F4C043@.microsoft.com...
> Hi
> I'm not sure if this is the right Newsgroup for this question, apologies
> if
> it's off topic.
> I've got a stored procedure that calls a second stored procedure on a
> linked
> server. My local stored procedure encloses the call to the remote stored
> procedure in a try - catch block. I have deliberately introduced an error
> into the remote stored procedure to check whether the local try - catch
> block
> handles it. Unfortunately the try - catch block appears to exhibit
> inconsistent behaviour under identical conditions.
> At the moment it appears a little like black magic - could anyone explain
> what might be going on?
> SET UP
> --
> Here's a snippet of code from the local stored procedure. The code snippet
> exhibits the same inconsistent behaviour as the full stored procedure:
> LOCAL CODE SNIPPET STARTS
> =====================
> declare @.DeviceID NVARCHAR(10),
> @.RunID NVARCHAR(10),
> @.CourierID NVARCHAR(10)
> set @.DeviceID = 'TestDev1'
> set @.RunID = 'TestRun1'
> set @.CourierID = '99999'
> DECLARE
> @.RetVal INT,
> @.StoredProcErrNum INT,
> @.SqlErrMsg VARCHAR(200)
> SET @.RetVal = 0
> SET @.StoredProcErrNum = 0
> SET @.SqlErrMsg = N''
> DECLARE @.nCID INT
> SET @.nCID = CAST(@.CourierID AS INT)
> select @.RunID, @.nCID
> DECLARE @.fail bit
> DECLARE @.Profile TABLE ( profile_desc VARCHAR(40), Street BIT, [Print]
> BIT,
> t3_run_type CHAR(1) )
> SET XACT_ABORT ON
> SET @.RetVal = NULL
> BEGIN TRY
> INSERT INTO @.Profile
> EXEC @.RetVal = cme.cme.dbo.spd_t3_login_driver_details @.RunID, @.nCID,
> @.fail
> OUTPUT
> END TRY
> BEGIN CATCH
> IF @.@.TRANCOUNT > 0 ROLLBACK TRANSACTION
> SET @.RetVal = 1
> SET @.StoredProcErrNum = ERROR_NUMBER()
> SET @.SqlErrMsg = ERROR_MESSAGE()
> END CATCH
> IF @.RetVal IS NULL SET @.RetVal = 1
> select @.RetVal AS RetVal, @.fail AS Fail, @.StoredProcErrNum AS
> StoredProcErrNum, @.SqlErrMsg AS SqlErrMsg
> select * from @.Profile
> ================
> CODE SNIPPET ENDS
> Here is the remote stored procedure that is called by the above code
> snippet:
> REMOTE STORED PROCEDURE CODE STARTS
> ===============================
> ALTER PROCEDURE [dbo].[spd_t3_login_driver_details] ( @.run_no VARCHAR(40),
> @.driver_id INT, @.failure BIT OUTPUT )
> AS
> --select 100/0
> IF NOT EXISTS ( SELECT * FROM run r INNER JOIN driver d ON
> r.default_driver
> = d.driver_id
> INNER JOIN run_profiles rp ON r.profile_id = rp.run_profile_id
> WHERE run_no = @.run_no
> AND d.driver_id = @.driver_id )
> BEGIN
> SELECT @.failure = 1
> END
> ELSE
> BEGIN
> SELECT @.failure = 0
>
> SELECT profile_desc, ISNULL(street, 1) AS 'Street', ISNULL(van_print, 1)
> AS
> 'Print', ISNULL(t3_run_type, 'M') AS 't3_run_type'
> FROM run r INNER JOIN driver d ON r.default_driver = d.driver_id
> INNER JOIN run_profiles rp ON r.profile_id = rp.run_profile_id
> WHERE run_no = @.run_no
> AND d.driver_id = @.driver_id
> END
> =================
> CODE ENDS
> The commented line in the remote stored procedure allows me to introduce a
> divide by zero error.
> The remote stored procedure is pretty simple and I don't expect much
> trouble
> with it. However there are many remote stored procedures running on the
> linked server. I just used this one to test whether we could deal with
> errors that may arise in any of the remote stored procedures.
> Unfortunately we have no control over the remote stored procedures. They
> were developed and are maintained by another company, and are running on
> their server which we have only limited rights to. We have a test
> environment with a duplicate of the production remote server. This is
> how
> I've played around with the remote stored procedure above. However the
> production versions of the remote stored procedures are set in stone.
> BEHAVIOUR:
> --
> When I uncomment the select 100/0 and run the alter procedure script for
> spd_t3_login_driver_details on the remote server, then run the code
> snippet
> on the local server, this is the behaviour I expect:
> The code snippet runs to the end and returns the following recordsets:
> (no column name) (no column name)
> -- --
> TestRun1 99999
> RetVal Fail StoredProcErrNum SqlErrMsg
> -- -- -- --
> 1 NULL 8134 Divide by zero error encountered.
> profile_desc Street Print t3_run_type
> -- -- -- --
> <no rows returned>
> However, this desired behaviour happens only about one time in ten. Most
> of
> the time when I run the code snippet it aborts when it tries to call the
> remote stored procedure.
> The following recordset is returned:
> (no column name) (no column name)
> -- --
> TestRun1 99999
> I also get the following messages:
> (1 row(s) affected)
> (0 row(s) affected)
> Msg 1206, Level 18, State 118, Line 28
> The Microsoft Distributed Transaction Coordinator (MS DTC) has cancelled
> the
> distributed transaction.
> ATTEMPTED INVESTIGATION:
> --
> Initially I thought adding the IF @.@.TRANCOUNT > 0 ROLLBACK TRANSACTION to
> the CATCH block solved the problem by rolling back the implicit
> transaction.
> However I soon discovered the problem came back again. I also thought the
> SET
> XACT_ABORT ON might be the problem. I set it to OFF instead. Then the code
> snippet seemed to
> always run to completion but it was not picking up the error message and
> error number from ERROR_MESSAGE() and ERROR_NUMBER().
> Can anyone explain the inconsistent behaviour of this code? Why does the
> try
> - catch block work sometimes but not others?
> Cheers
> Si
|||Thanks for your reply, Roger.
What exactly is an attention? Sorry if this is a newbie sort of question.
I had assumed that since the severity level of the error was less than 20 it
would have been caught by the catch block. What is the difference between an
error and an attention? Books online mentions examples of attentions being
client-interrupt requests and broken client connections but that doesn't
really help me to understand them.
Is there any way of trapping attentions or will they always break T-SQL
code, no matter what the severity level is?
Cheers
Simon
"Roger Wolter[MSFT]" wrote:

> I don't know why it would be inconsistent but This may be why the
> transaction aborts without going to the catch:
> Attentions will terminate a batch even if the batch is within the scope of a
> TRY.CATCH construct. This includes an attention sent by the Microsoft
> Distributed Transaction Coordinator (MS DTC) when a distributed transaction
> fails. MS DTC manages distributed transactions.
|||Our DBA pointed out I have missed one very important piece of information:
Although the local server is SQL Server 2005, the linked server (cme) that it
calls to is SQL Server 2000 SP4.
Si
|||Further progress: I've tried to find information about attention events.
Pretty hard to track down but as I understand them, attention events are just
requests from a client to cancel the currently running query.
I discovered Profiler can track Attention events so ran Profiler traces on
both local and linked servers. There were no attention events raised on
either server when the MS DTC cancelled the distributed transaction. On the
linked server an exception was raised: Error: 8134, Severity: 16, State: 1
(as far as I can recall 8134 is a divide by zero error). On the local server
an exception was raised: Error: 1206, Severity: 18, State: 199. This was
followed by a user error message "The Microsoft Distributed Transaction
Coordinator (MS DTC) has cancelled the distributed transaction.".
Now that it's finally occurred to me to use Profiler I'll continue using it
while playing with SET XACT_ABORT to see if I can make any further progress.
Cheers
Simon

Inconsistent metadata. Error 7352.

Howdy all. I am getting an error with SQL Server 2000. I am pulling data from one server to another using Linked Servers. I am getting the following error:

OLE DB provider 'SQLOLEDB' supplied inconsistent metadata. The object '[<IP>].[<Database>].[dbo].[<Table>]' was missing expected column '<ColumnName>'. [SQLSTATE 42000] (Error 7352).

The perplexing thing to me about this problem, is that I am getting the error when I run a particular stored procedure within a SQL Server Agent Job. However, I run the stored procedure several times within that job, and it works the first couple of times. It fails on the same job step every time, but yet it works on other steps that do the same thing -- just with different tables and columns.

Any help would be greatly appreciated.You may have already tried this - but have you deleted the step and added the step back ?|||No, I have not tried this yet, but I will try it. I am having this problem at several servers which are all pulling from the same linked server.

Thanks for the suggestion.

Originally posted by rnealejr
You may have already tried this - but have you deleted the step and added the step back ?|||Was a column (or anything else) modified/deleted ?|||No. I thought of that, too. Nothing has been done to the table or its columns.

Originally posted by rnealejr
Was a column (or anything else) modified/deleted ?|||Let me know if deleting the step works - something may have gotten corrupted.|||I deleted the whole SQL Agent job and readded it. I am still getting the inconsistent metadata error. It happens on and off. It will work sometimes for several of the servers that are pulling data, but most of the time I get the metadata error.|||Is it the same column/table every time ? If so, what is the data type of the column ? Are you linking to sql server 2000 servers only ? Do you know where it is failing within the sp - can you post the code where it is failing ?|||It is the same table/column everytime. It is the same step in the job every time. The sp is executed several times within the job, and it works successfully several times, but when it fails it always fails on this step. Here is the code that it is failing on:
--------------
SELECT @.Command = @.Command + 'DECLARE tmpCursor CURSOR READ_ONLY FOR' + Char(13)
SELECT @.Command = @.Command + 'SELECT distinct ' + Char(13)
SELECT @.Command = @.Command + ' o.O_ID' + Char(13)
SELECT @.Command = @.Command + 'FROM' + Char(13)
SELECT @.Command = @.Command + ' [' + @.SourceServerName + '].Mugshot.dbo.Objects o,' + Char(13)
SELECT @.Command = @.Command + ' [' + @.SourceServerName + '].Mugshot.dbo.SubObjects so,' + Char(13)
SELECT @.Command = @.Command + ' [' + @.SourceServerName + '].Mugshot.dbo.FieldInstanceObjects fio,' + Char(13)
SELECT @.Command = @.Command + ' ' + @.DestImageTableName + ' i,' + Char(13)
SELECT @.Command = @.Command + ' xFer_R_ID r' + Char(13)
SELECT @.Command = @.Command + 'WHERE' + Char(13)
SELECT @.Command = @.Command + ' r.R_ID = i.Parent_R_ID AND' + Char(13)
SELECT @.Command = @.Command + ' i.' + @.DestImageColumnName + ' = fio.FI_ID AND' + Char(13)
SELECT @.Command = @.Command + ' fio.O_ID = o.O_ID AND' + Char(13)
SELECT @.Command = @.Command + ' so.Full_O_ID = o.O_ID' + Char(13)
--------------

Basically, I am declaring a cursor within a string, so the SourceServer can be dynamically specified. All SourceServer's are SQL Server 2000. I use Linked Servers to access the SourceServer's (sp_addlinkedserver).

Thanks for your time.

Originally posted by rnealejr
Is it the same column/table every time ? If so, what is the data type of the column ? Are you linking to sql server 2000 servers only ? Do you know where it is failing within the sp - can you post the code where it is failing ?

Inconsistent Linked Server Query Results

Hello,

I have a linked server named 'Charlie_File' to an Excel Workbook that I set up in SQLServer 2005 Management Studio. The workbook is on my local C drive. Sometimes, I get the results back that I expect when I run the following query;

SELECT*FROMOPENQUERY(Charlie_file,'SELECT * FROM [Feb$]')

Sometimes, on subsequent runs of the above query, I get the following message;

Msg 7399, Level 16, State 1, Line 1
The OLE DB provider "MSDASQL" for linked server "Charlie_file" reported an error. The provider did not give any information about the error.
Msg 7303, Level 16, State 1, Line 1
Cannot initialize the data source object of OLE DB provider "MSDASQL" for linked server "Charlie_file".

There seems to be about a minute or so of a delay before the query will run correctly on subsequent attempts. Is there a connection issue here where a connection blocks subsequent attempts to select the data within a specific time span?

Thank you for your help!

cdun2

It turns out that the problem was with security settings on the linked server. I didn't have a mapping set up between the linked server and the SQL Server login for myself, so under 'For a login not defined in the list above, connections will;' I selected 'Be made using the login's current security context.'

cdun2

Inconsistent Linked Server Execution Plans

I am witnessing something odd with regard to execution plans and a
linked server.
I have a restore of a production database in two different
environments, one DEV the other QA. This database resides on the linked
server in our setup. The other database -- the local database -- has
been installed and populated by a script in both DEV and QA. The
version and edition of SQL Server are identical in both environments.
In the DEV environment, executing a query which uses the linked server
(in a four part name) results in a reasonable execution plan with
filtering ocurring on the remote database before the rows are returned.
However, in the QA environment the same query results in an execution
plan that has _all_ of the rows from the remote tables returned before
filtering. The tables in the database on the linked server are somewhat
large > 1M. The execution times differ by a vast amount.
I'm really at a loss. I know the query optimizer is a fickle mistress
but is this evidence of something predictable and knowable? What are
the types of things that I might take a look at in order to discover
why the same query in two very similar environments generates such
wildly different execution plans? And, more than that why on earth
would the query optimizer not just as a matter of course _always_
filter the rows remotely before returning them? Is there any way to
force the query optimizer to filter the rows remotely before returning
them? I've looked at the openquery function which does this but is not
practical in this circumstance given the query itself. Rearchitecture
is an option but I'm dying for some kind of explanation for this
behavior. My brain is broke.Hi
I am not familiar with your problem in particular, but you could try
updating indexes and statistics on the linked server to see if anything
changes. To avoid any possible filtering problem you could execute a remote
stored procedure or possibly use OPENQUERY.
John
"person" wrote:

> I am witnessing something odd with regard to execution plans and a
> linked server.
> I have a restore of a production database in two different
> environments, one DEV the other QA. This database resides on the linked
> server in our setup. The other database -- the local database -- has
> been installed and populated by a script in both DEV and QA. The
> version and edition of SQL Server are identical in both environments.
> In the DEV environment, executing a query which uses the linked server
> (in a four part name) results in a reasonable execution plan with
> filtering ocurring on the remote database before the rows are returned.
> However, in the QA environment the same query results in an execution
> plan that has _all_ of the rows from the remote tables returned before
> filtering. The tables in the database on the linked server are somewhat
> large > 1M. The execution times differ by a vast amount.
> I'm really at a loss. I know the query optimizer is a fickle mistress
> but is this evidence of something predictable and knowable? What are
> the types of things that I might take a look at in order to discover
> why the same query in two very similar environments generates such
> wildly different execution plans? And, more than that why on earth
> would the query optimizer not just as a matter of course _always_
> filter the rows remotely before returning them? Is there any way to
> force the query optimizer to filter the rows remotely before returning
> them? I've looked at the openquery function which does this but is not
> practical in this circumstance given the query itself. Rearchitecture
> is an option but I'm dying for some kind of explanation for this
> behavior. My brain is broke.
>|||I updated the statistics on all the databases involved to no avail. I'm
unable to use the OPENQEURY function since I have to join tables across
the databases.
Which execution plan seems to be the anomaly? Would it be the execution
plan where the data is filtered on the linked server prior to being
returned or the execution plan that returns all the rows before
filtering?|||I think I may have found some promising information:
http://www.sql-server-performance.com/linked_server.asp
/quote
When running distributed queries on a linked server, if the linked
server has the same character set and sort order (collation) as the
local SQL Server, then you can reduce overhead and boost performance if
you set the SP_SERVEROPTION "collation compatible" option to true. What
this setting does is tell SQL Server to assume that all columns and
character sets on the remote server are compatible with the local
server. This same option can also be turned on for a linked server
using Enterprise Manager
If this option is not selected, then the distributed query being
executed on the remote server must return the entire table to the local
server in order for the WHERE clause to be applied. As you can imagine,
this could potentially return a lot of unnecessary data over the
network, slowing it down.
If the option is selected, (which is always recommended if the
collations are the same on both servers), then the WHERE clause is
applied on the remote server. This, of course, means that much less
data is transmitted over the network, often greatly speeding up the
distributed query. [7.0, 2000] Updated 2-16-2004
/endquote|||Hi
Also check out the other information at the bottom of the article.
Some examples of locally performed operations include:
Data conversion operations
Queries that use the bit, timestamp, or uniqueidentifier data types
Queries that use the TOP clause
INSERTS, UPDATES, or DELETES
John
"person" wrote:

> I think I may have found some promising information:
> http://www.sql-server-performance.com/linked_server.asp
> /quote
> When running distributed queries on a linked server, if the linked
> server has the same character set and sort order (collation) as the
> local SQL Server, then you can reduce overhead and boost performance if
> you set the SP_SERVEROPTION "collation compatible" option to true. What
> this setting does is tell SQL Server to assume that all columns and
> character sets on the remote server are compatible with the local
> server. This same option can also be turned on for a linked server
> using Enterprise Manager
> If this option is not selected, then the distributed query being
> executed on the remote server must return the entire table to the local
> server in order for the WHERE clause to be applied. As you can imagine,
> this could potentially return a lot of unnecessary data over the
> network, slowing it down.
> If the option is selected, (which is always recommended if the
> collations are the same on both servers), then the WHERE clause is
> applied on the remote server. This, of course, means that much less
> data is transmitted over the network, often greatly speeding up the
> distributed query. [7.0, 2000] Updated 2-16-2004
> /endquote
>|||The collation compatibility was not the magic bullet I was hoping it
would be. The two database use the same collation and enabling the
collation compatibility option on the linked server had no effect.
However, digging in further it now appears that there is a correlation
between W2003 and the poor linked server performance.
In our initial setup in the dev environment the local server was a W2K
box while the remote server was a W2003 box. In the QA environment both
servers are W2003. I installed the local db on W2003 box in the Dev
environment. To my surprise, the problem is now reproducible. I can
reproduce the problem in the dev environment only when the local db is
on a W2003 box but not when it is on a W2K box.
So there is some correlation between W2003 and poor linked server
performance.|||Hi
A pure guess would be the check out DTC is working correctly and possibly
re-install it. [url]http://support.microsoft.com/default.aspx?scid=kb;en-us;Q306843[/ur
l]
John
"person" wrote:

> The collation compatibility was not the magic bullet I was hoping it
> would be. The two database use the same collation and enabling the
> collation compatibility option on the linked server had no effect.
> However, digging in further it now appears that there is a correlation
> between W2003 and the poor linked server performance.
> In our initial setup in the dev environment the local server was a W2K
> box while the remote server was a W2003 box. In the QA environment both
> servers are W2003. I installed the local db on W2003 box in the Dev
> environment. To my surprise, the problem is now reproducible. I can
> reproduce the problem in the dev environment only when the local db is
> on a W2003 box but not when it is on a W2K box.
> So there is some correlation between W2003 and poor linked server
> performance.
>|||I'm not sure that that article applies to my situation. We're not using
distributed transactions.
Does this seem like a situation where a support ticket to Microsoft
might be advisable? I can consistently demonstrate that the query
optimizer devises radically different execution plans for the same
stored procedure depending on which operating system the local db is on
(all other factors being equal -- or apparently so). I don't know if
anybody from Microsoft looks at this forum...but would starting a new
thread with a more specific subject line get this problem any better
exposure?|||Hi
It is not something I have come across. I could not find anything at
http://lab.msdn.microsoft.com/productfeedback so raising it with PSS may be
an idea.
John
"person" wrote:

> I'm not sure that that article applies to my situation. We're not using
> distributed transactions.
> Does this seem like a situation where a support ticket to Microsoft
> might be advisable? I can consistently demonstrate that the query
> optimizer devises radically different execution plans for the same
> stored procedure depending on which operating system the local db is on
> (all other factors being equal -- or apparently so). I don't know if
> anybody from Microsoft looks at this forum...but would starting a new
> thread with a more specific subject line get this problem any better
> exposure?
>|||Did you come up with an explanation for the differences in the way the
two OSs handled the queries?
I'm curious, because I migrated from a perfectly-good W2K installation
to a W2003 machine, and my OLE DB Sybase linked server threw ALL KINDS
of errors... things that look to me like collation differences.
Rick

Inconsistent Linked Server Execution Plans

I am witnessing something odd with regard to execution plans and a
linked server.
I have a restore of a production database in two different
environments, one DEV the other QA. This database resides on the linked
server in our setup. The other database -- the local database -- has
been installed and populated by a script in both DEV and QA. The
version and edition of SQL Server are identical in both environments.
In the DEV environment, executing a query which uses the linked server
(in a four part name) results in a reasonable execution plan with
filtering ocurring on the remote database before the rows are returned.
However, in the QA environment the same query results in an execution
plan that has _all_ of the rows from the remote tables returned before
filtering. The tables in the database on the linked server are somewhat
large > 1M. The execution times differ by a vast amount.
I'm really at a loss. I know the query optimizer is a fickle mistress
but is this evidence of something predictable and knowable? What are
the types of things that I might take a look at in order to discover
why the same query in two very similar environments generates such
wildly different execution plans? And, more than that why on earth
would the query optimizer not just as a matter of course _always_
filter the rows remotely before returning them? Is there any way to
force the query optimizer to filter the rows remotely before returning
them? I've looked at the openquery function which does this but is not
practical in this circumstance given the query itself. Rearchitecture
is an option but I'm dying for some kind of explanation for this
behavior. My brain is broke.Hi
I am not familiar with your problem in particular, but you could try
updating indexes and statistics on the linked server to see if anything
changes. To avoid any possible filtering problem you could execute a remote
stored procedure or possibly use OPENQUERY.
John
"person" wrote:
> I am witnessing something odd with regard to execution plans and a
> linked server.
> I have a restore of a production database in two different
> environments, one DEV the other QA. This database resides on the linked
> server in our setup. The other database -- the local database -- has
> been installed and populated by a script in both DEV and QA. The
> version and edition of SQL Server are identical in both environments.
> In the DEV environment, executing a query which uses the linked server
> (in a four part name) results in a reasonable execution plan with
> filtering ocurring on the remote database before the rows are returned.
> However, in the QA environment the same query results in an execution
> plan that has _all_ of the rows from the remote tables returned before
> filtering. The tables in the database on the linked server are somewhat
> large > 1M. The execution times differ by a vast amount.
> I'm really at a loss. I know the query optimizer is a fickle mistress
> but is this evidence of something predictable and knowable? What are
> the types of things that I might take a look at in order to discover
> why the same query in two very similar environments generates such
> wildly different execution plans? And, more than that why on earth
> would the query optimizer not just as a matter of course _always_
> filter the rows remotely before returning them? Is there any way to
> force the query optimizer to filter the rows remotely before returning
> them? I've looked at the openquery function which does this but is not
> practical in this circumstance given the query itself. Rearchitecture
> is an option but I'm dying for some kind of explanation for this
> behavior. My brain is broke.
>|||I updated the statistics on all the databases involved to no avail. I'm
unable to use the OPENQEURY function since I have to join tables across
the databases.
Which execution plan seems to be the anomaly? Would it be the execution
plan where the data is filtered on the linked server prior to being
returned or the execution plan that returns all the rows before
filtering?|||I think I may have found some promising information:
http://www.sql-server-performance.com/linked_server.asp
/quote
When running distributed queries on a linked server, if the linked
server has the same character set and sort order (collation) as the
local SQL Server, then you can reduce overhead and boost performance if
you set the SP_SERVEROPTION "collation compatible" option to true. What
this setting does is tell SQL Server to assume that all columns and
character sets on the remote server are compatible with the local
server. This same option can also be turned on for a linked server
using Enterprise Manager
If this option is not selected, then the distributed query being
executed on the remote server must return the entire table to the local
server in order for the WHERE clause to be applied. As you can imagine,
this could potentially return a lot of unnecessary data over the
network, slowing it down.
If the option is selected, (which is always recommended if the
collations are the same on both servers), then the WHERE clause is
applied on the remote server. This, of course, means that much less
data is transmitted over the network, often greatly speeding up the
distributed query. [7.0, 2000] Updated 2-16-2004
/endquote|||Hi
Also check out the other information at the bottom of the article.
Some examples of locally performed operations include:
Data conversion operations
Queries that use the bit, timestamp, or uniqueidentifier data types
Queries that use the TOP clause
INSERTS, UPDATES, or DELETES
John
"person" wrote:
> I think I may have found some promising information:
> http://www.sql-server-performance.com/linked_server.asp
> /quote
> When running distributed queries on a linked server, if the linked
> server has the same character set and sort order (collation) as the
> local SQL Server, then you can reduce overhead and boost performance if
> you set the SP_SERVEROPTION "collation compatible" option to true. What
> this setting does is tell SQL Server to assume that all columns and
> character sets on the remote server are compatible with the local
> server. This same option can also be turned on for a linked server
> using Enterprise Manager
> If this option is not selected, then the distributed query being
> executed on the remote server must return the entire table to the local
> server in order for the WHERE clause to be applied. As you can imagine,
> this could potentially return a lot of unnecessary data over the
> network, slowing it down.
> If the option is selected, (which is always recommended if the
> collations are the same on both servers), then the WHERE clause is
> applied on the remote server. This, of course, means that much less
> data is transmitted over the network, often greatly speeding up the
> distributed query. [7.0, 2000] Updated 2-16-2004
> /endquote
>|||The collation compatibility was not the magic bullet I was hoping it
would be. The two database use the same collation and enabling the
collation compatibility option on the linked server had no effect.
However, digging in further it now appears that there is a correlation
between W2003 and the poor linked server performance.
In our initial setup in the dev environment the local server was a W2K
box while the remote server was a W2003 box. In the QA environment both
servers are W2003. I installed the local db on W2003 box in the Dev
environment. To my surprise, the problem is now reproducible. I can
reproduce the problem in the dev environment only when the local db is
on a W2003 box but not when it is on a W2K box.
So there is some correlation between W2003 and poor linked server
performance.|||Hi
A pure guess would be the check out DTC is working correctly and possibly
re-install it. http://support.microsoft.com/default.aspx?scid=kb;en-us;Q306843
John
"person" wrote:
> The collation compatibility was not the magic bullet I was hoping it
> would be. The two database use the same collation and enabling the
> collation compatibility option on the linked server had no effect.
> However, digging in further it now appears that there is a correlation
> between W2003 and the poor linked server performance.
> In our initial setup in the dev environment the local server was a W2K
> box while the remote server was a W2003 box. In the QA environment both
> servers are W2003. I installed the local db on W2003 box in the Dev
> environment. To my surprise, the problem is now reproducible. I can
> reproduce the problem in the dev environment only when the local db is
> on a W2003 box but not when it is on a W2K box.
> So there is some correlation between W2003 and poor linked server
> performance.
>|||I'm not sure that that article applies to my situation. We're not using
distributed transactions.
Does this seem like a situation where a support ticket to Microsoft
might be advisable? I can consistently demonstrate that the query
optimizer devises radically different execution plans for the same
stored procedure depending on which operating system the local db is on
(all other factors being equal -- or apparently so). I don't know if
anybody from Microsoft looks at this forum...but would starting a new
thread with a more specific subject line get this problem any better
exposure?|||Hi
It is not something I have come across. I could not find anything at
http://lab.msdn.microsoft.com/productfeedback so raising it with PSS may be
an idea.
John
"person" wrote:
> I'm not sure that that article applies to my situation. We're not using
> distributed transactions.
> Does this seem like a situation where a support ticket to Microsoft
> might be advisable? I can consistently demonstrate that the query
> optimizer devises radically different execution plans for the same
> stored procedure depending on which operating system the local db is on
> (all other factors being equal -- or apparently so). I don't know if
> anybody from Microsoft looks at this forum...but would starting a new
> thread with a more specific subject line get this problem any better
> exposure?
>|||Did you come up with an explanation for the differences in the way the
two OSs handled the queries?
I'm curious, because I migrated from a perfectly-good W2K installation
to a W2003 machine, and my OLE DB Sybase linked server threw ALL KINDS
of errors... things that look to me like collation differences.
Rick|||Rick,
No real explanation yet as to why the OSs handle the queries
differently.
We put in a support ticket with Microsoft. Their tech said to enable
the dynamic parameters option for the Sql Server provider. So in other
words, drop the linked server and recreate it with the dynamic
parameters option selected. I tried that and it had no effect. The
Microsoft tech then suggested we reboot the machine. I did and it
appears to have had a good effect. I am still in the process of testing
and I will post an update if anything interesting ocurrs. Here is the
knowledge base article the tech provided as documentation for his
suggestion:
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q320208.
The article doesn't mention the reboot step. But it is a Microsoft
product and well...
Interestingly enough, the Sql Server provider option for the dynamic
parameters is _not_ selected on the w2k machine. The execution plan on
the w2003 machine is still not as efficient as on the w2k machine but
I'm closer than where I was last month.