Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: DBA Hacks Book

RE: DBA Hacks Book

From: Carel-Jan Engel <>
Date: Fri, 18 Jun 2004 21:27:44 +0200 (CEST)
Message-Id: <>

It is nice to see people using stuff you developed in a way you've never intended.....

 From mid 80's to early 90's I was working in R&D teams, building programming languages, so-called 4GL stuff, report geereators etc. etc. I've always admired programmers using my tools in totally unexpected ways.  From this perspective, it was not 'how to prevent the user from doing this or that', but 'hey, what I built is more useful then ever designed'.

The best example I remember was a report writer that I wrote in '91, based on a preditive parser architecture. It could be used together with WordPerfect, because that has a nice tagged file-format. It's still used. A textblock would be opened with a table reference and some simplified expressions. Blocks could be nested. Every block resulted in a query, and the contents of the block were iterated for any row returned. Columnnames within the block got replaced by the contents of the column. Bold columnname: bold column contents, etc. It worked very good and fast, and was a very nice tool for mail-merging and creating reports with a lot of text. The reportwriter was available on Dos, Windows and Unix, Standalone and as a Forms3.0 user-exit. Alas, I never saw any money for it, I developed it for my employer those days, who sold it far too cheap to another company. But the tool survived.

Then the users started to invent unforeseen problems for this tool: Create a block with an expression, include text, but no columns. This resulted in modular letters, dynamically put together from textblocks, depending on generated queries against the Oracle database.

The best application was using it for printing passports and driving licences: the software vendor didn't want to write all kinds of printer drivers, and implented the whole stuff with my program. WordPerfect would take care of the different printers on the market, and the scanned signature of the mayor, stamps and data of the owner were placed on the document with an accuracy of 0,01 cm.

You are totally right in a situation where a user should be prevented to create an imbalanced General Ledger: the application shouldn't allow that. However, I've always lived with the opinion that it is the user who has to do the thinking, and the program is just a tool. Some decades ago, when people were writing down all the figures manually, there was no tool withelding them from messing up. A tool (program) that tries to catch every exception or anomaly will be hard to maintain and probably unusable because of inflexibility. Saying this, I still consider myself as a good programmer. Programming isn't about being perfect, being more perfect than expected, but about meeting the specs and the requirements, to the level of quality agreed and for the cost estimated beforehand. Using an American Screwdriver to drive a screw into the wood is your own responsibility. ( I don't know of other countries, but in The Netherlands an American Screwdriver is also know as a Hammer).

Most programmers thes days are like toddlers, playing with hammers, nails and chain-saws. Good parents wouldn't allow them access to those tools. Todays damagement doesn't seem to care about the level of maturity of their developers (let them developers start to develop themselves before touching anything else...), but give their toddler-developers a nice playground with all sorts of dangerous tools. And, the management sits back totally flabbergasted when accidents happen.

Just my 0.02C

Best regards, Carel-Jan

At 03:40 PM 6/18/2004, you wrote:
> >> I work with developers who use our databases all the time in ways that
> aren't anticipated but I can't discuss it without a lot of unfriendly language.
>Here we go again…
>In prehistoric times (about 1980) when I started to learn to program, one
>of the first things I learned that if a user does something that you
>hadn’t anticipate, it was not the fault of the user. Of course it only
>meant that the programmer didn’t use his brains enough to foresee these
>things. He should make a better program, and certainly NOT try to explain
>to the user that ‘he shouldn’t do that and that’; no, if he was a real
>programmer, the user could NEVER even do ‘that and that’.
>The sentence above only means to me, that the person who developed the db
>in question should try to work smarter instead of complaining!
>Rob Zijlstra.

If you think education is expensive, try ignorance. (Derek Bok) ===

DBA!ert, Independent Oracle Consultancy
Kastanjelaan 61C
2743 BX Waddinxveen
The Netherlands

tel.    +31 (0) 182 640 428
fax     +31 (0) 182 640 429
mobile  +31 (0) 653 911 950


Please see the official ORACLE-L FAQ:

To unsubscribe send email to: put 'unsubscribe' in the subject line.
Archives are at
FAQ is at
Received on Fri Jun 18 2004 - 14:32:21 CDT

Original text of this message