If you encounter the following error when using SAS's StoredProcessService events:
event invocation for COM objects requires event to be attributed with DispIdAttribute
Roll your project back from .NET 4.0 to .NET 3.5. This may only be applicable to the web services code.
Example code:
class Program
{
static void Main(string[] args)
{
Workspace ws = new Workspace();
SAS.LanguageService ls = ws.LanguageService;
ls.StepError += new CILanguageEvents_StepErrorEventHandler(ls_StepError); <---- ERROR OCCURS HERE
ls.Submit("data test; abort; run;");
}
static void ls_StepError()
{
Console.WriteLine("Bingo!");
Console.ReadLine();
}
}
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.
Tuesday, May 17, 2011
Friday, May 13, 2011
Flush with excitement...errr, logs
Well, it is Friday night, I am back from the doctor with antibiotics due to a possible spider bite (love those little guys), and I decide to track down some performance issues with the SAS StoredProcessService (or Microsoft's Cassini). Somewhere, someone is responsible. Set up my little test bed to see it all work:
All is well and good. Life is happy, kids are playing, sunshine is everywhere.
Wait! We need to see if the code ran. let's check the log:
AHHHH!!!! It never comes back. Where is my string!?!?
Turns out that if the FlushLog int amount EXCEEDS the total number of chars in the log, you go to a happy place called infinity. Less than the total chars and all is well.
I decided to test this a few times and was able to get a picture of my CPU utilization:
This does not happen when using the LanguageService directly, only when using the StoredProcessService. Time to wrap up this blog, pull back from the black hole of infinite loops, and go issue a bug report with SAS R&D.
If any SAS R&D folks in this area read this blog, let me know if I missed something. Right now, it seems like I have been bitten twice today by bugs.
SAS.Workspace ws = new Workspace();
LanguageService ls = ws.LanguageService;
StoredProcessService sp = ls.StoredProcessService;
sp.Repository = @"file:" + @"x:\temp";
sp.Execute("test.sas", string.Empty);
All is well and good. Life is happy, kids are playing, sunshine is everywhere.
Wait! We need to see if the code ran. let's check the log:
string log = ls.FlushLog(1000);
AHHHH!!!! It never comes back. Where is my string!?!?
Turns out that if the FlushLog int amount EXCEEDS the total number of chars in the log, you go to a happy place called infinity. Less than the total chars and all is well.
I decided to test this a few times and was able to get a picture of my CPU utilization:
This does not happen when using the LanguageService directly, only when using the StoredProcessService. Time to wrap up this blog, pull back from the black hole of infinite loops, and go issue a bug report with SAS R&D.
If any SAS R&D folks in this area read this blog, let me know if I missed something. Right now, it seems like I have been bitten twice today by bugs.
Subscribe to:
Posts (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 was just tasked to read in LDAP records so we could cross-reference userids with login identifiers and general ledger information. Using...
-
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...
-
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 ...