You also need to download the Oracle Instant Client. Download all three rpm files -- basiclite, devel and sqlplus -- not just the first. You do need all three. Finally, the ./configure [...] line in debian/rules took some fiddling. I read this post by Arun Mallikarjunan and, emboldened, I tried a few variations of my own. This is what worked:

./configure --prefix=/usr --with-oracle=/usr/lib/oracle/11.2/client
--with-instantclient --without-rpath --disable-new-check --without-kde
--with-oracle-includes=/usr/include/oracle/11.2/client
--with-oracle-libraries=/usr/lib/oracle/11.2/client/lib --enable-libsuffix=

The above is all on one long line. Incidentally, Arun commented here that in addition to the prerequisites Brad listed, you need a few others. Brad disagreed here. He is right that the extra packages on Arun's list not are required. But if you install them, you also get MySQL and ODBC support enabled, so I did. One time last year I had to odbc load some data from a MySQL database into Stata (I found help for that here) and I figured the need might come up again. Finally, I cleaned up after myself with help from here.

Some context first: one of my ongoing projects is a suite of Stata do-files for helping certain daily newspapers optimize their subscriber retention, using survival analysis. I have several clients. Some of their needs are common, so they can be met with one do-file, others are not so common, so they need custom code. I use global macros as bridges between custom and common code. You need this introduction to see what I'm doing in my example below.

One client is sending me a weekly snapshot of its subscriber database in the MS Access format, in a file called Submaster_YYYYMMDD.mdb. Suppose that that file resides in c:/data/my access file comes from here/. Then I must read it into Stata and save it as subsYYYYMMDD.dta in c:/data/my stata file goes here/. Now suppose that I spread this project across several do-files, so I use some internal names for these file paths in the form of global macros defined once:


global datafrom "c:/data/my access file comes from here/"
global datato "c:/data/my stata file goes here/"


Also suppose that I save the date of arrival part of the file name, YYYYMMDD, as a global macro:


global t "YYYYMMDD"


Finally, I don't want my lines to be too long, so I use local macros to compress things a bit whenever that looks practical. Now let's have a look at the actual example:


capture confirm file "${datato}subs${t}.dta"
if _rc!=0 {

   local mdbpath "${datafrom}"
   local mdbname "Submaster"
   local source "MS Access Database;DBQ=`mdbpath'`mdbname'_${t}.mdb"
   capture confirm file "`mdbpath'`mdbname'_${t}.mdb"

   if _rc==0 {
      #delimit ;
      local vars "
      ${${paper}index},
      prod_code,
      start_orig,
      last_start_date,
      last_stop_date,
      expire_date,
      rate_table,
      paper_code,
      rate,
      credit_card_usage";

      drop _all;
      odbc load,
      exec("SELECT `vars' FROM `table' WHERE (prod_code='1D' OR prod_code='3D')")
      dsn("`source'");
      save "${datato}subs${t}", replace;
      #delimit cr
   }
}


First, I check if the Stata file subsYYYYMMDD.dta exists in the path ${datato} with "capture confirm file". If it does not, then I check if the Access file Submaster_YYYYMMDD.mdb exists in the path ${datafrom}. If yes, then I read it and save subsYYYYMMDD.dta. The exec() part of odbc load is for running SQL syntax. Just to make sure that you appreciate the coolness of this: any SQL line that you could execute in Access, no matter how complicated, can be put between the exec() parentheses. Mine is simple -- I wrote the SQL commands in all caps for clarity -- but yours needn't be. You can also combine Stata locals with SQL syntax like I did.

I switch to the semicolon delimiter when it helps readability. It allows the line with SQL syntax to wrap around, and the listing of my `vars' local as one word per line. This, of course, is optional. The checks for the existence of either file are also optional. They keep my do-files from exiting with an error if I happen to run them on a day when either file does not exist -- either because the source file Submaster has not arrived yet, or because it hasn't been translated yet into Stata.

Just to get it out of the way: if you run Stata 10 and you receive data from somebody using one of the newer, XML-style Excel versions, you don't need odbc load for that. Use the command xmluse instead. You can tell by the file name extension. Whenever Excel went XML (as of Office 2007 perhaps? I've been using OOo for a while now, so I'm not sure) it started saving workbooks with the .xlsx extension. The notes below apply to getting data from old-school -- .xls -- workbooks into Stata.

So, back to odbc load. Its syntax is a bit arcane; for that reason, sometimes more code is preferred to less. You can split this command into components with local macros, for example. Well-chosen local macros make it much easier to re-use code or organize it into modules that can be maintained by different people working simultaneously.

Stata may still be the preserve of the lone researcher, or the grad student working for the typical PI, which is the same thing, and for them these niceties don't matter as much. But the private sector has highly structured ways and Stata can roll with that just as well as it does with the more freewheeling style of the academia. So here's how I propose that odbc load should be run for getting data out of an Excel workbook:


// your customers can edit this
local my_path     "D:/data/My Project/Source Files/"
local my_workbook "workbook.xls"
local my_file     "Sheet1"

// without worrying about any of this
local source "Excel Files;DBQ=`my_path'`myworkbook'"
clear
odbc load, dsn("`source'") table("`my_file'$")
tempfile my_file
compress
describe
save "`my_file'", replace

And that's all for MS Excel. Your temporary file "`my_file'" has all the data on worksheet Sheet1. If you ever need to pass this code on to other people, they will appreciate that they only need to edit the local macros with the path, workbook and worksheet that are right for them, and everything else works unchanged. You can use odbc load for getting data out of MS Access or a MySQL database. You can even embed SQL code. More on that here.