It's the old argument, really, of flexibility vs robustness, I guess. We use a vendor's external website, which we log into. They actually have a webpage on their site where you can type SQL into the webpage, hit the button, and the results are returned in an HTML table, or flat file, or excel spreadsheet. So the flexibility is that we can manipulate internal data using SAS, and then utilise that data to use within the SQL that we then send using the external application into the webtool. As a really simple example: PROC SQL;
SELECT DISTINCT "'"||trim(CITY)||"'"
INTO :city
FROM some_local_table (Obs=1);
QUIT;
%put &city.;
x %sysfunc(quote(
\\my share\my subfolder\myapplication.exe /loginandget
"parameter 1"
parameter2
&Param3var.
"select col1, col2 from vendors_remote_table where city=&city."
)); Yes it's a horrible hack, but needs must.... The vendor also does send us overnight batch files which are uploaded into a SAS Server, but lately, this process fails as often as it works. But as you say, if we're always going to be getting the same data back from the vendor's site, no reason why we can't schedule the application to run outside of SAS, and save the output somewhere, and then schedule a SAS job to pick up that data and do things with it.
... View more
