Re: Cross Table (Pivot Table) with Oracle Spread Table Control (MMTX32.OCX)

"Andreas Rothenwaender" <Andreas.Rothenwaender_at_safe.at> wrote:

>Thanks for your reply, but I'm not looking for something that creates "right SQL"
>I just wanted an easy way to display data which comes in the form

Nothing is easy. :-)

>
>in a spread table of the form
>
>+-------+-----+-----+-----+
>| Key1 | 1 | 2 | 3 |
>| Key2 | | | |
 +-------+-----+-----+-----+
>| 1 | a11 | b21 | c31 |
 +-------+-----+-----+-----+
>| 2 | a12 | b22 | c32 |
 +-------+-----+-----+-----+
>| 3 | a13 | b23 | c33 |
>+-------+-----+-----+-----+
>
>What is wrong with using a prebuilt control that does exactly this
>(providing it does it really - but it seems to do)?

Nothing wrong - my problem is about delegating control from your application to a 3rd party control. I dislike the idea of having my application software depending and relying on other 3rd party application ware (which is what most OCX's are).

Then there's the problem with different versions of the same OCX. Installation and registration of that OCX. Support for that OCX. Try and get the OCX authors to fix bugs in that OCX. Royalties and copyright of that OCX. And the list goes on and on.

Creating pivot tables is _easy_. To create a Delphi base class called TPivotTable that supports basic pivoting functionality will probably take a few hours. You subclass the TQuery class to create a SQL class. Have one of the properties of that class be a string grid. And so on.

End result - you have a class that you own. You know what is going on. You can fix the bugs. You have re-usable code that can be used again and again. You have the flexibility to make that class more and more powerful and grow with the analysis and display demands of the user.

All it took was a little effort to design, wrote and test that class initially. And you will be reaping term benefits from it. For years to come.

Using an OCX in comparison.. sure the initial "start up" time is much easier.. until you start to hit limitation after limitation. Until you try and distribute that app with its dependancies on OCX's to 1000's of users running various flavours of Win'95 OSR1, Win'95 OSR2, Win'98 OSR1, Win'98 OSR2, Win-NT 4 (insert service pack number here), Win'2000 (insert service pack numbe here). Each of these containing various flavours of OCX installation, Windows hot fixes, Windows security fixes and so. And so on.

Developing software does not mean in my mind "oh see how easy is it for me to write code using an OCX". It is about _MEETING_ the requirements. And that includes DISTRIBUTION, SUPPORT and MAINTENANCE.

And this is why I have never supported the use of OCX's in any of the development projects that I've managed.

Also why I get rubbed the wrong way by programmers (especially the VB/MS Access crowd) who think ito "what OCX can I use to do this?". They are not programmers, but code jockeys trying to wire together a bunch of black boxes and call it a solution.

>Or do you think a SELECT-DECODE-construct which feeds a standard
>spread table would be nicer and quicker?

Quicker? - yes ito performance. As the SQL is controlled by _you_ and not by the OCX which may decide to do things less than efficient.

Quicker ito development? No - OCX provide quick fix - and a dirty one that has the habbit of biting you in the butt in the medium to long term. Which often requires trashing the OCX and developing that functionality that was offered by the OCX yourself anyway. Wasted time and resources. One that I have seen a couple of times myself when "corporate systems" were developed that used OCX's as crutches.

Nicer? If by that you imply "nice - see I just drag and drop the OCX into my form", then no - writing your own SQL is probably a bit more difficult.

But then developing software as I said is not about making the programmer's life nice - it is about create nice software that is easy to maintain, distribute, support and grow.

>My question is still "HOW can I use the given tools?"!

SQL. SQL. SQL. That is the only tool (interface) that you need IMO. It is flexible. It is powerful. And you control it. :-)

OCX are not a substitude for a well designed OO class hierachy. Like what you have from Inprise/Borland with their Delphi/C++ Builder/Kylix products that supports the same OO class hierachy across multilple languages (C++ and Object Pascal) and across multiple platforms (Windows all versions and now Linux with Kylix).

regards,
Billy Received on Fri Jun 09 2000 - 00:00:00 CEST