Connection Manager Deployment with master/detail package

Hallo,

I'm currently strugling with the setup of our packages for deployment to a new environment.

We are working with a master/detail package setup. One master package is created that will call all child packages. In the master package we don't have any connection towards our source and/or target databases/sourcesystems.

Everything works fine, however, starting to deploy the whole set of packages, it seems that we don't have the option to set specific properties of our detailed packages, e.g. connection properties. But this is just what we need.

When we are adding a job in the Job Agent for our master package to be scheduled, we want to be able to set all different connection manager properties, not only the one from the master package and definitely the ones from the detailed packages as there we switch the connections from the development environment towards the acceptance environment.

I tried to fix this with parent package variables, but I can't set the password property, only the ServerName and UserName can be set, not the Password.

Anyone an idea what the easiest and best approach is to solve this burden?

Thx

Children packages should use package configuration on their connection strings as well; then when deploying the packages to a different enviroment all you have to do is to change the configuration values.

Be warned that there is a known bug when using package configuration with 'parent variables' that, under certain circustances may prevent you to set connection in children packages properly. See details here: https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=126146

Because of that, my recommendation is to define package configurations to set connection strings on every child package(via XML file, SQL server table, env. variable, etc).

"When we are adding a job in the Job Agent for our master package to be scheduled, we want to be able to set all different connection manager properties, not only the one from the master package and definitely the ones from the detailed packages as there we switch the connections from the development environment towards the acceptance environment. "

I think you can only set properties of the invoked package from the command line...as I said before; use configuration packages for that.

Connecting Trace info to blocked users?

In master.dbo.sysprocesses I can filter for blocked users (Blocked >0)
and I can create a self join(ON SPID = Blocked) to see what user
Loginame is causing the block. In the column [cmd] I can see the
command that the offending blocker is running to cause the block, but
it only says "SELECT" etc. with no details about the stored procedure
that is causing the block.

If I am running a Trace, I can see the exact stored procedures
including the parameters that every cmd is running.

Is there a way to see that same Trace information when looking for
blocked users in master.dbo.sysprocesses, or in some other place?

Ideally what I want is a list of blocked users, who is causing the
blocks and the stored procedure name (or other mischief) causing the
block.

Any help is appreciated.
lqYou can do this, run sp_who2
there is a field named BlkBy grab the id
run DBCC INPUTBUFFER (ID) to get the SQL statement

http://sqlservercode.blogspot.com/|||Is there a way to get the EXEC ('DBCC INPUTBUFFER (BlkBy) WITH
NO_INFOMSGS')) to become a column in the resulting SELECT statement?

CREATE TABLE #SystemUsers (id int identity, SPID int, BlockerLoginame
nvarchar(255), BlockingSQL nvarchar(2000))

INSERT INTO #SystemUsers (SPID, BlockerLoginame, BlockingSQL)
SELECT
SPID,
loginame,
/* (EXEC ('DBCC INPUTBUFFER (BlkBy) WITH NO_INFOMSGS')) As BlockingSQL
??? */
FROM master.dbo.sysprocesses

SELECT
s.spid,
status,
loginame,
hostname,
cmd,
cpu,
last_batch,
login_time,
kpid,
blocked,
x.BlockerLoginame,
waittype,
waittime,
lastwaittype,
waitresource,
dbid,
uid,
memusage,
ecid,
open_tran,
sid,
hostprocess,
nt_domain,
nt_username,
net_address,
net_library,
context_info
FROM master.dbo.sysprocesses s
LEFT OUTER JOIN #SystemUsers x ON x.SPID = s.Blocked
WHERE Blocked >0|||Insert the result of sp_who2 into a table
Delete everything where BlkBy is empty
Loop thru this table and insert the DBCC inputbuffer result into
another table
Join this last table with sysprocesses

http://sqlservercode.blogspot.com/|||This is the part I'm not sure how to write:
"Loop thru this table and insert the DBCC inputbuffer result into
another table"|||laurenq uantrell (laurenquantrell@.hotmail.com) writes:
> In master.dbo.sysprocesses I can filter for blocked users (Blocked >0)
> and I can create a self join(ON SPID = Blocked) to see what user
> Loginame is causing the block. In the column [cmd] I can see the
> command that the offending blocker is running to cause the block, but
> it only says "SELECT" etc. with no details about the stored procedure
> that is causing the block.
> If I am running a Trace, I can see the exact stored procedures
> including the parameters that every cmd is running.
> Is there a way to see that same Trace information when looking for
> blocked users in master.dbo.sysprocesses, or in some other place?
> Ideally what I want is a list of blocked users, who is causing the
> blocks and the stored procedure name (or other mischief) causing the
> block.

