I have a vb.net 2010 project that would remotely run a prepared SSIS package that exports a SAS 9.3 dataset into a SQL Server 2012 database. As far as I can tell, the process tested fine.
However, I was told not to use it (because SSIS packages are unreliable?), so are there alternatives to doing this?
I have looked up SAS ODBC to see if I can do this from the SAS end, but I am not sure of the DSN argument, the example I looked up is like this:
LIBNAME SQL ODBC DSN='sqlsrv_nt' schema=MSSQLTips;
Besides not being sure that the DSN is applicable for me, I am not administrator on my workstation so I can't play with ODBC settings much - I'm not certain that's the way to go.
You can either use a driver or DSN (customized shortcut data source connection object with all configurations/settings set). Once connected, append your data from local to remote source.
* WITH DSN;
libname mssqldata odbc datasrc="DSN Name" user="username" password="password";
* WITH DRIVER;
libname mssqldata odbc complete="driver={SQL Server}; Server=servername; user=username; pwd=password; database=databasename;";
** APPEND TO DATABASE TABLE;
proc datasets;
append base = mssqldata.DBTable
data = Work.SASdataset
force;
quit;
** UN-ASSIGN ODBC LIBRARY;
libname mssqldata clear;
Be very careful with assigning library to database as it is a live connection and not copies. Hence, modifying/adding/deleting will reflect immediately to server.
You don't need to be administrator. Set up a DSN connection under user profile. Then assign your libname and you can upload or update data in SQL server as permissions allow.
Your libname statement looks correct.
Related
I am creating a SAS macro function that my co-workers may use to connect via ODBC connections to various databases using SAS Proc SQL, to run pass-through SQL code. I would like the connection to be read-only, even though the users have write-access to the databases. I can do this in a LIBNAME statement, with ACCESS=READONLY:
LIBNAME myLib ODBC NOPROMPT="DATABASE=myDB;Server=myServer;DRIVER={SQL Server};Trusted_Connection=Yes;" ACCESS=READONLY;
I can create a read-write connection like so:
PROC SQL ;
CONNECT TO ODBC AS myCon(NOPROMPT="DATABASE=myDB;Server=myServer;DRIVER={SQL Server};Trusted_Connection=Yes;") ;
EXECUTE( INSERT INTO myTable(myColumn) VALUES(1) ) BY myCon ; ** insert a row where myColumn=1;
QUIT;
But inserting ACCESS=READONLY as an option in Connect To ODBC (), like CONNECT TO ODBC AS myCon(ACCESS=READONLY NOPROMPT="DATABASE=myDB;Server=myServer;DRIVER={SQL Server};Trusted_Connection=Yes;") ;, results in ERROR: Invalid option name ACCESS.
I know that there is nothing I can put within the connection string to make the connection read-only. Is there some way to make this Connect to ODBC ... into a read-only connection?
First, you can do it using the libname!
proc sql;
connect using mylib;
... sql stuff ...
quit;
Second, this is going to be in the ODBC init string (so inside the "quotes") and will depend on what driver you're using. The modern SQL server drivers have ApplicationIntent=ReadOnly; see for example this doc page for the v15 driver. I don't know if the older {SQL Server} driver supports that or not.
Is there a configuration file in Netezza like tnsnames.ora in Oracle which contains database names and their connect string names?
If so, what is the default location of the file?
I'm using Informatica PowerCenter to load to target Netezza table. I want to know the Database details of the connect string Informatica uses to connect with Netezza DB. In Oracle, I could have got the informatica from tns file.
Netezza doesn't have an equivalent to Oracle TNSNames.
ODBC Connection String Example:
Driver={NetezzaSQL};servername=myServerAddress;port=myPortNumber;
database=myDataBase;username=myUsername;password=myPassword;
ODBC ConnectionStrings.com
ODBC Configuration IBM
JDBC Configuration IBM
You can check the dsn entry (connect string name in Informatica connection) in the odbc.ini file in the LD_LIBRARY_PATH which is defined at the time of Netezza ODBC driver installation
In PowerCenter, a developer can check the connection details only if a dedicated connector is used. For ODBC, the only information available in Workflow Manager is the name of ODBC. The details can be checked in ODBC definition on the server.
A small addition to #Marciejg:
We have only a few odbc connections compared to powercenter connections. Each odbc points to the ‘system’ database and in the powercenter connection pointing to a specific database on that server, we run a ‘set current_catalog PROD_EDW’ in the pre sql. That way things are mostly visible and manageable in powercenter, and the odbc only points to the server.
And slightly off topic: the pre sql has additional ‘set CLIENT_*_NAME’ statements that enters the powercenter workflow/session etc dynamically based on powercenter build in variables (they are named $PMWorkflowname and similar)
That way we can trace back to the powercenter code immediately from a planfile, the pg.log or most interestingly, the HISTDB
Follow these links if you want to play with it:
- https://www.ibm.com/support/knowledgecenter/SSULQD_7.2.1/com.ibm.nz.dbu.doc/r_dbuser_set.html
and
http://dwhlaureate.blogspot.dk/2012/09/built-in-variables-in-informatica.html
I'd like to connect SAS to a Microsoft SQL Server database but I didn't succeed.
I already have a database connection using a NT authentication.
For instance, when I want to connect R (the statistical sofware) to the db, I do that
ch_db <- odbcConnect("sql_nt")
But when I do that in SAS, it doesn't work :
LIBNAME sql ODBC DSN=’sql_nt’;
I have this error message :
ERROR: Libname SQL is not assigned. ERROR: Error in the LIBNAME
statement. ERROR 22-7: Invalid option name SQL_NT.
I probably do a stupid mistake, but I don't see it.
In SAS to make a ODBC CONNECTION TO SQL SERVER;
First make a User DSN using Windows ODBC Data Source Administrator. I use the SQL Server Native Client and the defaults.
THEN IN SAS EXECUTE THE FOLLOWING STATEMENT
libname mySasLib odbc datasrc='myUserDSN';
ALTERNATIVELY, from the SAS Explorer window GUI, choose New to invoke the New Library Dialog.
Note the DSN sources on your machine will be listed in the Data Source dropdown.
User ID, Password, and Options fields are optional and are left blank for Windows Integrated Security.
;
SUBSEQUENTLY--to get the power of SQL pass-through--here is the syntax for creating a virtual view in Work; this is an incredible performance boost for my situation.
proc sql;
connect to ODBC as mycon (datasrc='myUserDSN');
create view one as
select colA, colB from connection to mycon
(select colA, colB from tableInDataSrc order by colA);
disconnect from mycon;
quit;
Then something like:
proc univariate data=one;
by colA;
histogram colB;
run;
Take a look at this page:
http://support.sas.com/documentation/cdl/en/acreldb/63647/HTML/default/viewer.htm#a001355231.htm
Specifically, I think you should try it this way:
libname mydblib odbc user=testuser password=testpass datasrc=mydatasource;
Typically you should provide user name and password when connecting to a SQL server. I assume you've verified that the ODBC connection was set up correctly (such as testing it with R).
Edit from comments:
If you're using NT authentication, then follow the instructions here: (from http://support.sas.com/techsup/technote/ts802.pdf )
libname odbclib odbc noprompt="dsn=sql_NT;Trusted_Connection=yes"
schema=DBO;
I suspect the old style of just dsn="stuff" doesn't work on newer versions - though I only use OLEDB so I'm not 100% sure.
I have tried to connect using both proc sql statements and the libname format. The latter seems more user friendly, here is one example:
LIBNAME testLib ODBC DSN='sqlserver' user=userID pw=xxxxxxxx schema=dbo;
title 'Testing Libname Option';
proc contents data= testLib.mytable;
proc print data=testLib.mytable(obs=10);
UserID and PWD need to come from your ODBC connection setup.
I am a SAS newbie and wasted quite a lot of time trying to create a 'user DSN' .
Thankfully, I checked with admin team in my company.
One of the SAS admin replied
"DSNs are configured on SAS server side "
She requested for 'MSSQL database and SAS server name' and created DSN for me.
Once connection was established i used below query
(P.S : I used windows authentication)
LIBNAME sql odbc = 'xxxxxx' ;
LIBNAME myfolder 'xxxxxxxxxxxxxxxx' ;
proc sql;
create table sql.target_table as select * from myfolder.mydata ;
quit;
I have database connection to database DB1. The only thing I could do - execute any t-sql statements including using stored procedures. I want to export the specific table (or even the specific rows of specific table) to my local database. As you can read abve, DBs are on diffrent servers meaning no direct connection is possible. Therefore question: Is it possible to write query that returns the other query to execute on local server and get data? Also note, that table contains BLOBs. Thanks.
If you have SQL Server Management Studio, you can use the data import function on your local database to get the data. It works as long as you have Read/Select access on the tables you are trying to copy.
If you have Visual Studio you can use the database tools in there to move data between two servers as long as you can connect to both from your workstation.
Needs Ultimate or Premium though:
http://msdn.microsoft.com/en-us/library/dd193261.aspx
RedGate has some usefull tools too:
http://www.red-gate.com/products/sql-development/sql-compare/features
Maybe you should ask at https://dba.stackexchange.com/ instead.
If you can login to the remote db (where you can only issue t-sql), you may create linked server on your local server to the remote and use it later directly in queries, like:
select * from [LinkedServerName].[DatabaseName].[SchemaName].[TableName]
I am able to create and execute a DTS package that copies tables from a remote Oracle database to a local SQL server, but want to setup the connection to the Oracle database as a linked server.
The DTS package currently uses the Microsoft OLE DB Provider for Oracle with the following properties:
Data Source: SERVER=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=10.1.3.42)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=acc)));uid=*UserName*;pwd=*UserPassword*;
Password: UserPassword
User ID: UserName
Allow saving password: true
How do I go about setting a linked server to an Oracle database using the data source defined above?
I was able to setup a linked server to a remote Oracle database, which ended up being a multi-step process:
Install Oracle ODBC drivers on SQL Server.
Create System DSN to Oracle database on SQL Server.
Create linked server on SQL server using System DSN.
Step 1: Install Oracle ODBC drivers on server
a. Download the necessary Oracle Instant Client packages: Basic, ODBC, and SQL*Plus (optional)
b. Unzip the packages to a local directory on the SQL server, typically C:\Oracle. This should result in a [directory] like C:\Oracle\instantclient_10_2, which will be the value of [directory] referenced in the rest of this answer.
c. Create a text file named tnsnames.ora within the instant client [directory] that contains the following:
OracleTnsName =
(
DESCRIPTION=
(
ADDRESS = (PROTOCOL=TCP)(HOST=10.1.3.42)(PORT=1521)
)
(
CONNECT_DATA = (SERVICE_NAME=acc)
)
)
Note: Actual HOST, PORT, and SERVICE_NAME will vary based on Oracle server you are establishing a connection to. This information can often be found using the Oracle network client tools under the listeners.
The OracleTnsName can be any name you want to assign to the Oracle data source, and will be used when setting up the system DSN. You can also use the syntax above to define multiple TNS names in the same tnsnames.ora file if desired.
d. Add the [directory] to the system PATH environment variable.
e. Create a new system environment variable named TNS_Admin that has a value of [directory]
f. Execute the [directory]\odbc_install.exe utility to install the Oracle ODBC drivers.
g. It is recommended that you reboot the SQL server, but may not be necessary. Also, you may want to grant security permissions to this directory for the SQL server and SQL agent user identities.
Step 2: Create a System DNS that uses the Oracle ODBC driver
a. Open the ODBC Data Source Administrator tool. [ Administrative Tools --> Data Sources (ODBC) ]
b. Select the System DSN tab and then select the Add button.
c. In the drivers list, select Oracle in instantclient {version}. (e.g. 'Oracle in instantclient 10_2') and then select Finish button.
d. Specify the following:
Data Source Name: {System DSN Name}
Description: {leave blank/empty}
TNS Service Name: should have the OracleTnsName you defined in the tnsnames.ora file listed, select it as the value.
User ID: {Oracle user name}
e. Select Test Connection button. You should be prompted to provide the {Oracle user password}. If all goes well the test will succeed.
Step 3: Create linked server in SQL to the Oracle database
Open a query window in SQL server and execute the following:
EXEC sp_addlinkedserver
#server = '{Linked Server Name}'
,#srvproduct = '{System DSN Name}'
,#provider = 'MSDASQL'
,#datasrc = '{System DSN Name}'
EXEC sp_addlinkedsrvlogin
#rmtsrvname = '{Linked Server Name}'
,#useself = 'False'
,#locallogin = NULL
,#rmtuser = '{Oracle User Name}'
,#rmtpassword = '{Oracle User Password}'
Note: The {Linked Server Name} can be anything you want to use when referencing the Oracle server, but the {System DNS Name} must match the name of the system DSN you created previously.
The {Oracle User Name} should be the same as the User ID used by the system DSN, and the {Oracle User Password} should be the same as you used to successfully test the ODBC connection. See KB 280106 for information on troubleshooting Oracle linked server issues.
Querying the Oracle linked server
You may use OPENQUERY to execute pass-through queries on the Oracle linked server, but be aware that for very large recordsets you may receive a ORA-01652 error message if you specify a ORDER BY clause in the pass-through query. Moving the ORDER BY clause from the pass-through query to the outer select statement solved this issue for me.
I had the same problem. I was on the phone with Microsoft for hours, and they did not have a solution. None of those "connection timeout" settings helped me.
To resolve it, I created a DTS job that runs a proc which only updates the time on one row, in one column, every two minutes. Then I setup a replication between SQL Server and Oracle, scheduled to replicate that single cell change, from SQL to Oracle, every 3 minutes. It keeps the connection alive!