SAS Libname Statment
QUERY_BAND= LIBNAME Option
Generate
SET QUERY_BAND="BAND;" FOR SESSION;
I need to generate this :
SET QUERY_BAND='BAND’; FOR SESSION VOLATILE;
Whitch statment should I to use?
Statement like QUERY_BAND_VOLATILE does not exist.
Your query_band expression is incorrect. Use smth like below, and run it within the Proc SQL as Richard suggested.
SET QUERY_BAND = 'BAND=1;' FOR SESSION VOLATILE;
proc sql;
connect to teradata as tdd (server=&SERVER. user=&HCUSER. password=&HCPASS.);
execute(SET QUERY_BAND = 'BAND=1;' FOR SESSION VOLATILE; ) by tdd;
disconnect from tdd;
quit;
Related
I would like to ask you how to move a table from SAS to TeradataSQL Assistant.
What I have done in SAS is to define a libname, then create the table that I want to move in Teradata.
libname NAME "/path"
proc sql;
create table WORK.EXAMPLE as(
select *
from DATASET
);
quit;
However, I do not know if I need to connect SAS to Teradata in this way:
libname NAME teradata USER=tduser PASSWORD=tdpasswd SERVER=TDServ ;
proc sql;
connect to teradata (
tdpid=“” user=“” password=“”);
create table WORK.EXAMPLE as
select * from connection to teradata
(select * from DATASET
); quit;
My questions are:
in the second libname, where should I consider the path?
which one of the code above should I consider and why?
how can I 'call' this table in Teradata? I tried with SELECT * FROM WORK.EXAMPLE, but it does not exist.
Thank you for your help.
You can either connect to Terdata using the LIBNAME statement
libname mylib TERADATA .... ;
or the CONNECT statement in PROC SQL.
proc sql;
connect to teradata .... ;
In fact you can even use the libref created in a previously created LIBNAME statement in your connect statement.
libname mylib TERADATA .... ;
proc sql;
connect using mylib ;
Generally I find it easiest to use PROC APPEND to copy data into Teradata.
libname td TERADATA ... ;
libname mysas 'path to where my SAS datasets live';
proc append base=td.target_table data=mysas.source_table force;
run;
If the target table doesn't exist then SAS will create it. (In which case take care as you might not want the default variable types or the primary index that will get created that way.).
I have a store procedure in Teradata and I trying execute with "PROC SQL" in SAS but I don't have results.
libname S_SQUEMA teradata server="100.00.00.100" user=##### pwd=#### schema=S_SQUEMA fastload=YES;
PROC SQL;
CALL S_SQUEMA.SP_TEST(year);
QUIT;
Thanks.
To run something in Teradata you need to connect to Teradata using a CONNECT statement and then push the Teradata code to the database using the EXECUTE statement. So your code will look something like this:
proc sql ;
connect to teradata ..... ;
execute ( call S_SQUEMA.SP_TEST(year) ) by teradata;
quit;
If you already ran your LIBNAME statement to define your S_SQUEMA libref then you can just use that to make the connection.
proc sql ;
connect using S_SQUEMA ;
execute ( call S_SQUEMA.SP_TEST(year) ) by S_SQUEMA;
quit;
I work with SAS on a relationnal database that I can access with a libname odbc statement as below :
libname myDBMS odbc datasrc="myDBMS";
Say the database contains a table named 'myTable' with a numeric variable 'var_ex' which values can be 0,1 or . (missing). Now say I want to exclude all rows for which var_ex=1.
If I use the following :
DATA test1;
SET myDBMS.myTable; /* I call directly the table from the DBMS */
where var_ex NE 1;
run;
I don't get rows for which 'var_ex' is missing. Here is a screenshot of the log, with my actual data :
Whereas if I do the exact same thing after importing the table in the Work :
DATA myTable; /* I put myTable in the Work library */
SET myDBMS.myTable;
run;
DATA test2;
SET myTable; /* I call the table from the work */
where var_ex NE 1;
run;
I select rows for which 'var_ex' is 0 or missing, as intended. Here is a screenshot of the log, with my actual data :
The same happens if I use PROC SQL instead of a DATA step, or another NE-like.
I did some research and more or less understood here that unintended stuff like that can happen if you work directly on a DBMS table.
Does that mean is it simply not recommended to work with a DBMS table, and one has to import table locally as below before doing anything ?
DATA myTable; /* I put myTable in the Work library */
SET myDBMS.myTable;
run;
Or is there a proper way to manipulate such tables ?
The best way to test how SAS is translating the data step code into database code is through the sastrace system option. Before running code, try this:
options sastrace=',,,db' sastraceloc=saslog;
Then run your code tests. When you check the log, you will see precisely how SAS is translating the code (if it can at all). If it can't, you'll see,
ACCESS ENGINE: SQL statement was not passed to the DBMS, SAS will do the processing.
followed by a select * from table.
In general, if SAS cannot translate data step code into dbms-specific code, it will pull everything to locally manipulate the data. By viewing this output, you can determine precisely how to get the data step to translate into what you need.
If all else fails, you can use explicit SQL pass-through. The code in parentheses operates the same way as if you're running SQL directly from some other client.
proc sql;
connect to odbc(datasrc='source' user='username' pass='password');
create table want as
select * from connection to odbc
(<code specific to your dbms language>);
disconnect from odbc;
quit;
In SAS 9.2, how do I get the return codes / error messages from explicit pass-through sql to teradata? Printed in log or output or something.
I already got a small query to work fine, but having some trouble with a more complex one. Debugging would be much easier with the error messages.
Tried the sqlxmsg and sqlxrc that are used when querying db2, but of course those don't work... haven't found any documentation on this. (I'm quite new to Teradata)
Use the SASTRACE option to bring back debugging messages from Teradata.
http://support.sas.com/documentation/cdl/en/acreldb/63647/HTML/default/viewer.htm#a000433982.htm
This document supports and shows an example of it in use on explicit pass-through SQL:
https://support.sas.com/resources/papers/TroubleshootingSASandTeradataQueryPerformanceProblems.pdf
N.B. If you are using this option on large sets of data, be careful to choose the options wisely or you will create huge logs
This was the code, and now after shutting and restarting SAS it works fine!
Seems I had some process hanging somewhere...
rsubmit sashost;
proc sql;
connect to teradata (user=&terauser password=&terapass server=&teraserv mode=teradata);
create table test as
select * from connection to teradata
(select x
from y.z
where c);
%put &sqlxmsg;
%put &sqlxrc;
disconnect from teradata;
quit;
proc download data=test out=locallib.test; run;
endrsubmit;
How can I call an Oracle stored proc from SAS to pass values and return values. I have SAS/ACCESS and running SAS 9.3
Thanks
Dan
This should work:
proc sql;
connect to oracle (user="oracleUserName" password="pass" path="serverPath" CONNECTION=GLOBAL CONNECTION_GROUP = SASAML);
execute( execute MyPackage.MyProcedure(¶m1, ¶m2) ) by oracle;
/* param1 and param2 are macro variables here */
disconnect from oracle;
quit;
This should work fine in SAS 9.2 and above using ODBC passthrough.
Here's a similar discussion with relevant links:
http://communities.sas.com/message/114296#114296
I'll try and come back sometime to surmise the linked article in this answer...
Pass-through stored procedure execution does not support output parameters. But if you need only one output parameter, a workaround is to use a function and "SELECT FROM dual" query. Here is in example (it uses one input parameter that is passed in from a macro variable).
%let a = 'ddd';
proc sql;
connect to oracle as ora2 (user=xxx password=xxx path="xxx");
select * from connection to ora2 (
SELECT test_fun(p_a => &a.) FROM dual
);
disconnect from ora2;
run;