ADO is Micro$oft's strategic database interface.

It isn't going away, and if you are a Windows victim user, it's a good way of getting at data. There are two ways to get at it using Python - either directly via COM, or via OPAL's Python DB-API 2.0 driver. The first way is more flexible, the second is code compatible with other DB-API 2.0 drivers. Take your pick!

Psyco is a Python compiler. Looks ike black magic to me - large speed improvements no work required!

Feedback is overwhelmingly positive.

If I had any performance issues with any of my Python stuff, I'd try this like a shot. But I don't.

SQuirreL SQL - SQuirreL SQL Client is a graphical Java program that will allow you to view the structure of a JDBC compliant database, browse the data in tables, issue SQL commands etc.

Looks really cool.

Via Sanjay's Journal of Coding Tips, via Babu.

Easily maintain SQL triggers is a nice example of the kind of thing that you can do with SQL on the '400 these days.

'Smart' databases might seem like an unalloyed good thing, but I'm not so sure anymore. Do you really want your business rules mixed up with your database?

Sure, triggers mean that you can't break the rules even when editing data with SQL, DFU, or the wonderful WRKDBF, but the temptation would be to put too much intelligence into the trigger.

You want your business rules to live in your business objects. These are the things it which you code all your business rules - usually in the form of OO classes, but you can use an RPG service program or suchlike to take the same role. Your triggers should be thin wrappers, simply calling out to the business objects for verification of the required data change, and for any consequential database operations. The database should be just a repository for your data.

Of course, your front end (be it a GUI, a web service, or whatever) should also be as thin as possible, and hook into your business objects.

And thus a 3-tier architecture is born!