I am thinking of using SAS and would like to know:
Is it possible to use ODBC to access a Teradata database in SAS?
I know that accessing MS Access using ODBC in SAS is possible, and accessing Teradata with Excel VBA using ODBC is possible, but I can not find anything for SAS with Teradata and ODBC.
connecting to Teradata by connect statement can be done by connect statement as shown below.
proc sql ;
connect to teradata (server=server user=user pw=pw );
create table work.emp as
(select *
from connection to teradata
(select a.*,
row_number()over(partition by deptno order by hiredate) as rn from
prod_targetdb.customer_table a
));
disconnect from teradata;
quit;
looks like connect to ODBC will also work but looks like it has more limitations,
like fastload capability and others, please look into the page 24 in the link given below
https://www.cs.purdue.edu/homes/ake/courses/cs590w/SASACCESS.pdf
Related
I am trying to get the tables using the following proc sql statement:
proc sql;
Select tablename from dbc.tables;
run;
I have already defined the teradata and SQL server locations required. The error I get is "File dbc.tables does not exist"
If I run the query in Teradata SQL assistant, it works. Its just that I am unable to do the same using SAS.
Try using dictionary.tables
proc sql;
select memname
from dictionary.tables
where libname = 'YOUR LIBNAME HERE'
;
quit;
proc datasets lib=<your library reference>;
run;
If you don't know your library reference, but you assume the library is assigned, try
proc sql;
select * from sasHelp.vlibnames;
quit;
If that does not help and you are working in Enterprise Guide, connected to a metaserver, click on Servers, your server, Libraries and make sure the button to see non-assigned libraries is set.
I am trying to display from the Oracle table the latest day from each particular month and I am facing a issue with the right function. I am trying like below, but it doesn't work.
proc sql;
connect to Oracle( );
create table work.database as
select * from connection to Oracle
(select * from oracle_table_name
where column_name= intnx('month',column_name, -1,'E');
disconnect from Oracle;
quit;
Your issue here (beyond some typos) is that you are using intnx, a SAS function, in pass-through SQL.
Pass-through SQL means you are submitting Oracle SQL code directly to Oracle and saying "please run this". You need to use the proper Oracle date functions in the where clause.
I have connected to the DB2 database using libname statement and created a table using DATA Step as follows:
libname db2lib db2 user=user pw=pwd database=dbtest schema=schema1;
data db2lib.test_table;
var1 = "1234";
run;
Table got created successfully but nobody else able to run the SELECT query on it.
I know how to grant permissions to the table using PROC SQL execute but is there any way to GRANT privileges as I am connecting to DB2 using LIBNAME.
I am unaware of any DB2 CREATE TABLE options that grant permissions.
However, if there are any, the data set option DBCREATE_TABLE_OPTS= could be specified in your SAS code:
DBCREATE_TABLE_OPTS= Data Set Option
Specifies DBMS-specific syntax to add to the end of the CREATE TABLE statement.
Details
You can use this option to add DBMS-specific clauses at the end of the SQL CREATE TABLE statement. The SAS/ACCESS engine passes the SQL CREATE TABLE statement and its clauses to the DBMS. The DBMS then executes the statement and creates the DBMS table. This option applies only when you are creating a DBMS table by specifying a libref associated with DBMS data.
As you know, the GRANT statement can be issued through The SQL Procedure EXECUTE statement.
Did you know CONNECT can use the existing LIBNAME ?
Proc SQL;
connect using DB2LIB;
execute (
GRANT …
) by DB2LIB;
I have a SAS dataset and I need to create a volatile table in Teradata using the SAS dataset. But, I do not have a sandbox to store the table on Teradata server. Is there a way that I can create a Teradata volatile table from a SAS dataset without SQL Sandbox.
It is pretty simple to create a volatile table in Teradata, just use the dbmstemp=yes option on your libname statement.
libname TDWORK teradata connection=global dbmstemp=yes .... ;
data tdwork.test1 ;
set sashelp.class ;
run;
Make sure to use the connection=global option on all of your LIBNAME and CONNECT statements so that all of the connections to Teradata use the same session so you can see your volatile table. Keep at least one of the libref's open so that the connection persists.
Then you could also use passthru SQL to create a volatile table.
proc sql ;
connect to teradata (connection=global .... );
execute (
create volatile table test2 as (
select * from test1
) with data on commit preserve rows
) by teradata;
quit;
Or to reference the volatile tables in pass thru SQL code.
So if you wanted to pull out of Teradata all the records from MYDB.MYTABLE where NAME was in the list of names you uploaded into the volatile table TEST1 you made with the first data step above you could use code like this:
proc sql ;
connect to teradata (connection=global .... );
create table mytest as select * from connection to teradata
( select * from mydb.mytable
where name in (select name from test1)
);
quit;
I am trying to access the SAS table which I made outside of Teradata Passthrough in working space for query run. Now it gives me an error. My question is how to access the table not in teradata inside the passthrough
proc sql;
connect to teradata (user="&user_id.#LDAP" password="&TERADATA_PASS" server='ABC'
connection=global database="GTY");
select * from connection to teradata(
select * from mm)
;
quit;
mm is not in teradata but made in working directory.
You probably can't access that in passthrough directly. You either need to run your query using libname access to the Teradata, or you need to put the information you need into a macro variable or text file that could be included in the passthrough query. In passthrough you can only access what you could access in an interactive Teradata session - so unless you have SAS defined as an ODBC or such provider for Teradata, it's a no go.
Typically what I do in this case is first try to execute the entire process through libname access, and if that fails (either because of execution time or because of a need for passthrough-only elements like stored procedures) then I use libname access to load the table to a table inside the RDBMS (Teradata here). Then it's available in your passthrough session for use (as a native Teradata table).