Check out this code:
string newParms = "outdata=WORK.TEST";
Common.SasLanguageService.Async = true;
StoredProcessService sp = Common.SasLanguageService.StoredProcessService;
sp.Repository = storedProcLibrary;
sp.Execute(storedProcedureName, newParms);
Standard stuff when working with the stored process server through VB or C# (or any other means of hitting these dlls).
Funny thing is the SAS log shows that the macro assignment of newParms never takes place. Hence, &outdata is undefined:
SYMBOLGEN: Macro variable OUTDATA resolves to
Commenting out the Async makes this all work:
SYMBOLGEN: Macro variable OUTDATA resolves to WORK.ALAN_20110418_070053
Now, even wiring up the event handlers for SubmitComplete do not fix the issue. Seems like a bug but I'll let the guys in R&D figure it out. If you have to waste a lot of time on it, however, keep in mind the nuances here until SAS R&D dives in.
Well, back out to the far left field where I hang out. Time to work on the business problem.
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.
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 ...
6 comments:
It seems like you're trying it the hard way using SAS IOM via COM. Did you know that there might be a managed wrapper in your Integration Technologies folder if you have SAS9.2?
Look for a StoredProcessService.dll and the documentation file StoredProcessService.chm in the %programfiles%\SAS\Shared Files\Integration Technologies folder.
BTW: i really like your blog!
xoxoxo
Now THAT's what I have been looking for for a long, long time. Playing with the help file now...
More info to come later.
Well, the issue with the .NET component is that it relies on a Stored Process Server already being set up (from what I could tell). Hence, you can't just pass the file locations and the parms and execute. I would love it if this wasn't the case but that is what I gleaned from my short exploration.
I will work on it more once I clear a deadline that I have to meet.
I did not have much time to investigate the .NET component either. I discovered it by accident :P (like all nice SAS stuff it is hidden very good) and only used it in a simple demo, but as far as i understand it, the stored process has to be already registered in the metadata server.
If you just want to execute some SAS code from a file location (which is not registered in the metadata) you should use a workspace server, right?
Well good luck on meeting your deadline. It would be very nice if you could share your experience with the managed assembly. I guess there are only very few people like us who use SAS/ Integration Technologies in combination with Microsoft technology.
It works ok for me if I set Common.SasLanguageService.Async = false under C#.
Async = false is the default which is why including it works or commenting out the line works.
Post a Comment