As I can see that shimmer of light at the end of the tunnel I have to start thinking "what do I do with a binary SAS reader/writer?"
I originally started down this path with the goal of avoiding having to read/write SAS using XML Now that I am nearing the finish, I am trying to determine what comes after this (other than a quiet, non-working evening).
Where I am leaning right now is an Excel add-in or something in that space. I think Excel/SAS is one of the biggest areas of opportunity and an area that frankly does not get enough attention, IMO. SQL Server add-ins are another possible option so SAS can be supported in SSIS. It is early in this mulling period though so I would appreciate any thoughts people have on what they would like to see.
This blog is designed to show various ways to use Data Virtualization, technologies, and SAS with Microsoft technologies with an eye toward outside of the box thinking.
Thursday, August 27, 2009
Subscribe to:
Post Comments (Atom)
SAS throwing RPC error
If you are doing code in C# and get this error when creating a LanguageService: The RPC server is unavailable. (Exception from HRESULT:...
-
I am finally ready with my SAS dataset reader/writer for .NET. It is written in 100% managed code using .NET 3.5. The dlls can be found here...
-
I was just tasked to read in LDAP records so we could cross-reference userids with login identifiers and general ledger information. Using...
-
Well, around 14 months ago, I started on a journey to understand the SAS dataset so I could read and write one independently. Originally, I ...
3 comments:
The problem with Excel and SAS is that SAS (SAS datasets) are the approved method of submitting data to regulatory agencies (FDA). The SAS statistical procedures have been validated. What this means is the way SAS calculates and stores numeric values has been approved and tested and meets the criteria of government (US and international) regulatory agencies. Excel has not been validated to the degree SAS has been. For example (and I am making this up) numbers in Excel with a long decimal numbers may not be rounded correctly after the sixth or seventh decimal place. Also Excel has statistical functions that I assure you are not validated to the extent SAS procedures are validated. Moving a calculation from an Excel spreadsheet to a SAS dataset may provide a false sense confidence that the calculation was done correctly. Likewise a number moved from SAS to Excel may be rounded or truncated in a manner that loses accuracy. It would be best if there was a way (.net function or validated Excel function) to read a SAS datasets that preserves the exact value of the varaible in the dataset.
Not every application, though, requires this level of scrutiny. In my entire SAS career (20+ years), I have never had to deal with regulatory requirements.
The concern is valid vis-a-vis pharma and some other areas but there is a wide range of apps that do not need a high-degree of precision. That said, a number on a SAS dataset is a double and is easily preserved.
@LB - that's not strictly true - the FDA can't mandate the use of SAS datasets because the dataset file format is proprietary. They accept data as SAS transport files, because the transposrt file format is open (though also quite bad).
Post a Comment