May 3, 2013 at 8:35 am
Martyn Hughes (10/19/2010)
Steve, I've been a great fan of SSC for many years, I've used a number of redgate tools and Litespeed to compress some rather large DBs especially when using a SAN. I think Susan made a good contribution to the forum.My comment is not meant to be 'snarky', I'm always troubled when I have to fight within an organization to get useful tools. Pervasive does cost several thousand but the amount of time saved using appropriate tools rather than paying FTEs to 'reinvent the wheel' is certainly a better use of company resources.
Pervasive has data connectors for just about anything, even really old 132 column report type stuff! (Only useful if you're dealing with old mainframe stuff)
I've used it to convert Progress to Oracle DW, Progress to SQL and vice-versa, Foxpro to SQL. On a smaller scale I used it to convert Quickbooks to SQL.
SSIS is certainly better than the old DTS but far behind 3rd party tools.
Does not Pervasive use RIFL scripting as the language ?
______________________________________________________________________________________________________________________________________________________________________________________
HTH !
Kin
MCTS : 2005, 2008
Active SQL Server Community Contributor 🙂
May 7, 2013 at 2:10 pm
opc.three (5/3/2013)
Also worth noting, once you move file parsing into the database you gave up the option for doing data cleansing, validation, multi-system data enrichment, lots of things, in the SSIS space. I realize that sometimes we go with what we know, but SSIS was built to do this kind of work, and dynamically too. I think a lot of folks consider using tools other than T-SQL when the task seems to stretch the limits of what T-SQL should be doing, but when it gets to a point where they just need to get something done they revert to T-SQL because that is what is comfortable to them. Crutches like xp_cmdshell (as one poster mentioned, not your article) make it easier to do that as well and point to that type of thought process. I applaud your use of SSIS to at least avoid accessing the cmd prompt and file system from within T-SQL, something I never condone.
Indeed. With a bit of code the EZApi on CodePlex (See here[/url]) can also be used to leverage what SSIS can do natively through dynamically generated packages. Which, even if used as an accelerator, can provide benefits. Still, the right tool at the right time.
August 15, 2013 at 12:31 am
Last place I worked used DataJunction for the print service bureau side of the business (e.g., bank check printing, etc). While what DJ does is cool, it does store the "design" in a binary file format. It would be nice if it was XML or other similar text-based file. Why's that? Well, one of the weaknesses we noted is that it doesn't really do templates, so it's up to the people using it to have any standardization for creating mapping files. When you have multiple people working on different import packages for files, then it seems no one does it in a standard, repeatable (and, because of the binary DJ files, discoverable) fashion. One customer's address data might go in fields1-5 (literally), and another might be fields10-15...
I had a crazy project there where it would have been nice to be able to scan over the DJ packages to figure out where it mapped data into the generic table structure in the database for each customer, but had to talk to DJ devs to dig out the data mapping for each customer.
As far as what DJ does, it's...better...than SSIS for this kind of work.
August 15, 2013 at 12:34 am
xp_cmdshell has some serious security implications. In that case, it's easier to not deal with that particular set of landmines and just implement that functionality through SSIS.
Viewing 4 posts - 31 through 33 (of 33 total)
You must be logged in to reply to this topic. Login to reply