Oh the humanity ...
-
I'm sure you will have had this before so apologies if you have.
We are evaluating SQL2005 as an upgrade from 2000. The old DTS and in particular the wizard was a real boon to our 'lesser-abled' members of staff. They could use it, usually without fail, to easily import or export data to and from a variety of sources (it was even easy to find). In 2005, we finally found the wizard but it doesn't work! It just sits in a corner complaining about everything under the sun. The old wizard was great and did everything for you but this new one, well, doesn't.
After reading SQL Server 2005 Administrator's Pocket Consultant (Microsoft Press) on the subject, I quote: "Creating an Integration Services package is one of the most complex tasks you will perform as a database administrator" (p.319 if you have the misfortune of owning this book). Eh? This _used_ to be a simple task and now it's described as the most complex task of all? Blimey, is this supposed to be progress?
Has anyone actually managed to use SSID with no problems whatsoever? i.e. it worked straight out of the box without having to refer to the internet / books / God? I ask this, because DTS did. And SSID doesn't. So what gives? Or, am I missing the point somewhere and it's actually ridiculously easy?
I'll be honest and say that the way things are going with our evaluation, the Devil himself will have to be wearing ice-skates before we upgrade. (please don't get me started on performance - aaarrrggghhh!
)Thanks.
-
I, for one, am glad at the greater apparent complexity - the main problem with Microsoft products in a large corporate nevironment was that any Tom, Dick or Harry with Analyst in their job title would create hundreds of hellish DTS packages with no rhyme, reason or documentation. Now perhaps they'll need to know what they're doing
-
Thanks for replying. I take it then, the answer is no, it didn't work straight out of the box? Reading the sub-text of your reply would suggest that we should tell our tech support department that in SQL2005 they now can't import or export data - particularly when it's one of their most commonly used tools ... Hmm, I'm not sure they're going to be particularly happy about that ...
-
I assume you mean SSIS not SSID
I agree with you (original poster), it's very complex. And it's no longer a quick and dirty tool to import data for a DBA. It raises the bar for using the product.
The wizard is better, which might help you, but it should give you pause. As far as performance, it's seemed to work well for me. Are you speaking the server or the Management Studio tool?
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com -
Thanks for replying Steve. I am of course including myself in the list of 'lesser-abled' members of staff and yes, I did mean SSIS (damn acronyms)
Well, the wizard was a start but as I mentioned originally, it just doesn't want to know if we keep user-interaction to a minimum i.e. clicking next all the time. Which, to be honest, is more-or-less what we used to do - and why shouldn't we? It allowed the user to concentrate on getting the data in without having to worry about the 'mechanics'. Bear in mind that these are tech. support bods (not DBA's) who are using this to sort out problems with data from customers. Also, for minor tweaks, the designer was easy enough to work out how to add in extra 'bits' without having to resort to undergoing Microsoft certification!!! Oh yes, and it would save the package without complaining too!
Maybe we have a different philosophy (we are from Yorkshire after all) and we have to change how we operate for SQL2005? But, saying that, if there is a tool that makes our life easier, is it wrong to assume that we can still use the same tool (or a version thereof) to carry on making our life easier?
As for performance, I am talking about the Management studio tool and also the Business Intelligence Development Studio (say that after you've had a few!). It runs like a dog although it has got better since I put in an extra half gig of memory (not much though it has to be said) - Enterprise Mangler is now looking positively speedy in comparison.
-
Juan,
There is most certainly a learning curve with SSIS. The extra complexity has been added for a reason, mostly for issues of security. I kind of agree with Joseph, messing about with data in databases is something that should be done by skilled people in dedicated roles (i.e. a DBA). Having said that the "old way" certainly had its plus points.
In regard to SSMS performance. I remember I used to moan about the very same thing but now, I never notice it being a problem. Funny that!
Oh, and I too am from Yorkshire so you can't use that excuse
-Jamie
Jamie Thomson
http://sqlblog.com/blogs/jamie_thomson -
Hi Jamie
If we were just one corporate entity, I would agree with you. Unfortunately, we are a company that sells a product that is supported by our tech. support department. Are you suggesting that every single member of tech. support should be a qualified DBA? (they all 'mess' with data after all - it's their jobs) The cynic in me would suggest that this is what MS wants to happen. The realist in me just laughs his head off because it won't.
I also think that my initial assumption that no-one has been able to use SSIS straight out of the box was correct which means I remain unconvinced that this is progress.
And don't get me started on the new security 'features'. What do you mean I can't save my SSIS package? I've entered my credentials three times. Aaaaarrgggh. I know, I'll look at the error message, that's bound to help me. Hang on, what's this? 'Exception in handle c:0x0105082'. Oh. I'll get me coat.
As for speed, I reckon if you went back to Query Analyzer, it would be like strapping yourself into a rocket sled after riding around on a penny farthing all week.
Mark (now even more seriously considering a career in pig-farming.)
-
There's more to the job than getting it working, quick and dirty. How many systems have you come across with hundreds of packages that mean nothing to anyone? How do you migrate that app? How do you maintain it?
Every single member of your support department should indeed know what they are doing, I wouldn't even grant access to non-DBAs for the work you are describing.
-
Hi Joseph. I'm not talking about the app not working because it does. It's not an SQL app, it's a compiled app that sits on top of SQL and the source is highly maintained here in the dev section. DTS is not used by the software - it doesn't need to. Also, I'm not talking about our corporate server as that is a different thing altogether - that is on a secured network with no access at all from anyone except a select few - maybe that is what you think I am talking about?
We get data from a multitude of sources - not just from the thousands of our customers but from suppliers of data to our software and because of that, most people need to be able to get data into whatever server they happen to be using, quick and dirty as you put it. For the purposes I am describing, I would say the servers tech support are using are test servers and as such, they can do whatever they like to it. If they solve the customers problem, that's what we're interested in. We don't have an issue at all with 'hundreds of packages that mean nothing'.
I honestly can't believe you would deny tech support (or whoever) access to a server on, say, their own machine which is used for the sole purpose of solving problems with data! You'd basically be cutting off their right arm and then tying the left one behind their back. Tech support do indeed know what they are doing - if they didn't, we wouldn't have a business. Query Analyzer, DTS, Enterprise Mangler (to a certain extent) are the lifebloods of their jobs. How can we justify enrolling 100+ people on a certified DBA course just so we can import data to the same extent we are doing now?
Sorry, still not convinced ...
-
Now that I'm starting to get the hang of SSIS it doesn't seem so bad or extreemly slower to develop than DTS (which I loved and used a lot). There's a learning curve to be sure, but it looks like it's worth it.
Skål - jh
-
Thanks for the words of encouragement omhoge and thanks to everyone else for your responses but I can tell from what you're saying that the answer is to basically suck it up. Not particularly what I wanted to hear, but hey, beggars can't be choosers I guess.
Therefore, the answers to my two original questions of 'Is there an easier way than SSIS?' and 'Has anyone managed to use it straight out of the box' are 'No' and 'No' respectively.
I'll set a little challenge then: I have just created a package in Enterprise Manager using DTS that imports a flatfile into one of my tables. The flatfile is a snapshot of a table that is an exact replica of the one I am importing into (so there are no 'weird' transformations). I then added an SQL task in the designer that simply truncates my existing table so I don't get pkey errors (it's test data after all). It took me 1 minute and 17 seconds from start to finish (yes I timed it - sad I know) - and it is now re-usable from now and for ever more (because it saved - something which I can't make SSIS do at present). Who wants to beat that using SSID?
(If you can, please please tell me how ...). Thanks
-
Of course I mean SSIS! doh!
-
I'm intrigued, what kind of problems do these guys resolve?
Note I didn't say certified DBAs earlier, experience qualifies a DBA in my book.
-
Juan,
Send me the file and a CREATE TABLE script and I'll have a go. I love a challenge.
jamie.thomson@nospam.conchango.com
-Jamie
Jamie Thomson
http://sqlblog.com/blogs/jamie_thomson -
Joseph: Ok, for instance: I have just finished a project for one of our customers who is based in the states (we're UK) During the course of development, a regular exchange of data had to take place. As I describe in the challenge above, I would snapshop a table, drag it over here and DTS it into my own table - the whole process taking minutes.
Then there's our testing department who do similar things when new devs or program fixes are scheduled. Then there's our customer services department who build reports to customer specs (not SQL reports - our own, built into our software) and who use DTS for the same reason (it's easier to get the results you want when you have the source data of the person who wants it). Then there's tech support who can do the same thing if a customer reports a problem. Then there's the RnD section who are constantly manipulating supplier data from a variety of sources so we can make it available to our customers (one of our selling points). Then there's engineering, marketing, accounts etc etc. Yes, we could (and do) use backups etc but if we want just one or two tables, which is usually all we need, DTS is great for grabbing and loading and testing. I'm sure there are other ways of doing all this, but it works for us.
As a business, we have been operating for nearly 25 years now and hold the market share in our niche. We've managed to do that by constantly evolving our products to fit our customers' needs and DTS plays a part in that by allowing us to respond quickly and efficiently. As far as I can see and with the comments I have received, SSIS is going to hinder us - not help.
Viewing 15 posts - 1 through 15 (of 32 total)
You must be logged in to reply to this topic. Login to reply