SAS and .Net

Well, I’m not at TechEd this year, but home and busy working.  The current project at the moment is trying to abstract out SAS and make it look and act like a regular data provider.  For those of you that don’t have to interop with SAS, consider yourself lucky.  It’s about the most closed, prominent, business software that I can think of.  If it wasn’t for the FDA basically requiring Pharmas to use the thing, I can’t see how they would ever be able to stay in business.  Not that it is a bad piece of software, it just does not play well with others.  As long as you stay in the SAS world, it is fine, but to try to integrate it into another platform and you are in for trouble.  So, to remove most of the development related issues, I’m busy trying to make it look like a regular data provider to the .Net developer.  This means creating Connection, Command, Parameter, and DataAdpater classes that inherit from the base System.Data interfaces, and then implementing all the interop code.  These classes are then abstracted again by my Data Access Layer, so that the business object developers don’t need to learn specific data providers.  After I get this done, I’ll eventually create a web service wrapper for the DAL so that even non .Net developers can work with SAS, and not have to learn how to handle the interop.

Enough talk, back to the grind and get this code ready for my development team.

DonXML

[Listening to: Who Invited You - The Donnas]

6 Comments

  • hey don. sorry for a post in the wrong location. i just wanted to see how your vlane purchase of msdn went.


    -Mathew

  • I did something similar pre-.NET with another interoperability-challenged business system: I wrote an ODBC driver.





    Luckily it seems that many of these software packages are learning that it doesn't pay to be antisocial.

  • Don, will you make your Web Service available to others? I can think of a number of individuals and companies that could take advantage of such a service.

  • All the work I am doing with SAS and .Net is for a client, and they consider this a competetive advantage, so I don't think they will allow me to release the code. That does not mean that I can not help others, just that I can't release this particular code. If someone wants to start an open source project for SAS and .Net, I would love to lend my advice, but coding it may present some issues.





    DonXML

  • I feel your pain with trying to get SAS to play nicely with .NET. I am writing a GUI in VB .NET to control some modeling code in SAS. So far, I have made great progress, despite the lack of help from SAS tech support.



    Currently, I am having difficulty reading XML into a SAS dataset. It works the first time through, but fails the second time through. On the second pass, the XML file is created from an ADO dataset, but SAS says the XML file does not exist (and it does). Any ideas? Any help you can offer would be greatly appreciated. By the way - I'm fairly new to .NET, but well-versed in SAS. cheridy@hotmail.com



    Cheridy

  • I feem your SAS pain too. I move data alot between different databases, xml, and then often into SAS for some statisticians to play with.



    I've usually converted XML or records into flat files which SAS can read with a regular input job. Pain in the butt but it always works. .NET streamreader and streamwriter objects are pretty straightforward to use, and it’s also easy to loop through XML files and write out a comma delimited file. Comma delimited input is also pretty easy to read with a sas input statement.

Comments have been disabled for this content.