MS Access stores its database in .mdb files
Excel stores its workbook, which contain worksheets in .xls files.
Microsoft uses .doc
SAS generates/uses .sas7bdat files; but, that is also configurable.
Base SAS is not an RDMS, like Oracle, DB2, Sybase, Informix, etc.
You can easily copy and move a .sas7dbat file around, from one directory/folder to another and from one server to another, of the same kind, and SAS can happily open it and use it without concern.
It is my understanding that you cannot take .sas7bdat file from a mainframe, ftp it to a Sun box and open it. The binary representations are totally different.
It is my understanding that you could have the same problem between Sun, AIX, HPUX and Windows.
My question is generally, why would you want to in the first place?
If data is in Oracle, why would you want to move that data to a text file and move it to a different server so that you could import it into another system? There are legitimate circumstances, but generally, it is a bad idea. It the data is in a database, it is there so that a variety of tools can access it directly from the database. Same goes for SAS, once data is in a SAS dataset, use that SAS to do stuff with it. Or use SAS/CONNECT or SAS/SHARE or other SAS tools for processing the data on a different box.
RDMS's like Oracle and DB2 are meant to hold all data of all kinds and divy it out to whomever wants/needs to for some purpose. So set up your SAS to access the database to pull the data you want to analyze, and maybe even do some intial manipulation with it there on the database server first.
SAS is so good at reading so many different types of files, that it generally doesn't matter what you choose for your "standard format" for transferring data files around: tab delimited, comma delimited, any delimiters, fixed field lengths, variable records, etc. etc. etc. Use what is most convenient/standard practice for the application/system exporting the data. Just be careful of XML because it can blow up the file size hugely with all the extra text.
Generally, generate text files, compress them, move them, uncompress them, import them. Although, I had a C program do some intial data summary work on a mainframe, save it as a binary file, and then read those binary files in with SAS for actual analysis work.
I used C because of the nature/format of the incoming data files, it was easier to use unions to read in the data, and then structs to output the summary results. This is one situation where SAS isn't as efficient as C unions for data reads. SAS doesn't deal as well with input data that breaks normal form 1. It can do it, but it is more painful, and less efficient.
Message was edited by: Chuck