[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

From |
Phil Schumm <pschumm@uchicago.edu> |

To |
statalist@hsphsun2.harvard.edu |

Subject |
Re: st: Running stata from Excel : why not you can with SAS |

Date |
Wed, 9 Mar 2005 10:45:12 -0600 |

At 09:18 AM -0500 3/9/05, Stephen Graham wrote:

SAS introduced SAS Integration Technologies a few years ago, and I have had success in creating excel application that can "talk" to SAS in an appreciable way. I like the fact I can create a very simple front-end (excel) to complicated programs. This gives the user a front-end that is easily recognizable and common.

Being that I worked for a STATA owner for almost 5 years (Hi, to all WC people who are reading) I am an extreme advocate for STATA. Is there a way of doing a similar thing with STATA? I would love to bring STATA's superior everything to the table.

There are several issues here, one of which is the contention that another interface is somehow more "user friendly" than Stata's own (many of us, I think, would disagree). However, there certainly are legitimate reasons to want to interact with Stata from other applications (e.g., integration with a text editor, driving Stata from a cgi script, etc.). And currently it *is* possible to launch Stata and to pass it a do-file for processing. This can be done directly from the shell in Unix/Linux/OS X and also via Apple Events in OS X (and I believe in Windows too -- I just don't know how). This might be used in conjunction with Stata's ODBC capability to set up some limited interaction between something like Excel and Stata.

The problem with facilities for inter-process communication is that they tend (necessarily) to be platform-specific. Thus, to develop these StataCorp would either have to spend a substantial amount of effort to make them work on all platforms, or disenfranchise some if its users.

An excellent way to make a specific task "more accessible" in Stata is to write an ado-file which wraps together several commands. This can be made very easy-to-use (e.g., it can involve interactive prompts or even be menu-driven), but has the advantage that it is accessible to anyone using Stata, regardless of which platform they're on. Moreover, another important advantage of this strategy is that it is easy to expose the underlying process (i.e., by incorporating a noisily option), which is an excellent way (1) to reassure the user that he or she knows exactly what is being done, and (2) to help teach the user how to use Stata.

Note that even with this approach, there are ways that you can facilitate the use of other applications together with Stata. For example, in our group we use an effort reporting system to record time spent on specific tasks. We have several input interfaces none of which involve Stata but each of which is able to save the data in files which Stata can read. We then have an ado-file which people can use to summarize their effort and to generate reports. Although this is not as neat as a fully integrated application, the two work very effectively together.

-- Phil

*

* 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/

- Prev by Date:
**st: RE: Running stata from Excel : why not you can with SAS** - Next by Date:
**st: quartz & quickdraw labels for StataSE 8 OS X** - Previous by thread:
**st: Running stata from Excel : why not you can with SAS** - Next by thread:
**st: RE: Running stata from Excel : why not you can with SAS** - Index(es):

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