Karl has some good comments. I can offer one slight
tweak in that while going to each workstation and
setting an ODBC token map is commonly done. For SAS
programs it isn't always necessary, you can put it in
your SAS string on-the-fly. e.g. locate NOPROMPT in
the example archive posts:
Hope this is helpful.
Senior Programmer Analyst
Investment Management & Research
Global Leaders in Multi-Manager Investing
From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of
Sent: Friday, April 25, 2008 10:38 AM
Subject: Re: SAS/Access Opinions
Ken, we've used SAS Access to ODBC for, gosh, 15 years now, both to SQL
Server and to Oracle, and have had absolutely no problems, either for
local or remote databases accessed over the internet. (Parenthetically,
have, on rare occasions, tried to use the pass thru facility to send SQL
Server specific commands to the server, and ODBC seemed to have a
with it, but, it's rare, and right now, I can't even remember what the
Having said that, ODBC is pretty old and OLE DB is considered the more
modern way to go, at least for Windows shops. There is one practical
difference (as far as SAS is concerned) that weighs in favor of OLE DB:
for ODBC, you need to have an ODBC data source set up for each database
you want to access *on each workstation*. For OLE DB, the connection
string is contained right in your SAS statement, so you don't need to go
around to each workstation whenever you create a new database.
The only reason we haven't upgraded to OLE DB is because ODBC is part of
our bundle, and the OLE DB license would cost us a bundle.
On Fri, 25 Apr 2008 10:41:12 -0600, Ken Barz <Ken.Barz@CPCMED.ORG>
>It looks like we're finally going to leap into the 20th century (21st
>maybe some day) and get the ability to have our SAS connect to a
>real-live database. We know we're going to connect to a SQL Server
>database. However, we're making another purchase that may wind up
>sitting on Oracle. I've worked before with the ODBC SAS/Access product
>so I have a feel for that. Does anyone have an opinion on the value of
>that versus the OLEDB version versus the database specific varieties?
>We're a Windows shop and one of the SQL Server databases we'll actually
>have to hit across the internet if that makes a difference.