Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
![]() |
![]() |
Home -> Community -> Usenet -> c.d.o.misc -> Re: Interactive Interface for Oracle ?
Daniel Morgan <damorgan_at_exesolutions.com> writes:
> Joel Garry wrote:
>
> > fransh_at_hotmail.com (Frans H.) wrote in message news:<31abf0e5.0304180456.502a30eb_at_posting.google.com>...
> > > Daniel Morgan <damorgan_at_exesolutions.com> wrote in message news:<3E9F7617.35F3D6C8_at_exesolutions.com>...
> > > > RM wrote:
> > > >
> > > > > I need to create an application where the end user can retrieve data from
> > > > > Oracle and send the output to excel spreadsheets. Basically, I need to
> > > > > provide a user friendly graphical interface where the user can input their
> > > > > criteria's.
> > > > >
> > > > > Do you have suggestions as to sources that can tell me how to do this. Any
> > > > > books, web site etc . . .
> > > >
> > > > No. Nor would I ever support sending database data to a spreadsheet. Unless,
> > > > of course, the object of the exercise is to let end-users massage data so that
> > > > reports will reflect untruths.
> > > >
> > > > What can they possibly do in Excell that can't be better done in Oracle with a
> > > > decent report writer? Nothing except as noted above.
> > > >
> > > > Daniel Morgan
> > >
> > > Oracle Discoverer would be an option, or Oraxcel.
> > > And there are a few things that can be better be done in Excel than
> > > with a report writer. Think of the graphics (although there are much
> > > better programs around) or of the analytical functions in excel.
> > > Furthermore there are several analytical programs that will more
> > > easily use spreadsheets as input,
> >
> > Some users have wild screaming orgasms when I give them a program that
> > can grab the oracle data into Excel, integrated into their other apps
> > that run thin-client (ie, enter data about a customer and a product
> > and have a spreadsheet magically appear that they can manipulate for a
> > quote, email back and forth to production engineers and so forth).
> > Even though I seriously hate Excel and do much to avoid it, there's
> > something about my customers having wild screaming orgasms that tends
> > to be lucrative. I was bummed to find out the vendor of the program
> > language has decremented the activex stuff (which, since I seriously
> > hate MS software, has given me mixed feelings, to say the least). If
> > it were up to me, of course, I would try to put everything into
> > Oracle, but it isn't, and even if it were, it would take a long time
> > and be very expensive to get there. And that isn't in the budget.
> >
> > To the original poster: I think VB and similar things suck, but it
> > and activeX sounds like what you want. Also, go into excel help and
> > type in Oracle, you may be able to do what you need directly with
> > macros, if the needs are simple enough and you have a suitable db
> > design. The group would probably be interested in your thoughts on
> > oraxcel, too. Discoverer is a good tool, but it has quite a learning
> > curve and you may need DBA support and perhaps an expensive class to
> > get going.
> >
> > jg
> > --
> > @home.com is bogus.
> > http://www.signonsandiego.com/news/uniontrib/wed/business/news_1b16aol.html
>
> Your client's lack of a personal life not withstanding ... I don't believe there is a single bit of
> functionality in Excell that can't be found in all of the major report writing tools.
>
> And all without the ability for end-users to corrupt the data.
>
> Daniel Morgan
>
While what Daniel says has some validity, I think the academic in him is showing just a little. In a perfect world, we would only have reports generated with tools like crystal/discoverer by users who understood the tools and the database/data they are manipulating. However, often in reality there are insufficient resources to do this and some level of compromise needs to be reached.
In our shop we have teams of support staff who are responsible for generating and maintaining reports for our end users. They use crystal, discoverer and sql/plsql. They produce about 90% of the reporting needs of our end users. However, there is another 10% of ad hoc reports which users want and for which we cannot justify spending the resources on to have them maintained by our support staff. In these situations, we provide a web form which the end user fills in with their parameter values and which generates a tsv file - on windows systems, this will result in excel firing up and the file being read directly into it. This works very well because the end user gets the data in the format they want and when they want and it does not require constant mainteneance by the support staff.
As Daniel points out, doing this does mean end users could mangle the data and create reports which are incorrect. This is always a danger - even if you provided them with report writing tools, they can still get it wrong. Therefore, I think its important to weigh up the dangers and then decide - sometimes the only person affected by mangled data is the one doing the mangling. Other times, mangled reports may result in the wrong decisions on issues which are important to the business as a whole, in which case you need to be far more careful.
Tim
-- Tim Cross The e-mail address on this message is FALSE (obviously!). My real e-mail is to a company in Australia called rapttech and my login is tcross - if you really need to send mail, you should be able to work it out!Received on Fri Apr 18 2003 - 21:49:43 CDT
![]() |
![]() |