Of all the days for it to happen.

I found a couple of bugs in my DAO package this morning. Actually three, two of them are really embarrassing, and obvious, and stupid. The third was a genuine bug, a typo that in initial checks looked right.

BUT

I am writing this at work as I use it for all of my data access, the fixes are ready to go and I figured I'd get them published before anyone saw the bugs.

I work for SATAC and they use the Adelaide University Network which, today, got flooded out. DNS went away, outside links went away, our phone system died. Version 2.0.1 of my DAO is all zipped up with nowhere to go.

To top it all off, I am in Sydney next week and won't de able to get to it until Wednesday.

A slight retraction.

I have just spent three days on an Ingres training course.

Once again, warnings about playing nice came from all sectors.

Part of this course was learning about the internal architecture of Ingres and how it handles tables, logging, backup and recovery. I was in complete control of an Ingres database server, mine to configure, manipulate and break if I wanted.

Ingres is a pretty good database system.

There I said it.

It would appear my main problems come from legacy constructs, poor design and bad implementations. This system needs an enema!

The negatives of Ingres are thus:

1. Lack of cross table support


2. Ingres Net


3. Minimal JDBC support

Lack of cross catalog support means we cannot logically and physically divide a database into basic groups that allow greater control of access.

Ingres Net is a throwback to propriatry network protocols. We can safely get rid of it.

I say JDBC support is minimal because I found a bug in the JDBC connections that turns out not to be a bug, but a limitation. The JDBC doesn't have any really understanding of the client setup, so it cannot figure out how to change the database times from GMT to local. This morning I wrote a quick java class to allow that to happen (using the symbol.tbl file). It took my four hours, and that includes the crude symbol.tbl editor. I've sent it to CA, they might use it.

That's all. My concerns about the insane data table layouts where unfounded, it's actually similar to MySQL. The wierdness that is the backups is just the ongoing struggle that we have with checking audit trails and the like that are not supported in the in-house system. Speed issues are a design issue. None of these things are Ingres faults. Some naming conventions are odd, to do an ascii backup of the database, you unload it. To backup normally you checkpoint it, to restore it is a rollforward. These names do make sense once you have looked under the hood, and with journalling and checkpoints the restoration of a database is fast and you can recover everything to the last correct transaction. This is done by the use on a very elegant solution.

At the end of the day, though, the lack of catalogs is a biggy!

All there agreed that the report writer is archaic and has only one T and is only really used to produce a once off quick and dirty report on the fly for people who don't need it to be pretty.

You can set local variables in scripts from selects, just not in an obvious way, and I've forgotten it already. I'm on another course in a fortnight, will keep you informed.