For those of us who work with SAS LanguageService on a regular basis, it is frustrating. The entire SAS COM interface is very poorly documented and is light on functionality. It gets better over time but it would be much nicer to have a .NET interface so we don't have 50 COM nulls in a single method call.
Ok, that all said, I just came off of a marathon (10+ hours) bug fix that damn near drove me mad.
I was submitting a simple query via the Language Service:
proc sql;
create outdata.test as
select *
from DICTIONARY.COLUMNS
where …some criteria…
;
quit;
Ok, no problem. I could submt the query within the SAS Editor and it would work fine. However, DEPENDING ON WHERE I WAS IN MY .NET CODE, it would return 0 rows. Huh!?!? It wasn't the dataset, it wasn't the syntax for the call, it was where the call occured at during processing. Holy smokes Batman! That's a bear of a bug to catch.
You do the normal stuff and isolate, isolate, isolate. Well, it took a long time to isolate that it was where it was being called. Damn, damn, damn...one of the toughest bugs I have hit in years.
My answer for how to solve it:
Common.SAS.LanguageService.Reset();
(I am using a static class called Common).
Will this answer stand the test of time? Not sure. I have asked my buddy at SAS whether I am on the right track.
Back to the first point: better documentation would be welcome. Even better, an ADO.NET data provider WITHIN Base SAS. Don't make me buy IOM to use SQL processing.
Ah well, back out to the far corners of the ballpark I go...
1 comment:
Hey Alan,
For a long time, I had some problems with my Notebook saving 0 rows when the saving SAS datasets, and also the Code Editor not returning any listing output after submitting a code with an error (syntax or otherwise). Then a few weeks ago, I posted to SAS-L that the bugs have been fixed in the latest release. You know what? It was the LanguageService.Reset() function that solved it!
Audi :-)
Post a Comment