Aaron, Thanks, that makes a lot of sense. I do use linked servers and scripts for my daily import scripts in my SPs, but I can understand how it makes it so much easier to build these kinds of things in the point and click DTS interface; especially for things like the excel to oracle use case you mention. I had also forgotten about the VB code that the DTSs allow. that can be handy in some cases.
On Thu, Dec 18, 2008 at 9:48 AM, Aaron Rouse <[email protected]> wrote: > We typically used DTS to migrate data between database servers that could > not talk directly to one another and quite often one of those databases > would not be SQL Server. Part of the migration would be some form of data > manipulation but not always. Really simple stuff and was really easy to get > done in DTS and still faily easy with SISS when going between two SQL > Servers. When I first got here they used DTS a lot, I believe with a ton of > VB code and who knows what else, that was all in a data warehouse that I had > nothing to do but shared an office with one of their programmers so heard a > lot about it. I have used DTS for quick and dirty imports of data in the > past, it is unbelievably simple to do and nice when you can just get > something like an Excel file into Oracle with very little invested time or > effort and with a pre-existing(on the machine) tool. > > Now days the only thing I have to use SISS for is to migrate data from our > staging server to the production. Which could be done with an SP if the > users were allowed the proper permissions. I doubt any DTS packages I have > written in the past are still online here, most everything has been migrated > to Oracle or retired. > > On Thu, Dec 18, 2008 at 9:38 AM, Ken Auenson, II <[email protected]>wrote: > >> So, I have not yet been exposed to SISS in SQL Server 2005, but I am >> maintaining a few DBs that are SQL Server 2000 that had a lot of DTS >> packages. >> At one point, I re-wrote most of them to be straight stored procedures. >> I find this to be a lot easier to maintain and a lot easier to actual work >> with. >> What tasks and added power to DTS and/or SISS have that you cannot do in >> straight stored procedures? >> In other words, what features/benifits am I missing out on? >> >> Thanks, >> Ken >> >> On Thu, Dec 18, 2008 at 9:08 AM, Aaron Rouse <[email protected]>wrote: >> >>> I am talking about the cost of the software itself not the people who >>> manage it. We pay the same amount of money for either and actually the same >>> people administer both flavors is why. >>> >>> Yes SISS is much more powerful but for those of us who do not need the >>> added power it actually made certain tasks more cumbersome to do if using >>> SISS instead of DTS. >>> >>> On Thu, Dec 18, 2008 at 7:51 AM, Robert L. Stewart < >>> [email protected]> wrote: >>> >>>> >>>> Cost of ownership and cost of both development DBAs (which I am) and >>>> production DBAs is a lot lower with SQL Server than Oracle. Oracle >>>> DBAs tend to specialize in certain things about the role. Because >>>> of the size and complexity of it, it is pretty much impossible to >>>> do everything in it well as a DBA. All of the Oracle "development" >>>> DBAs that I have dealt with have been very competent with writing SQL >>>> statements, again I think it is the specialization thing. >>>> >>>> The change done to DTS to make it SSIS was generally to put it into >>>> competition with Informatica. For those of you that have not seen it, >>>> it is a lot like the SSIS interface. SSIS is also much more powerful >>>> than DTS ever was. >>>> >>>> Also, if you write the T-SQL correctly, it can be extremely versatile >>>> for the GUI/Business layer programmer to use. For example, the update >>>> can be written so that not all the fields need to be passed in, but >>>> the ones that are passed in will be updated. >>>> >>>> For example: >>>> >>>> UPDATE dbo.tbl_HSE_Causes >>>> SET [HSEC_HAZOP_ID] = CASE WHEN @HSEC_HAZOP_ID IS NULL THEN >>>> [HSEC_HAZOP_ID] >>>> ELSE @HSEC_HAZOP_ID >>>> END, >>>> [HSEC_No] = CASE WHEN @HSEC_No IS NULL THEN [HSEC_No] >>>> ELSE @HSEC_No >>>> END, >>>> [HSEC_Project_ID] = CASE WHEN @HSEC_Project_ID IS NULL THEN >>>> [HSEC_Project_ID] >>>> ELSE @HSEC_Project_ID >>>> END, >>>> [HSEC_Description] = CASE WHEN @HSEC_Description IS NULL THEN >>>> [HSEC_Description] >>>> ELSE @HSEC_Description >>>> END >>>> WHERE HSEC_ID = @HSEC_ID >>>> >>>> All of the parameters are optional except the HSEC_ID in the example. >>>> >>>> I would be interested in reading that article. It seems that they should >>>> be >>>> optimizing the dynamic stuff more because of LINQ. So maybe they have in >>>> 2008. >>>> But, I do not know many people that are using it yet. SPs definitely >>>> faster in 2000 and 2005 that dynamic. >>>> >>>> >>>> At 02:32 AM 12/17/2008, you wrote: >>>> >Date: Tues, Dec 16 2008 7:24 pm >>>> >From: "Aaron Rouse" >>>> > >>>> > >>>> >Yeah just a shame that the price tag on Oracle and CF Enterprise(if you >>>> want >>>> >out of the box datadirect drivers) is rather steep for some. We are >>>> being >>>> >pushed slowly towards SQL Server because MS gave a bunch of licenses >>>> for it >>>> >and makes the cost of Oracle all the sudden seem like a huge waste of >>>> money >>>> >to the higher ups. Have to love MS's approach, make the first uses >>>> free >>>> >then once they are sunk in charge them a lot. >>>> >>>> Robert Stewart >>>> ProjecTools.com >>>> 713-371-9840 X1305 >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Aaron Rouse >>>> http://www.happyhacker.com/ >>>> >>>> >>>> >> >> >> >> >> -- >> Aaron Rouse >> http://www.happyhacker.com/ >> >> >> >> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the "Houston ColdFusion Users' Group" discussion list. To unsubscribe, send email to [email protected] For more options, visit http://groups.google.com/group/houcfug?hl=en -~----------~----~----~----~------~----~------~--~---
