Stata The Stata listserver
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

RE: st: STATA Vs. SAS


From   "Ed Bassin, Ph.D." <edbassin@profsoft-health.com>
To   <statalist@hsphsun2.harvard.edu>
Subject   RE: st: STATA Vs. SAS
Date   Wed, 27 Nov 2002 18:36:37 -0500

Database connectivity, or the lack of it, is one of the biggest barriers
that I face bringing Stata into corporate environments.  Frankly, I think
the issue is as much one of perception as reality, but perception often is
reality.

Data transfer programs, specifically DBMS/Copy and Stat-Transfer, allow
users to query databases using ODBC connections.  I have integrated
DBMS/Copy scripts into several Stata .do and .ado programs.  I use DBMS/Copy
to transfer millions of records from large medical claims databases
(millions of records).  The performance is very good, better than infile.
However, the fact that you need another piece of software is a major turnoff
in most companies.

I really hope that Stata 8 will include ODBC connectivity at the least.
(I've suggested it several times.)

-----Original Message-----
From: owner-statalist@hsphsun2.harvard.edu
[mailto:owner-statalist@hsphsun2.harvard.edu]On Behalf Of Sayer, Bryan
Sent: Wednesday, November 27, 2002 5:35 PM
To: 'She, Dewei '; ''statalist@hsphsun2.harvard.edu' '
Subject: RE: st: STATA Vs. SAS


The primary advantage Dewei will find in SAS is the ability to read the db2
database directly in native format on the server, without having to use a
transfer utility or having to out the data from the database.

This is a HUGE advantage if the data is updated on a regular basis and/or
standard reports are run on a regular basis.  For this reason, I recommend
SAS for this specific situation.

In general, SAS will directly read many more formats of data than Stata
will.  If one encounters these types of data often, then this feature has
overwhelming importance.

Bryan Sayer
Statistician, SSS Inc.

-----Original Message-----
From: She, Dewei
To: 'statalist@hsphsun2.harvard.edu'
Sent: 11/27/02 1:17 PM
Subject: RE: st: STATA Vs. SAS

Thank you very much, guys.

We are going to use the software (SAS or STATA) against a db2 database
whose
serve resides on a linux box. The database is pretty big. Our
statistical
analysis is going be simple. Most of the time, we only do the freqency
distribution and logistic regression (both conditional and
unconditional).
Hope this will help you guys to help me out.

Dewei

-----Original Message-----
From: Nick Cox [mailto:n.j.cox@durham.ac.uk]
Sent: Wednesday, November 27, 2002 1:01 PM
To: statalist@hsphsun2.harvard.edu
Subject: RE: st: STATA Vs. SAS


Laurel A Copeland, among many other comments, wrote

> I find SAS much better for data management.  There are many ways to
> approach each coding task; code can be optimized for
> readability/teachability, or for brevity, or for
> conservation of space or CPU time.

and Richard Herrell similarly wrote

> I continue to find Stata frustrating for data
> management and prefer SAS's data step
> capabilities.

I think Stata's developers (and at least one user-programmer)
would like to see specific suggestions of what
is easier to do in SAS, to help influence
the agenda.

Sometimes -- but not always -- it turns out
that the facilities exist; it is just not
transparent how to use them.

Nick
n.j.cox@durham.ac.uk

*
*   For searches and help try:
*   http://www.stata.com/support/faqs/res/findit.html
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/
*
*   For searches and help try:
*   http://www.stata.com/support/faqs/res/findit.html
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/
*
*   For searches and help try:
*   http://www.stata.com/support/faqs/res/findit.html
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/

*
*   For searches and help try:
*   http://www.stata.com/support/faqs/res/findit.html
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/



© Copyright 1996–2014 StataCorp LP   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index