Hello all
I am about to begin a project that will be implemented in a local company. It involves using an IVR(interactive voice response) to collect information with regards a customer satisfaction survey. The results are then to be presented on the web. Thus I have an IVR connected to a database which is connected to the web. The results are to be presented in stats and graphs on the web.
I was originally going to use an Oracle database however it has worked out that it is not feesable to use Oracle for such a small application. I am now looking at SQL server. However, I have never dealt with it before. I have extensive knowledge of SQL. What I need to know is SQL server suitable to use when it comes to connecting to a web application, querying the data to show graphs and stats and is it easy to learn for a person who has extensive knowledge of databases? Id appreciate your knowledge and advice on this topicHowdy,
Greetings from sunny Surrey in the UK!!
Well the short answer is - yes - if you are willing to take the time to learn SQLs eccentricities.
Regards size , we have 5 MB databases running ( some with web app links ) so small isnt an issue.
SQL Server is pretty easy to learn, and if you are just quering the database or writing data into it from a web app, it should all be straight forward. Mind you...how long is a bit of string?
Do you have a DBA to set up the server or are you it?
Cheers,
SGsql
Showing posts with label project. Show all posts
Showing posts with label project. Show all posts
Friday, March 30, 2012
Monday, March 26, 2012
Item not linked to dataset, and "table1" issue
Hi--
I have a report project in VS (2003). I have a report in that project that was working properly. I copied objects from that report to a new one and created a new dataset for the new report (under it's Data tab). Though both datasets (for each of the reports) seem healthy, i.e., they produce data when run, I am now experiencing the following problems:
1. In both reports, the datasets seem to be unlinked, somehow. I know this by right clicking on a field of the report, going to expressions, then selecting the Fields node. Instead of listing fields, as used to be the case, it now says "Report item not linked to a dataset."
2. If I attempt to preview either of the reports, I get an error that reads, "The table 'table1' refers to an invalid dataset name 'MedMgmt.' MedMgmt is the dataset name of the first report. I changed it to another name, but I still get the same message.
I have clicked and right-clicked everywhere and have not found a way to re-link the dataset to the report. Why Reporting Services can't figure out that the dataset in the report's Data tab is the dataset to link to is a point of deep annoyance, but whatever... If anyone can please help me solve these problems, I would be very grateful! Thank you!
I have exactly the same problem. Only way around it (for me) so far has been to build the report all over and let the wizard link it, then copy the elements 1 by 1 from original... real pain...
There's GOT to be a better way?
|||I think i know what it is. What is this object you are looking to link? If its a table, List, or Matrix : Right click the object (make sure the whole object is selected and click properties. if properties slides out Scroll down to "Dataset Name", there should be a drop down which all the datasets in your report. Select the one you are grabbing you attributes from. The reason your getting that error is, the object is linked to dataset names from your other report (since you copied them over). So you need to change the dataset names for each object. This is why it shows the name of your dataset from your other report.
IF the properties box opens up for the table/matrix/list , then you should see (3 textboxes down) "Dataset Name". if its empty or has something in it...i would click the dropdown anyways, and make sure the right dataset it selected.
I hope this helps!
Item not linked to dataset, and "table1" issue
Hi--
I have a report project in VS (2003). I have a report in that project that was working properly. I copied objects from that report to a new one and created a new dataset for the new report (under it's Data tab). Though both datasets (for each of the reports) seem healthy, i.e., they produce data when run, I am now experiencing the following problems:
1. In both reports, the datasets seem to be unlinked, somehow. I know this by right clicking on a field of the report, going to expressions, then selecting the Fields node. Instead of listing fields, as used to be the case, it now says "Report item not linked to a dataset."
2. If I attempt to preview either of the reports, I get an error that reads, "The table 'table1' refers to an invalid dataset name 'MedMgmt.' MedMgmt is the dataset name of the first report. I changed it to another name, but I still get the same message.
I have clicked and right-clicked everywhere and have not found a way to re-link the dataset to the report. Why Reporting Services can't figure out that the dataset in the report's Data tab is the dataset to link to is a point of deep annoyance, but whatever... If anyone can please help me solve these problems, I would be very grateful! Thank you!
I have exactly the same problem. Only way around it (for me) so far has been to build the report all over and let the wizard link it, then copy the elements 1 by 1 from original... real pain...
There's GOT to be a better way?
|||I think i know what it is. What is this object you are looking to link? If its a table, List, or Matrix : Right click the object (make sure the whole object is selected and click properties. if properties slides out Scroll down to "Dataset Name", there should be a drop down which all the datasets in your report. Select the one you are grabbing you attributes from. The reason your getting that error is, the object is linked to dataset names from your other report (since you copied them over). So you need to change the dataset names for each object. This is why it shows the name of your dataset from your other report.
IF the properties box opens up for the table/matrix/list , then you should see (3 textboxes down) "Dataset Name". if its empty or has something in it...i would click the dropdown anyways, and make sure the right dataset it selected.
I hope this helps!
Friday, March 23, 2012
IT Project Failure Rates
Different projects have different definitions of "failing". I can tell you
that from my perspective more than 35%, perhaps 50% or more, of projects at
least go over budget. It's entirely plausable that 35% are either aborted
before completion or completely re-engineered before their original life
expectancy expires. The weakest link is typically poor system design
documentation and middle tier project leadership.
"Jordan R." <JordanRemoveThis3481@.ComCast.net> wrote in message
news:Oyk9q%23Z6FHA.4012@.TK2MSFTNGP14.phx.gbl...
> I'm posting to this question to the selected NGs because I'm interested in
> getting the viewpoint from within the "trenches" (not from academia or the
> big consulting firms).
> At the launch last Monday, one of Steve Ballmer's early slides presented
> the fact that something like 35% of IT projects fail. I just did a bit of
> research and found lots of studies supporting that point (e.g.,
> http://www.it-cortex.com/Stat_Failure_Rate.htm).
> Apparently projects fail on a number of measures... way over budget, way
> behind schedule, business objectives of the system not met within one year
> of going live, etc...
> Just wondering what some of your opinions are for *why* the failure rates
> are so high? I mean, with all the "smart" programmers out there, how come
> projects fail so often (or is it the IT managers who fail? Both? Other?).
> I'm thinking there has to be common thread amongst these failures and
> lessons to be learned.
> Thanks.
>Thank you JT and others.
What do you all think is the *likelihood* that big projects fail because,
for various reasons many people on the project *want* for the failure to
happen? Apparently the larger the budget the more likely the failure. Of the
various definitions of "failure" two involve [over budget] and [way beyond
deadline]. Practically everybody on a large team *benefits* from those
specific and prevalent types of failure (EXCEPT perhaps for the people who
are *paying* for the system in question and of course the users). You budget
8 million dollars for a project and suddenly you need a whole army of people
to manage (spend) that money. Anyone who can pay 8 million for a system can
surely pay 9 million and maybe even 10 million. You get to 10 million,
you're 6 months behind schedule and you can finish it for just another 1.5
mil. What happens if things happen on budget and on time. Well, that whole
army hired to build the system is suddenly out of work. The cash cow is gone
and everybody has to suddenly justify thier positions. But keep the project
going and... well.. you get the picture. Of course we all know how easy it
is to diffuse responsibility on any IT failure of any size (i.e. get off the
hook "scott free").
Thoughts?
"JT" <someone@.microsoft.com> wrote in message
news:uTET03e6FHA.2192@.TK2MSFTNGP14.phx.gbl...
> Different projects have different definitions of "failing". I can tell you
> that from my perspective more than 35%, perhaps 50% or more, of projects
> at least go over budget. It's entirely plausable that 35% are either
> aborted before completion or completely re-engineered before their
> original life expectancy expires. The weakest link is typically poor
> system design documentation and middle tier project leadership.
> "Jordan R." <JordanRemoveThis3481@.ComCast.net> wrote in message
> news:Oyk9q%23Z6FHA.4012@.TK2MSFTNGP14.phx.gbl...
>|||"Jordan R." <JordanRemoveThis3481@.ComCast.net> wrote in message
news:OTPacAg6FHA.2156@.TK2MSFTNGP14.phx.gbl...
> Thank you JT and others.
> What do you all think is the *likelihood* that big projects fail because,
> for various reasons many people on the project *want* for the failure to
> happen? Apparently the larger the budget the more likely the failure. Of
> the various definitions of "failure" two involve [over budget] and [way
> beyond deadline]. Practically everybody on a large team *benefits* from
> those specific and prevalent types of failure (EXCEPT perhaps for the
> people who are *paying* for the system in question and of course the
> users). You budget 8 million dollars for a project and suddenly you need a
> whole army of people to manage (spend) that money. Anyone who can pay 8
> million for a system can surely pay 9 million and maybe even 10 million.
> You get to 10 million, you're 6 months behind schedule and you can finish
> it for just another 1.5 mil. What happens if things happen on budget and
> on time. Well, that whole army hired to build the system is suddenly out
> of work. The cash cow is gone and everybody has to suddenly justify thier
> positions. But keep the project going and... well.. you get the picture.
> Of course we all know how easy it is to diffuse responsibility on any IT
> failure of any size (i.e. get off the hook "scott free").
> Thoughts?
First of all, if you work for a company where all software projects fail,
how long do you think that company will stay in business?
I find that Cash Cows have a very short life span (if you exclude
government).
If you're out for a quick buck, find a cash cow.
If you want to make a career of this, find a company that has a proven
development track record, one that takes budgets and deadlines seriously.
Second, I'd rather have on my resume the fact that I work(ed) for a company
that had a 50% development success rate than a 10% one.
I'd rather also hire that person.|||Thanks Raymond. I agree with all your points. Also, this isn't about me.
It's about those 35% that reportedly fail. Also, in a big mega corporation
or big bank, 8 million can get totally blown and nobody gets fired and the
business just keeps chugging along. Small cash cows can't last long - but if
the cow is big enough it can get repeatedly milked.
> First of all, if you work for a company where all software projects fail,
> how long do you think that company will stay in business?
> I find that Cash Cows have a very short life span (if you exclude
> government).
> If you're out for a quick buck, find a cash cow.
> If you want to make a career of this, find a company that has a proven
> development track record, one that takes budgets and deadlines seriously.
> Second, I'd rather have on my resume the fact that I work(ed) for a
> company that had a 50% development success rate than a 10% one.
> I'd rather also hire that person.|||In many cases the scope of the system currently under development bears
little resemblance to the scope as defined in the original requirements
documents. It's not that the developers are taking twice or thrice as long
to complete the project, but that the project management and client allowed
the scope to creep wihout going back and extending the requirements and
budget. Some clients actually like this informal arrangement, becuase they
don't feel painted into a corner, and becuase they think they are saving
money by not putting additional effort into hard analysis and design. They
simply expect the contractors to keep them happy from one day to the next,
and in return they keep the money trickling in. In that case, you are
basically an IT whore. If this is what you choose or if your options are
limited, then at least make sure they are paying you well.
As for situations where the developers (or even the factions within the
client's own organization) actually want the project to fail; this is can
happen for a number of reasons. If you think you are observing it, then it
may not simply be your paranoid imagination, and if you are independent
consultant, then it was probably the plan from the very start. Ed Yourdon
describes this in his book "Death March: The complete software developer's
guide to surviving projects that are "doomed to fail.".
http://www.informit.com/bookstore/p...0146595&redir=1
"Jordan R." <JordanRemoveThis3481@.ComCast.net> wrote in message
news:OTPacAg6FHA.2156@.TK2MSFTNGP14.phx.gbl...
> Thank you JT and others.
> What do you all think is the *likelihood* that big projects fail because,
> for various reasons many people on the project *want* for the failure to
> happen? Apparently the larger the budget the more likely the failure. Of
> the various definitions of "failure" two involve [over budget] and [way
> beyond deadline]. Practically everybody on a large team *benefits* from
> those specific and prevalent types of failure (EXCEPT perhaps for the
> people who are *paying* for the system in question and of course the
> users). You budget 8 million dollars for a project and suddenly you need a
> whole army of people to manage (spend) that money. Anyone who can pay 8
> million for a system can surely pay 9 million and maybe even 10 million.
> You get to 10 million, you're 6 months behind schedule and you can finish
> it for just another 1.5 mil. What happens if things happen on budget and
> on time. Well, that whole army hired to build the system is suddenly out
> of work. The cash cow is gone and everybody has to suddenly justify thier
> positions. But keep the project going and... well.. you get the picture.
> Of course we all know how easy it is to diffuse responsibility on any IT
> failure of any size (i.e. get off the hook "scott free").
> Thoughts?
>
>
> "JT" <someone@.microsoft.com> wrote in message
> news:uTET03e6FHA.2192@.TK2MSFTNGP14.phx.gbl...
>|||Jordan R. wrote:
> Thank you JT and others.
> What do you all think is the *likelihood* that big projects fail because,
> for various reasons many people on the project *want* for the failure to
> happen? Apparently the larger the budget the more likely the failure. Of t
he
> various definitions of "failure" two involve [over budget] and [way beyond
> deadline]. Practically everybody on a large team *benefits* from those
> specific and prevalent types of failure (EXCEPT perhaps for the people who
> are *paying* for the system in question and of course the users). You budg
et
> 8 million dollars for a project and suddenly you need a whole army of peop
le
> to manage (spend) that money. Anyone who can pay 8 million for a system ca
n
> surely pay 9 million and maybe even 10 million. You get to 10 million,
> you're 6 months behind schedule and you can finish it for just another 1.5
> mil. What happens if things happen on budget and on time. Well, that whole
> army hired to build the system is suddenly out of work. The cash cow is go
ne
> and everybody has to suddenly justify thier positions. But keep the projec
t
> going and... well.. you get the picture. Of course we all know how easy it
> is to diffuse responsibility on any IT failure of any size (i.e. get off t
he
> hook "scott free").
> Thoughts?
The likelihood? No earthly idea how to evaluate that. It *can* happen that
way
- but might that not suggest that management is somehow providing an incenti
ve
when it does?
Really I have to agree with Fred E. here - there are a *lot* of holes that l
arge
projects can fall into - and most of them were identified quite well by Broo
ks
many years ago.
JT, in your original post you sounded like you were just curious in an acade
mic
way about how and why IT projects fail. Now though you are sounding more li
ke
someone who has been badly burned recently. Is this correct? If so, this m
akes
me curious about your POV - developer, architect, project manager, product
manager, innocent bystander or . . . ?
-rick-|||Re:
<< JT, in your original post you sounded like you were just curious in an
academic
> way about how and why IT projects fail. Now though you are sounding more
> like someone who has been badly burned recently. Is this correct? If so,
> this makes me curious about your POV - developer, architect, project
> manager, product manager, innocent bystander or . . . ?
Are you referring to JT or the the original poster? I'm the latter.
To answer your question, I was the "technical lead" (that's the title they
gave to me anyway) on a large system at a large company. The system was
great. Me and another guy architected then built it from scratch (designed
the database, wrote all the code, and lead a team of support developers to
complete the implementation). We delivered, hit our Y2K deadline with room
to spare, and life was good for a couple of years. Then new management came
in and they wanted [a system] like ours that had - say 14 features. We went
to them with "good news" and said we already had 11 of those features and
the remaining could be added within 9 months (a perfectly acceptable time
line to them). Strangely, a few of us who knew how easily the existing
system could be extended to meet all desires/needs got railroaded out of
town. After I left they ended up budgeting millions of dollars for a
complete new/replacement system. Fast forward 2.5 years to the present. They
just canned the whole new system and completely migrated back to the one I
had left them with years before. In fact they never completely migrated OFF
of my system. In other words they are part of the 35% that fail (in their
case both over budget and way over deadline). They even hired an outside
consulting firm to come in and advise on how to fix the replacement system.
The outside firm basically told them it could not be fixed. In essence -
they totally failed. Then last w
Ballmer presents his 35% failure rate
and I do some research to see who else is saying that. Until learning that
this sort of huge failure happens all the time, I had chalked up my former
client's situation to the particular organization. But if it's happening all
them time, then come on - there's more going on than just bad planning or
poor project management. I think it's plain and simple *greed* at
practically all levels that may be the "Super Explanation" from which the
poor planning and managemnet and communication etc flow. Yes, all those
other things happen all the time. But come on. They are continually
*allowed* to happen. Why are they allowed to happen all the time? Greed -
IMO.
Please don't think this thread is all about any old grudge. I'm several
years removed from all that. I was just surprised to see that it happens in
many organizations OTHER than the one I was in. That's why I'm looking to my
peers here in these NGs to learn what you are all seeing. I think I have to
ask you because if I were to just listen to academia and big consulting
firms or software vendors peddling their Team solutions then I'd be lead to
believe that we just need to communicate better; test earlier; test more
systematically; have UML save the day; organize ourselves into 2-person
developer teams (i.e. Extreme methodologies). etc. But none of those address
greed and the associated desire (unconscious perhaps) for systems to go over
budget and beyond deadline or ultimately fail.
Thanks for your feedback.|||Jordan R. was the OP, but any of us who have been in IT for more than 10
years have a story to tell.
"Rick Lones" <WrlonesX@.YcharterZ.net> wrote in message
news:%Psef.73821$RG4.16336@.fe05.lga...
> Jordan R. wrote:
> The likelihood? No earthly idea how to evaluate that. It *can* happen
> that way - but might that not suggest that management is somehow providing
> an incentive when it does?
> Really I have to agree with Fred E. here - there are a *lot* of holes that
> large projects can fall into - and most of them were identified quite well
> by Brooks many years ago.
> JT, in your original post you sounded like you were just curious in an
> academic way about how and why IT projects fail. Now though you are
> sounding more like someone who has been badly burned recently. Is this
> correct? If so, this makes me curious about your POV - developer,
> architect, project manager, product manager, innocent bystander or . . . ?
> -rick-|||Jordan R. wrote:
> Re:
> << JT, in your original post you sounded like you were just curious in an
> academic
>
>
> Are you referring to JT or the the original poster? I'm the latter.
To you, Jordan - thanks for the clarification.
> To answer your question, I was the "technical lead" (that's the title they
> gave to me anyway) on a large system at a large company. The system was
> great. Me and another guy architected then built it from scratch (designed
> the database, wrote all the code, and lead a team of support developers to
> complete the implementation). We delivered, hit our Y2K deadline with room
> to spare, and life was good for a couple of years. Then new management cam
e
> in and they wanted [a system] like ours that had - say 14 features. We wen
t
> to them with "good news" and said we already had 11 of those features and
> the remaining could be added within 9 months (a perfectly acceptable time
> line to them). Strangely, a few of us who knew how easily the existing
> system could be extended to meet all desires/needs got railroaded out of
> town. After I left they ended up budgeting millions of dollars for a
> complete new/replacement system. Fast forward 2.5 years to the present. Th
ey
> just canned the whole new system and completely migrated back to the one I
> had left them with years before. In fact they never completely migrated OF
F
> of my system. In other words they are part of the 35% that fail (in their
> case both over budget and way over deadline). They even hired an outside
> consulting firm to come in and advise on how to fix the replacement system
.
> The outside firm basically told them it could not be fixed. In essence -
> they totally failed.
Wow - quite a story. Any chance you can still sell them those remaining 3
enhancements? Your credibility should be way up with them by now. :)
Then last w Ballmer presents his 35% failure rate
> and I do some research to see who else is saying that. Until learning that
> this sort of huge failure happens all the time, I had chalked up my former
> client's situation to the particular organization. But if it's happening a
ll
> them time, then come on - there's more going on than just bad planning or
> poor project management. I think it's plain and simple *greed* at
> practically all levels that may be the "Super Explanation" from which the
> poor planning and managemnet and communication etc flow. Yes, all those
> other things happen all the time. But come on. They are continually
> *allowed* to happen. Why are they allowed to happen all the time? Greed -
> IMO.
Truthfully, I think that the demand for large complex systems has way
outstripped the supply of people qualified to build them. Hence the rise of
RAD
environments and powerful paradigms and languages such as OO and C++ which t
o
some hold out the promise of some silver bullet. To take C++ as an example:
IMO
this is a sophisticated language, quite well worked out by a smart well-educ
ated
guy - and completely appropriate for use on large engineering projects by ot
her
smart well-educated people. But in the wrong hands it's just a great way to
make a huge mess quickly - and with the best of intentions. I don't mean to
claim that most programmers are too stupid to understand OO or C++, but many
who
use these tools seem insufficiently prepared and/or lacking the experience t
o
use them well. And if you are using them less than well then IMO you just m
ight
have been better off with COBOL . . .
> Please don't think this thread is all about any old grudge. I'm several
> years removed from all that. I was just surprised to see that it happens i
n
> many organizations OTHER than the one I was in.
Everybody always seems to overestimate other people's competence. It's stil
l
true that 90% of *everything* is crap - and this includes management teams.
Programming isn't easy and most people can't do it at all, let alone well.
That's why I'm looking to my
> peers here in these NGs to learn what you are all seeing. I think I have t
o
> ask you because if I were to just listen to academia and big consulting
> firms or software vendors peddling their Team solutions then I'd be lead t
o
> believe that we just need to communicate better; test earlier; test more
> systematically; have UML save the day; organize ourselves into 2-person
> developer teams (i.e. Extreme methodologies). etc. But none of those addre
ss
> greed and the associated desire (unconscious perhaps) for systems to go ov
er
> budget and beyond deadline or ultimately fail.
Hmm, I *think* I see what you are getting at here - the proposed remedies se
ldom
rise above being just more magic bullets. "Do A, do B, do C, then your prob
lems
will be over and your organization will have (somehow) become competent." I
t
seems a bit naive, but the overselling of methodologies is ubiquitous.
I am not so sure about fingering greed and spooky unconscious motivations as
the
root of all problems though. Among other things we are all in this hoping t
o
make a living. Now if what you are pointing out is, "beware, the whole syst
em
is badly broken", then I might even agree - but IT system development is har
dly
the most pressing example of that.
Regards,
-rick-|||Re:
<<Any chance you can still sell them those remaining 3 enhancements? Your
credibility should be way up with them by now. :) >>
No way man! I had all the credibility I needed back when they initiated this
debacle. It's not at all about credibility - never was. I had as much of
that as anyone can get. (actually had one of those "only heard about" 20
minute - to - 20 second process enhancements to my credit; the internal
customers loved me for that one).
It apparently was *really* about them spending 8 mil.
Here's how it went (I'm pretty sure, in retrospect)
Me: "hey - check this out - you can have everything you want - all for about
300 large in about 9-10 months"
Them: "ohMyGosh - I can't build my little internal corporate empire if word
about this gets out. I just proposed a multimillion dollar system that got
approved. There's no way I can go back on that. Plus I just hired my
Alcoholics Anonymous Buddy as my admin assistant. I can't put us both out of
work..."
Now, looking forward for them, they're back a "square 1" with this system.
No one was fired over this - so we can know there were no *real* penalties
for failure. So this leaves them to do - guess what - propose the next
system! It's going to get its own budget too... same people in charge...
Re:
<<I am not so sure about fingering greed and spooky unconscious motivations
as the root of all problems though. Among other things we are all in this
hoping to make a living.>>
LOL - agreed about the spooky motives thing. But there is more of a living
to be made in many situations when the project fails (when, of course, there
is no real penalty for failure). That's all I'm trying to find out here - if
others see the same thing in their organizations.
I appreciate your perspective Rick.
that from my perspective more than 35%, perhaps 50% or more, of projects at
least go over budget. It's entirely plausable that 35% are either aborted
before completion or completely re-engineered before their original life
expectancy expires. The weakest link is typically poor system design
documentation and middle tier project leadership.
"Jordan R." <JordanRemoveThis3481@.ComCast.net> wrote in message
news:Oyk9q%23Z6FHA.4012@.TK2MSFTNGP14.phx.gbl...
> I'm posting to this question to the selected NGs because I'm interested in
> getting the viewpoint from within the "trenches" (not from academia or the
> big consulting firms).
> At the launch last Monday, one of Steve Ballmer's early slides presented
> the fact that something like 35% of IT projects fail. I just did a bit of
> research and found lots of studies supporting that point (e.g.,
> http://www.it-cortex.com/Stat_Failure_Rate.htm).
> Apparently projects fail on a number of measures... way over budget, way
> behind schedule, business objectives of the system not met within one year
> of going live, etc...
> Just wondering what some of your opinions are for *why* the failure rates
> are so high? I mean, with all the "smart" programmers out there, how come
> projects fail so often (or is it the IT managers who fail? Both? Other?).
> I'm thinking there has to be common thread amongst these failures and
> lessons to be learned.
> Thanks.
>Thank you JT and others.
What do you all think is the *likelihood* that big projects fail because,
for various reasons many people on the project *want* for the failure to
happen? Apparently the larger the budget the more likely the failure. Of the
various definitions of "failure" two involve [over budget] and [way beyond
deadline]. Practically everybody on a large team *benefits* from those
specific and prevalent types of failure (EXCEPT perhaps for the people who
are *paying* for the system in question and of course the users). You budget
8 million dollars for a project and suddenly you need a whole army of people
to manage (spend) that money. Anyone who can pay 8 million for a system can
surely pay 9 million and maybe even 10 million. You get to 10 million,
you're 6 months behind schedule and you can finish it for just another 1.5
mil. What happens if things happen on budget and on time. Well, that whole
army hired to build the system is suddenly out of work. The cash cow is gone
and everybody has to suddenly justify thier positions. But keep the project
going and... well.. you get the picture. Of course we all know how easy it
is to diffuse responsibility on any IT failure of any size (i.e. get off the
hook "scott free").
Thoughts?
"JT" <someone@.microsoft.com> wrote in message
news:uTET03e6FHA.2192@.TK2MSFTNGP14.phx.gbl...
> Different projects have different definitions of "failing". I can tell you
> that from my perspective more than 35%, perhaps 50% or more, of projects
> at least go over budget. It's entirely plausable that 35% are either
> aborted before completion or completely re-engineered before their
> original life expectancy expires. The weakest link is typically poor
> system design documentation and middle tier project leadership.
> "Jordan R." <JordanRemoveThis3481@.ComCast.net> wrote in message
> news:Oyk9q%23Z6FHA.4012@.TK2MSFTNGP14.phx.gbl...
>|||"Jordan R." <JordanRemoveThis3481@.ComCast.net> wrote in message
news:OTPacAg6FHA.2156@.TK2MSFTNGP14.phx.gbl...
> Thank you JT and others.
> What do you all think is the *likelihood* that big projects fail because,
> for various reasons many people on the project *want* for the failure to
> happen? Apparently the larger the budget the more likely the failure. Of
> the various definitions of "failure" two involve [over budget] and [way
> beyond deadline]. Practically everybody on a large team *benefits* from
> those specific and prevalent types of failure (EXCEPT perhaps for the
> people who are *paying* for the system in question and of course the
> users). You budget 8 million dollars for a project and suddenly you need a
> whole army of people to manage (spend) that money. Anyone who can pay 8
> million for a system can surely pay 9 million and maybe even 10 million.
> You get to 10 million, you're 6 months behind schedule and you can finish
> it for just another 1.5 mil. What happens if things happen on budget and
> on time. Well, that whole army hired to build the system is suddenly out
> of work. The cash cow is gone and everybody has to suddenly justify thier
> positions. But keep the project going and... well.. you get the picture.
> Of course we all know how easy it is to diffuse responsibility on any IT
> failure of any size (i.e. get off the hook "scott free").
> Thoughts?
First of all, if you work for a company where all software projects fail,
how long do you think that company will stay in business?
I find that Cash Cows have a very short life span (if you exclude
government).
If you're out for a quick buck, find a cash cow.
If you want to make a career of this, find a company that has a proven
development track record, one that takes budgets and deadlines seriously.
Second, I'd rather have on my resume the fact that I work(ed) for a company
that had a 50% development success rate than a 10% one.
I'd rather also hire that person.|||Thanks Raymond. I agree with all your points. Also, this isn't about me.
It's about those 35% that reportedly fail. Also, in a big mega corporation
or big bank, 8 million can get totally blown and nobody gets fired and the
business just keeps chugging along. Small cash cows can't last long - but if
the cow is big enough it can get repeatedly milked.
> First of all, if you work for a company where all software projects fail,
> how long do you think that company will stay in business?
> I find that Cash Cows have a very short life span (if you exclude
> government).
> If you're out for a quick buck, find a cash cow.
> If you want to make a career of this, find a company that has a proven
> development track record, one that takes budgets and deadlines seriously.
> Second, I'd rather have on my resume the fact that I work(ed) for a
> company that had a 50% development success rate than a 10% one.
> I'd rather also hire that person.|||In many cases the scope of the system currently under development bears
little resemblance to the scope as defined in the original requirements
documents. It's not that the developers are taking twice or thrice as long
to complete the project, but that the project management and client allowed
the scope to creep wihout going back and extending the requirements and
budget. Some clients actually like this informal arrangement, becuase they
don't feel painted into a corner, and becuase they think they are saving
money by not putting additional effort into hard analysis and design. They
simply expect the contractors to keep them happy from one day to the next,
and in return they keep the money trickling in. In that case, you are
basically an IT whore. If this is what you choose or if your options are
limited, then at least make sure they are paying you well.
As for situations where the developers (or even the factions within the
client's own organization) actually want the project to fail; this is can
happen for a number of reasons. If you think you are observing it, then it
may not simply be your paranoid imagination, and if you are independent
consultant, then it was probably the plan from the very start. Ed Yourdon
describes this in his book "Death March: The complete software developer's
guide to surviving projects that are "doomed to fail.".
http://www.informit.com/bookstore/p...0146595&redir=1
"Jordan R." <JordanRemoveThis3481@.ComCast.net> wrote in message
news:OTPacAg6FHA.2156@.TK2MSFTNGP14.phx.gbl...
> Thank you JT and others.
> What do you all think is the *likelihood* that big projects fail because,
> for various reasons many people on the project *want* for the failure to
> happen? Apparently the larger the budget the more likely the failure. Of
> the various definitions of "failure" two involve [over budget] and [way
> beyond deadline]. Practically everybody on a large team *benefits* from
> those specific and prevalent types of failure (EXCEPT perhaps for the
> people who are *paying* for the system in question and of course the
> users). You budget 8 million dollars for a project and suddenly you need a
> whole army of people to manage (spend) that money. Anyone who can pay 8
> million for a system can surely pay 9 million and maybe even 10 million.
> You get to 10 million, you're 6 months behind schedule and you can finish
> it for just another 1.5 mil. What happens if things happen on budget and
> on time. Well, that whole army hired to build the system is suddenly out
> of work. The cash cow is gone and everybody has to suddenly justify thier
> positions. But keep the project going and... well.. you get the picture.
> Of course we all know how easy it is to diffuse responsibility on any IT
> failure of any size (i.e. get off the hook "scott free").
> Thoughts?
>
>
> "JT" <someone@.microsoft.com> wrote in message
> news:uTET03e6FHA.2192@.TK2MSFTNGP14.phx.gbl...
>|||Jordan R. wrote:
> Thank you JT and others.
> What do you all think is the *likelihood* that big projects fail because,
> for various reasons many people on the project *want* for the failure to
> happen? Apparently the larger the budget the more likely the failure. Of t
he
> various definitions of "failure" two involve [over budget] and [way beyond
> deadline]. Practically everybody on a large team *benefits* from those
> specific and prevalent types of failure (EXCEPT perhaps for the people who
> are *paying* for the system in question and of course the users). You budg
et
> 8 million dollars for a project and suddenly you need a whole army of peop
le
> to manage (spend) that money. Anyone who can pay 8 million for a system ca
n
> surely pay 9 million and maybe even 10 million. You get to 10 million,
> you're 6 months behind schedule and you can finish it for just another 1.5
> mil. What happens if things happen on budget and on time. Well, that whole
> army hired to build the system is suddenly out of work. The cash cow is go
ne
> and everybody has to suddenly justify thier positions. But keep the projec
t
> going and... well.. you get the picture. Of course we all know how easy it
> is to diffuse responsibility on any IT failure of any size (i.e. get off t
he
> hook "scott free").
> Thoughts?
The likelihood? No earthly idea how to evaluate that. It *can* happen that
way
- but might that not suggest that management is somehow providing an incenti
ve
when it does?
Really I have to agree with Fred E. here - there are a *lot* of holes that l
arge
projects can fall into - and most of them were identified quite well by Broo
ks
many years ago.
JT, in your original post you sounded like you were just curious in an acade
mic
way about how and why IT projects fail. Now though you are sounding more li
ke
someone who has been badly burned recently. Is this correct? If so, this m
akes
me curious about your POV - developer, architect, project manager, product
manager, innocent bystander or . . . ?
-rick-|||Re:
<< JT, in your original post you sounded like you were just curious in an
academic
> way about how and why IT projects fail. Now though you are sounding more
> like someone who has been badly burned recently. Is this correct? If so,
> this makes me curious about your POV - developer, architect, project
> manager, product manager, innocent bystander or . . . ?
Are you referring to JT or the the original poster? I'm the latter.
To answer your question, I was the "technical lead" (that's the title they
gave to me anyway) on a large system at a large company. The system was
great. Me and another guy architected then built it from scratch (designed
the database, wrote all the code, and lead a team of support developers to
complete the implementation). We delivered, hit our Y2K deadline with room
to spare, and life was good for a couple of years. Then new management came
in and they wanted [a system] like ours that had - say 14 features. We went
to them with "good news" and said we already had 11 of those features and
the remaining could be added within 9 months (a perfectly acceptable time
line to them). Strangely, a few of us who knew how easily the existing
system could be extended to meet all desires/needs got railroaded out of
town. After I left they ended up budgeting millions of dollars for a
complete new/replacement system. Fast forward 2.5 years to the present. They
just canned the whole new system and completely migrated back to the one I
had left them with years before. In fact they never completely migrated OFF
of my system. In other words they are part of the 35% that fail (in their
case both over budget and way over deadline). They even hired an outside
consulting firm to come in and advise on how to fix the replacement system.
The outside firm basically told them it could not be fixed. In essence -
they totally failed. Then last w
Ballmer presents his 35% failure rateand I do some research to see who else is saying that. Until learning that
this sort of huge failure happens all the time, I had chalked up my former
client's situation to the particular organization. But if it's happening all
them time, then come on - there's more going on than just bad planning or
poor project management. I think it's plain and simple *greed* at
practically all levels that may be the "Super Explanation" from which the
poor planning and managemnet and communication etc flow. Yes, all those
other things happen all the time. But come on. They are continually
*allowed* to happen. Why are they allowed to happen all the time? Greed -
IMO.
Please don't think this thread is all about any old grudge. I'm several
years removed from all that. I was just surprised to see that it happens in
many organizations OTHER than the one I was in. That's why I'm looking to my
peers here in these NGs to learn what you are all seeing. I think I have to
ask you because if I were to just listen to academia and big consulting
firms or software vendors peddling their Team solutions then I'd be lead to
believe that we just need to communicate better; test earlier; test more
systematically; have UML save the day; organize ourselves into 2-person
developer teams (i.e. Extreme methodologies). etc. But none of those address
greed and the associated desire (unconscious perhaps) for systems to go over
budget and beyond deadline or ultimately fail.
Thanks for your feedback.|||Jordan R. was the OP, but any of us who have been in IT for more than 10
years have a story to tell.
"Rick Lones" <WrlonesX@.YcharterZ.net> wrote in message
news:%Psef.73821$RG4.16336@.fe05.lga...
> Jordan R. wrote:
> The likelihood? No earthly idea how to evaluate that. It *can* happen
> that way - but might that not suggest that management is somehow providing
> an incentive when it does?
> Really I have to agree with Fred E. here - there are a *lot* of holes that
> large projects can fall into - and most of them were identified quite well
> by Brooks many years ago.
> JT, in your original post you sounded like you were just curious in an
> academic way about how and why IT projects fail. Now though you are
> sounding more like someone who has been badly burned recently. Is this
> correct? If so, this makes me curious about your POV - developer,
> architect, project manager, product manager, innocent bystander or . . . ?
> -rick-|||Jordan R. wrote:
> Re:
> << JT, in your original post you sounded like you were just curious in an
> academic
>
>
> Are you referring to JT or the the original poster? I'm the latter.
To you, Jordan - thanks for the clarification.
> To answer your question, I was the "technical lead" (that's the title they
> gave to me anyway) on a large system at a large company. The system was
> great. Me and another guy architected then built it from scratch (designed
> the database, wrote all the code, and lead a team of support developers to
> complete the implementation). We delivered, hit our Y2K deadline with room
> to spare, and life was good for a couple of years. Then new management cam
e
> in and they wanted [a system] like ours that had - say 14 features. We wen
t
> to them with "good news" and said we already had 11 of those features and
> the remaining could be added within 9 months (a perfectly acceptable time
> line to them). Strangely, a few of us who knew how easily the existing
> system could be extended to meet all desires/needs got railroaded out of
> town. After I left they ended up budgeting millions of dollars for a
> complete new/replacement system. Fast forward 2.5 years to the present. Th
ey
> just canned the whole new system and completely migrated back to the one I
> had left them with years before. In fact they never completely migrated OF
F
> of my system. In other words they are part of the 35% that fail (in their
> case both over budget and way over deadline). They even hired an outside
> consulting firm to come in and advise on how to fix the replacement system
.
> The outside firm basically told them it could not be fixed. In essence -
> they totally failed.
Wow - quite a story. Any chance you can still sell them those remaining 3
enhancements? Your credibility should be way up with them by now. :)
Then last w
Ballmer presents his 35% failure rate> and I do some research to see who else is saying that. Until learning that
> this sort of huge failure happens all the time, I had chalked up my former
> client's situation to the particular organization. But if it's happening a
ll
> them time, then come on - there's more going on than just bad planning or
> poor project management. I think it's plain and simple *greed* at
> practically all levels that may be the "Super Explanation" from which the
> poor planning and managemnet and communication etc flow. Yes, all those
> other things happen all the time. But come on. They are continually
> *allowed* to happen. Why are they allowed to happen all the time? Greed -
> IMO.
Truthfully, I think that the demand for large complex systems has way
outstripped the supply of people qualified to build them. Hence the rise of
RAD
environments and powerful paradigms and languages such as OO and C++ which t
o
some hold out the promise of some silver bullet. To take C++ as an example:
IMO
this is a sophisticated language, quite well worked out by a smart well-educ
ated
guy - and completely appropriate for use on large engineering projects by ot
her
smart well-educated people. But in the wrong hands it's just a great way to
make a huge mess quickly - and with the best of intentions. I don't mean to
claim that most programmers are too stupid to understand OO or C++, but many
who
use these tools seem insufficiently prepared and/or lacking the experience t
o
use them well. And if you are using them less than well then IMO you just m
ight
have been better off with COBOL . . .
> Please don't think this thread is all about any old grudge. I'm several
> years removed from all that. I was just surprised to see that it happens i
n
> many organizations OTHER than the one I was in.
Everybody always seems to overestimate other people's competence. It's stil
l
true that 90% of *everything* is crap - and this includes management teams.
Programming isn't easy and most people can't do it at all, let alone well.
That's why I'm looking to my
> peers here in these NGs to learn what you are all seeing. I think I have t
o
> ask you because if I were to just listen to academia and big consulting
> firms or software vendors peddling their Team solutions then I'd be lead t
o
> believe that we just need to communicate better; test earlier; test more
> systematically; have UML save the day; organize ourselves into 2-person
> developer teams (i.e. Extreme methodologies). etc. But none of those addre
ss
> greed and the associated desire (unconscious perhaps) for systems to go ov
er
> budget and beyond deadline or ultimately fail.
Hmm, I *think* I see what you are getting at here - the proposed remedies se
ldom
rise above being just more magic bullets. "Do A, do B, do C, then your prob
lems
will be over and your organization will have (somehow) become competent." I
t
seems a bit naive, but the overselling of methodologies is ubiquitous.
I am not so sure about fingering greed and spooky unconscious motivations as
the
root of all problems though. Among other things we are all in this hoping t
o
make a living. Now if what you are pointing out is, "beware, the whole syst
em
is badly broken", then I might even agree - but IT system development is har
dly
the most pressing example of that.
Regards,
-rick-|||Re:
<<Any chance you can still sell them those remaining 3 enhancements? Your
credibility should be way up with them by now. :) >>
No way man! I had all the credibility I needed back when they initiated this
debacle. It's not at all about credibility - never was. I had as much of
that as anyone can get. (actually had one of those "only heard about" 20
minute - to - 20 second process enhancements to my credit; the internal
customers loved me for that one).
It apparently was *really* about them spending 8 mil.
Here's how it went (I'm pretty sure, in retrospect)
Me: "hey - check this out - you can have everything you want - all for about
300 large in about 9-10 months"
Them: "ohMyGosh - I can't build my little internal corporate empire if word
about this gets out. I just proposed a multimillion dollar system that got
approved. There's no way I can go back on that. Plus I just hired my
Alcoholics Anonymous Buddy as my admin assistant. I can't put us both out of
work..."
Now, looking forward for them, they're back a "square 1" with this system.
No one was fired over this - so we can know there were no *real* penalties
for failure. So this leaves them to do - guess what - propose the next
system! It's going to get its own budget too... same people in charge...
Re:
<<I am not so sure about fingering greed and spooky unconscious motivations
as the root of all problems though. Among other things we are all in this
hoping to make a living.>>
LOL - agreed about the spooky motives thing. But there is more of a living
to be made in many situations when the project fails (when, of course, there
is no real penalty for failure). That's all I'm trying to find out here - if
others see the same thing in their organizations.
I appreciate your perspective Rick.
Monday, March 12, 2012
Issue with SSIS Package Configurations in SqlServer
Hello everyone,
I am working on a SSIS project and I am facing an issue for getting the configuration settings of the package, once it is deployed and executed from SQL Server agent.
The package uses two configuration types: (listed bellow in the order they are appeared in the configuration editor)
Config1 - Xml configuration file - for storing the database connection string.
Config2 - SQL Server - for storing some user defined variables. It uses the same database as specified in Config1.
Everything works fine and the package uses the database configuration values as defined in Config2, if I execute it from Visual Studio,
However, the package doesn’t get the configuration settings from the database when I try to execute it as a SQL Agent job.
There aren’t any errors and the package executes all tasks successfully, using the connection object Config1 (the same we use to get the config parameters from the database) and the default values of the user defined variables.
It works ok, if I change Config2 to be of type XML configuration file.
There could be two problems:
1. SQL server agent doesn’t read the configuration from the database and I am not quite sure how to set this. In Agent/ Job step properties screen/ Configurations tab I can only browse for a config file. I can also use the command window and /CONFIGFILE option to specify xml file, but how to use it in a case of a database configuration? Is there a /CONFIGDATABSE option or /CONFIGFILE works with database connection as well. I tried with /CONFIGFILE and database connection, but it doesn’t seem to work.
2. SQL server agent doesn’t get the configurations in the specified order. In my case,
it could try to read Config2 first, but at that moment it doesn’t have the database connection from Config1 and it fails. Again, I am not sure how to set the sequence.
Thanks in advance for your comments.
ITHave you specified a full path for Config1?|||Yes, I specified the full path for Config1. I used the configuration tab to select the file and in the command line window it shows the full path.
The package itself uses the connection from Config1 for the data flow tasks and they work without any issues.
|||Hi,
What kind of user defined variables are you fetching from the database?
Can you try storing them in package level variables by using a Script Task?
Regards,
B@.ns
|||I think you can discard option 2. The package configurations should be processed in the order in which they are stored.
It sounds like a permissions problem with the SQl Server Agent account.
Have you tried profiling (SQL Profiler) the package execution to see if it is generating any SQL errors trying to read the configuration table? If the package fails to read the configuration, it only raises a warning, not an error, so it is not always obvious when a configuration fails to load.
|||I couldn’t find any errors or warnings during the package execution.
Moreover the same connection is used for all data flow tasks inside the package and the SSIS logging (it uses SSIS log provider for SQL) and all of them work without any issues.
As a workaround I can add a SQL script to read those variables from the database, but this will duplicate the configuration functionality.
The idea was to use the existing SSIS database configuration feature instead of building a similar one from scratch.
|||Are you changig the path of the Conf1 in Agent, different than one you have when building the package?|||I.T.See if you this blog spot can help you identifying the issue:
http://rafael-salas.blogspot.com/2007/01/ssis-package-configurations-using-sql.html
It uses an environment variable instead of a file|||
Hi Rafael,
I checked your blog (actually this was one of the first materials I found when I started exploring the issue a week ago), but in our case we have some system restrictions for using environment variables.
In your example you mentioned also that you used it successfully with XML file.
I would like to ask you if you were to deploy it and execute it as a SQL agent job?
Thanks,
IT
|||Yes, I did, and as far as I remember it worked ok. The only problems I can remember are stupid things like the XML file was not accessible for the account running the SS Agent; not updating the connection string properly withing the XML file (hence trying to connect to the wrong instance), etc. But most of the times, the package logging will tell you if something is wrong with any of the configurations and even shows the order in which the configurations were applied.|||Rafael,
I would like to ask you if you remember how you set the sql configuration in the SQL Agent job. Did you do something special for this?
I couldn’t see any available options to set explicitly the configuration as SQL server (the UI allows only to browse and select config file).
The package logging is set to log all events and it doesn’t show any errors during the execution.
You mentioned also that the package logging can tell the order of the configuration, but I couldn’t see that kind of information. Is there a special custom event for this?
Thanks,
IT
|||I just ran some tests using XML and Table configurations (in that order) and works fine in BIDS and as an agent job.
I didn't have to do any special thing in the job step (CmdExec); just to a command like:
DTEXEC /FILE "{path}\Configurations demo 2.dtsx" /MAXCONCURRENT " -1 " /CHECKPOINTING OFF /REPORTING EWCDI
But what I could notice is that the messages about package configurations are not shown in te progress tab; I recently updated to SP2, and I wonder if that has been changed. I dind't even received any warning when I deliberated removed the xml config file...not even in the package logging|||
I. T. wrote:
I couldn’t find any errors or warnings during the package execution.
This is normal behaviour in my experience. I didn't get any warnings or errors either.
Issue with SSIS Package Configurations in SqlServer
Hello everyone,
I am working on a SSIS project and I am facing an issue for getting the configuration settings of the package, once it is deployed and executed from SQL Server agent.
The package uses two configuration types: (listed bellow in the order they are appeared in the configuration editor)
Config1 - Xml configuration file - for storing the database connection string.
Config2 - SQL Server - for storing some user defined variables. It uses the same database as specified in Config1.
Everything works fine and the package uses the database configuration values as defined in Config2, if I execute it from Visual Studio,
However, the package doesn’t get the configuration settings from the database when I try to execute it as a SQL Agent job.
There aren’t any errors and the package executes all tasks successfully, using the connection object Config1 (the same we use to get the config parameters from the database) and the default values of the user defined variables.
It works ok, if I change Config2 to be of type XML configuration file.
There could be two problems:
1. SQL server agent doesn’t read the configuration from the database and I am not quite sure how to set this. In Agent/ Job step properties screen/ Configurations tab I can only browse for a config file. I can also use the command window and /CONFIGFILE option to specify xml file, but how to use it in a case of a database configuration? Is there a /CONFIGDATABSE option or /CONFIGFILE works with database connection as well. I tried with /CONFIGFILE and database connection, but it doesn’t seem to work.
2. SQL server agent doesn’t get the configurations in the specified order. In my case,
it could try to read Config2 first, but at that moment it doesn’t have the database connection from Config1 and it fails. Again, I am not sure how to set the sequence.
Thanks in advance for your comments.
ITHave you specified a full path for Config1?|||Yes, I specified the full path for Config1. I used the configuration tab to select the file and in the command line window it shows the full path.
The package itself uses the connection from Config1 for the data flow tasks and they work without any issues.
|||Hi,
What kind of user defined variables are you fetching from the database?
Can you try storing them in package level variables by using a Script Task?
Regards,
B@.ns
|||I think you can discard option 2. The package configurations should be processed in the order in which they are stored.
It sounds like a permissions problem with the SQl Server Agent account.
Have you tried profiling (SQL Profiler) the package execution to see if it is generating any SQL errors trying to read the configuration table? If the package fails to read the configuration, it only raises a warning, not an error, so it is not always obvious when a configuration fails to load.
|||I couldn’t find any errors or warnings during the package execution.
Moreover the same connection is used for all data flow tasks inside the package and the SSIS logging (it uses SSIS log provider for SQL) and all of them work without any issues.
As a workaround I can add a SQL script to read those variables from the database, but this will duplicate the configuration functionality.
The idea was to use the existing SSIS database configuration feature instead of building a similar one from scratch.
|||Are you changig the path of the Conf1 in Agent, different than one you have when building the package?|||I.T.See if you this blog spot can help you identifying the issue:
http://rafael-salas.blogspot.com/2007/01/ssis-package-configurations-using-sql.html
It uses an environment variable instead of a file|||
Hi Rafael,
I checked your blog (actually this was one of the first materials I found when I started exploring the issue a week ago), but in our case we have some system restrictions for using environment variables.
In your example you mentioned also that you used it successfully with XML file.
I would like to ask you if you were to deploy it and execute it as a SQL agent job?
Thanks,
IT
|||Yes, I did, and as far as I remember it worked ok. The only problems I can remember are stupid things like the XML file was not accessible for the account running the SS Agent; not updating the connection string properly withing the XML file (hence trying to connect to the wrong instance), etc. But most of the times, the package logging will tell you if something is wrong with any of the configurations and even shows the order in which the configurations were applied.|||Rafael,
I would like to ask you if you remember how you set the sql configuration in the SQL Agent job. Did you do something special for this?
I couldn’t see any available options to set explicitly the configuration as SQL server (the UI allows only to browse and select config file).
The package logging is set to log all events and it doesn’t show any errors during the execution.
You mentioned also that the package logging can tell the order of the configuration, but I couldn’t see that kind of information. Is there a special custom event for this?
Thanks,
IT
|||I just ran some tests using XML and Table configurations (in that order) and works fine in BIDS and as an agent job.
I didn't have to do any special thing in the job step (CmdExec); just to a command like:
DTEXEC /FILE "{path}\Configurations demo 2.dtsx" /MAXCONCURRENT " -1 " /CHECKPOINTING OFF /REPORTING EWCDI
But what I could notice is that the messages about package configurations are not shown in te progress tab; I recently updated to SP2, and I wonder if that has been changed. I dind't even received any warning when I deliberated removed the xml config file...not even in the package logging|||
I couldn’t find any errors or warnings during the package execution.
This is normal behaviour in my experience. I didn't get any warnings or errors either.
Issue with SSIS Package Configurations in SqlServer
Hello everyone,
I am working on a SSIS project and I am facing an issue for getting the configuration settings of the package, once it is deployed and executed from SQL Server agent.
The package uses two configuration types: (listed bellow in the order they are appeared in the configuration editor)
Config1 - Xml configuration file - for storing the database connection string.
Config2 - SQL Server - for storing some user defined variables. It uses the same database as specified in Config1.
Everything works fine and the package uses the database configuration values as defined in Config2, if I execute it from Visual Studio,
However, the package doesn’t get the configuration settings from the database when I try to execute it as a SQL Agent job.
There aren’t any errors and the package executes all tasks successfully, using the connection object Config1 (the same we use to get the config parameters from the database) and the default values of the user defined variables.
It works ok, if I change Config2 to be of type XML configuration file.
There could be two problems:
1. SQL server agent doesn’t read the configuration from the database and I am not quite sure how to set this. In Agent/ Job step properties screen/ Configurations tab I can only browse for a config file. I can also use the command window and /CONFIGFILE option to specify xml file, but how to use it in a case of a database configuration? Is there a /CONFIGDATABSE option or /CONFIGFILE works with database connection as well. I tried with /CONFIGFILE and database connection, but it doesn’t seem to work.
2. SQL server agent doesn’t get the configurations in the specified order. In my case,
it could try to read Config2 first, but at that moment it doesn’t have the database connection from Config1 and it fails. Again, I am not sure how to set the sequence.
Thanks in advance for your comments.
ITHave you specified a full path for Config1?|||Yes, I specified the full path for Config1. I used the configuration tab to select the file and in the command line window it shows the full path.
The package itself uses the connection from Config1 for the data flow tasks and they work without any issues.
|||Hi,
What kind of user defined variables are you fetching from the database?
Can you try storing them in package level variables by using a Script Task?
Regards,
B@.ns
|||I think you can discard option 2. The package configurations should be processed in the order in which they are stored.
It sounds like a permissions problem with the SQl Server Agent account.
Have you tried profiling (SQL Profiler) the package execution to see if it is generating any SQL errors trying to read the configuration table? If the package fails to read the configuration, it only raises a warning, not an error, so it is not always obvious when a configuration fails to load.
|||I couldn’t find any errors or warnings during the package execution.
Moreover the same connection is used for all data flow tasks inside the package and the SSIS logging (it uses SSIS log provider for SQL) and all of them work without any issues.
As a workaround I can add a SQL script to read those variables from the database, but this will duplicate the configuration functionality.
The idea was to use the existing SSIS database configuration feature instead of building a similar one from scratch.
|||Are you changig the path of the Conf1 in Agent, different than one you have when building the package?|||I.T.See if you this blog spot can help you identifying the issue:
http://rafael-salas.blogspot.com/2007/01/ssis-package-configurations-using-sql.html
It uses an environment variable instead of a file|||
Hi Rafael,
I checked your blog (actually this was one of the first materials I found when I started exploring the issue a week ago), but in our case we have some system restrictions for using environment variables.
In your example you mentioned also that you used it successfully with XML file.
I would like to ask you if you were to deploy it and execute it as a SQL agent job?
Thanks,
IT
|||Yes, I did, and as far as I remember it worked ok. The only problems I can remember are stupid things like the XML file was not accessible for the account running the SS Agent; not updating the connection string properly withing the XML file (hence trying to connect to the wrong instance), etc. But most of the times, the package logging will tell you if something is wrong with any of the configurations and even shows the order in which the configurations were applied.|||Rafael,
I would like to ask you if you remember how you set the sql configuration in the SQL Agent job. Did you do something special for this?
I couldn’t see any available options to set explicitly the configuration as SQL server (the UI allows only to browse and select config file).
The package logging is set to log all events and it doesn’t show any errors during the execution.
You mentioned also that the package logging can tell the order of the configuration, but I couldn’t see that kind of information. Is there a special custom event for this?
Thanks,
IT
|||I just ran some tests using XML and Table configurations (in that order) and works fine in BIDS and as an agent job.
I didn't have to do any special thing in the job step (CmdExec); just to a command like:
DTEXEC /FILE "{path}\Configurations demo 2.dtsx" /MAXCONCURRENT " -1 " /CHECKPOINTING OFF /REPORTING EWCDI
But what I could notice is that the messages about package configurations are not shown in te progress tab; I recently updated to SP2, and I wonder if that has been changed. I dind't even received any warning when I deliberated removed the xml config file...not even in the package logging|||
I couldn’t find any errors or warnings during the package execution.
This is normal behaviour in my experience. I didn't get any warnings or errors either.
Issue with SSIS Package Configurations in SqlServer
Hello everyone,
I am working on a SSIS project and I am facing an issue for getting the configuration settings of the package, once it is deployed and executed from SQL Server agent.
The package uses two configuration types: (listed bellow in the order they are appeared in the configuration editor)
Config1 - Xml configuration file - for storing the database connection string.
Config2 - SQL Server - for storing some user defined variables. It uses the same database as specified in Config1.
Everything works fine and the package uses the database configuration values as defined in Config2, if I execute it from Visual Studio,
However, the package doesn’t get the configuration settings from the database when I try to execute it as a SQL Agent job.
There aren’t any errors and the package executes all tasks successfully, using the connection object Config1 (the same we use to get the config parameters from the database) and the default values of the user defined variables.
It works ok, if I change Config2 to be of type XML configuration file.
There could be two problems:
1. SQL server agent doesn’t read the configuration from the database and I am not quite sure how to set this. In Agent/ Job step properties screen/ Configurations tab I can only browse for a config file. I can also use the command window and /CONFIGFILE option to specify xml file, but how to use it in a case of a database configuration? Is there a /CONFIGDATABSE option or /CONFIGFILE works with database connection as well. I tried with /CONFIGFILE and database connection, but it doesn’t seem to work.
2. SQL server agent doesn’t get the configurations in the specified order. In my case,
it could try to read Config2 first, but at that moment it doesn’t have the database connection from Config1 and it fails. Again, I am not sure how to set the sequence.
Thanks in advance for your comments.
ITHave you specified a full path for Config1?|||Yes, I specified the full path for Config1. I used the configuration tab to select the file and in the command line window it shows the full path.
The package itself uses the connection from Config1 for the data flow tasks and they work without any issues.
|||Hi,
What kind of user defined variables are you fetching from the database?
Can you try storing them in package level variables by using a Script Task?
Regards,
B@.ns
|||I think you can discard option 2. The package configurations should be processed in the order in which they are stored.
It sounds like a permissions problem with the SQl Server Agent account.
Have you tried profiling (SQL Profiler) the package execution to see if it is generating any SQL errors trying to read the configuration table? If the package fails to read the configuration, it only raises a warning, not an error, so it is not always obvious when a configuration fails to load.
|||I couldn’t find any errors or warnings during the package execution.
Moreover the same connection is used for all data flow tasks inside the package and the SSIS logging (it uses SSIS log provider for SQL) and all of them work without any issues.
As a workaround I can add a SQL script to read those variables from the database, but this will duplicate the configuration functionality.
The idea was to use the existing SSIS database configuration feature instead of building a similar one from scratch.
|||Are you changig the path of the Conf1 in Agent, different than one you have when building the package?|||I.T.See if you this blog spot can help you identifying the issue:
http://rafael-salas.blogspot.com/2007/01/ssis-package-configurations-using-sql.html
It uses an environment variable instead of a file|||
Hi Rafael,
I checked your blog (actually this was one of the first materials I found when I started exploring the issue a week ago), but in our case we have some system restrictions for using environment variables.
In your example you mentioned also that you used it successfully with XML file.
I would like to ask you if you were to deploy it and execute it as a SQL agent job?
Thanks,
IT
|||Yes, I did, and as far as I remember it worked ok. The only problems I can remember are stupid things like the XML file was not accessible for the account running the SS Agent; not updating the connection string properly withing the XML file (hence trying to connect to the wrong instance), etc. But most of the times, the package logging will tell you if something is wrong with any of the configurations and even shows the order in which the configurations were applied.|||Rafael,
I would like to ask you if you remember how you set the sql configuration in the SQL Agent job. Did you do something special for this?
I couldn’t see any available options to set explicitly the configuration as SQL server (the UI allows only to browse and select config file).
The package logging is set to log all events and it doesn’t show any errors during the execution.
You mentioned also that the package logging can tell the order of the configuration, but I couldn’t see that kind of information. Is there a special custom event for this?
Thanks,
IT
|||I just ran some tests using XML and Table configurations (in that order) and works fine in BIDS and as an agent job.
I didn't have to do any special thing in the job step (CmdExec); just to a command like:
DTEXEC /FILE "{path}\Configurations demo 2.dtsx" /MAXCONCURRENT " -1 " /CHECKPOINTING OFF /REPORTING EWCDI
But what I could notice is that the messages about package configurations are not shown in te progress tab; I recently updated to SP2, and I wonder if that has been changed. I dind't even received any warning when I deliberated removed the xml config file...not even in the package logging|||
I couldn’t find any errors or warnings during the package execution.
This is normal behaviour in my experience. I didn't get any warnings or errors either.
Subscribe to:
Posts (Atom)