Re: Start MS-excel from oracle on clientPC

"Sybrand Bakker" <postbus_at_sybrandb.demon.nl> wrote in message news:<uig6u3c1utmc5e_at_corp.supernews.com>...
> Comments embedded
>
> So this just means business-rules implemented outside the data-model.
> Business-rules should be implemented in the database.
> What you are basically discussing is automating chaos, which definitely will
> not resolve the real problem.
> Garbage In is Garbage Out.
> >
> I think in your situation time has come to replace the flat tire instead of
> trying to repair it. You are coping with a disaster situation and the only
> *real* solution is to implement the business-rules where they belong: in
> the database. IMO, there can be no discussion about that.
> Any other solution is going to be frought with errors.
> It shouldn't also be that difficult to change them.
> Quite likely your *real* problem is the business-'rules' are changing on the
> fly, by the day, and possibly even per person. No application can automate
> chaos, and usually the chaos even gets worse once it is automated. I've been
> there quite a lot of times: there are too many organisations that don't know
> what they want.
> The evident method to *repair* your flat tire, is to keep track of changed
> records with your database trigger, and have an Excel/VBA application filter
> those, apply the business-rules and have the VBA application update the
> database. Preferably this should be a VB application calling Excel and using
> Oracle Objects for OLE to prevent wastage of resources.
> However, I have to stress the real solution is to implement business-rules
> in the database and maybe to change processes.
> >
>
> Regards
>
>
> --
> Sybrand Bakker
> Senior Oracle DBA
>
> to reply remove '-verwijderdit' from my e-mail address
> > > >
> > > By creating a disaster application, which is the architecture you lay
> > > down above.
> > > PL/SQL can just do any calculation, and I can't imagine that anyone
> > > with only a bit of sanity in his mind would endeavour to write an
> > > external function to call Excel from a trigger, while Excel can call
> > > Oracle using ODBC.
> > > In short: either try to explain what is so complicated that would
> > > require Excel, or try to get acquainted with ODBC and VBA to implement
> > > your requirements directly in Excel.
> > > Calling Excel from a trigger is just not going to work, unless this is
> > > a mickey mouse app, which is supposed to work from one client only.
> > >

Sybrand,

Your comments are sometimes amazing. I think you need to get out of the assumption that *One size fits all*..which in your case *RDBMS* can provide solution to *Every* business problem...and if it cannot then anything outside of it would be *Disastrous*. Although it is always a good idea to implement *ALL* business rules in the database...sometimes it *Just* is not possible or does not make any sense to do it. RDBMS's are very good when it comes to relational data and PLSQL engine gives you a lot more to manipulate that data *BUT* PLSQL engine was not designed to handle complex mathematical calculations like e.g. C/C++ engine can. Case in point...Product configurators.

An example of it is let's say your company sells highly cunfigured office furniture. You want a tool that gives you the power to configure e.g. an office chair right in front of the customer and create a Bill Of Material. Configuring an office chair could be that you have 5 different styles to choose from, if you choose a leather style then you have 20 different options to choose your armrests and 10 different styles to choose the headrest. If you choose one armrest then you can only have a certain kind of legs with a certain kind of wood. As you can see it starts getting complex.

If you *ONLY* are selling chairs with maybe three levels of options...then you may attempt to build a configurator right in the database with *Lots* of PLSQL code. But what if you are selling customized boats or something like that. In that case the ideal situation would be to store your parts and parts structure in the database...use an external configurator to configure your product then save the configuration with BOM in the database.

In Siebe's case..looks like his company wants to leverage something they have already built in Excel and somehow integrate with Oracle. There could be any number of possible solutions to their business process..where they may even end up putting everything in the database. *BUT* to say that *Anything* other then one solution is *Disastrous* shouts *Shortsightedness* and not thinking *out-of-the-box*.

My two cents. -:)

Regards
//Rauf Sarwar Received on Sun Jul 07 2002 - 11:31:05 CDT