More so, provided that the stored procedures are not encrpyted, you
can get the exact SQL code they are executing. And, no, no need for a
lot of coding. I've already done it for you. :-)

http://www.sommarskog.se/sqlutil/aba_lockinfo.html sounds exactly what
you are looking for.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||laurenq uantrell wrote:
> This is the part I'm not sure how to write:
> "Loop thru this table and insert the DBCC inputbuffer result into
> another table"

I admit I didn't read your post in detail, but I suspect that
fn_get_sql() is what you're looking for - it's more useful than DBCC
INPUTBUFFER. See Books Online for more details; if it's not mentioned in
your current version of BOL then you should get the latest version from
here:

http://www.microsoft.com/sql/techin.../2000/books.asp

But since Erland uses this function in the procedure that he mentioned,
you might well find it easier just to use that.

Simon|||Whew. That's a hefty amount of code, which seems much more complex
than:
"Insert the result of sp_who2 into a table
Delete everything where BlkBy is empty
Loop thru this table and insert the DBCC inputbuffer result into
another table
Join this last table with sysprocesses"

Thanks for that.
Is there a way to force some blocking so that I can test it?|||The next step is to run this every 60 seconds and export the results to
a text file using bcp...
I know that in my original post:

SELECT
SPID,
loginame
FROM master.dbo.sysprocesses
WHERE
BlkBy > 0

will get the ball rolling if a blocking situation exists.

But looking at your aba_lockinfo sproc I'm not sure where to start
something like:

if exists (SELECT * FROM master.dbo.sysprocesses WHERE BlkBy > 0)
begin
/* Blocking exisit so use Erland's aba_lockinfo sproc to BCP to a
text file */
end|||laurenq uantrell (laurenquantrell@.hotmail.com) writes:
> Whew. That's a hefty amount of code, which seems much more complex
> than:
> "Insert the result of sp_who2 into a table
> Delete everything where BlkBy is empty
> Loop thru this table and insert the DBCC inputbuffer result into
> another table
> Join this last table with sysprocesses"
> Thanks for that.
> Is there a way to force some blocking so that I can test it?

In one window:

BEGIN TRANSACTION
CREATE TABLE #tmp (a int NOT NULL)

In other another

SELECT * FROM tempdb..sysobjects

> The next step is to run this every 60 seconds and export the results to
> a text file using bcp...

BCP with queryout would work in theory, but queryout is known to be
troublesome. The fact the column lengths may very from execution to
execution may also be aggrevate things.

You could also create a table that matches the output from aba_lockinfo,
and then run INSERT EXEC to that table. Again, the dynamic field lengths
could cause some problems, but just make your columns wide enough.

But I would rather just run it from OSQL with output directed to a file.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||I didn't realize I'm not running SP3 until trying to run fn_get_sql and
realizing I don't have a column SqlHandle in master.sysprocesses|||laurenq uantrell (laurenquantrell@.hotmail.com) writes:
> I didn't realize I'm not running SP3 until trying to run fn_get_sql and
> realizing I don't have a column SqlHandle in master.sysprocesses

Since there are other good reasons to upgrade to SP3 - that is Slammer -
I would recommend that you do that. (But there is a pre-SP3 version as
well of aba_lockinfo.)

By the way, I would not recommend that you try to extract pieces of that
code. I mean, it's fairly complex.

(And I will have to rewrite it entirely for SQL 2005...)

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||Erland,
Yes I saw that and have grabbed the pre-SP3 version. I caused the
interntional blocking with the open transaction as you mentioned, see
the blocking reported in aba_lockinfo, but I don't see reference to the
name of the specific sproc causing the block.|||laurenq uantrell (laurenquantrell@.hotmail.com) writes:
> Yes I saw that and have grabbed the pre-SP3 version. I caused the
> interntional blocking with the open transaction as you mentioned, see
> the blocking reported in aba_lockinfo, but I don't see reference to the
> name of the specific sproc causing the block.

No, you need to upgrade to SP3 to get that information. Pre-SP3 this
informatin was not available.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||Yes, I upgraded to SQL Server 2000 SP3a and now it's all clear to me
how this works. Now to execute it as a scheduled process and output it
to a text file on a regular basis...|||uh more importantly.. can't you reccomend upgrading to SP4?

i think that people that don't apply patches should be fired on the spot|||In the real world, sometimes there are reasons why patches are not
applied, but I'm certain we all appreciate your well thought comment,
and those to come.|||In the real world, sometimes there are reasons why patches are not
applied, but I'm certain we all appreciate your well thought comment,
and those to come.