Daynote ,Svenson

MM-xi     Tuesday

2000-01-11

The mist has all been frozen out of the air tonight, not that -4°C is real cold. Definitively not when there is no wind. Well I admit to being a little out of tune with almost everybody else around here. I mean, they all come in lamenting the 'verrrrryyyy collldddd' weather. Why, I love it, cool sunny and dry. Nah.

After some discussions with Peter a few of the remaining uncertainties in the HCC specifications are cleared up so I can start at the last program.
The changes in the II (invoice address) and DR (delivery address) files, done by Dimitri, are causing some concern with the OLI people. In these address files there used to be only one record per address, now there are three different records and they have to pick the right one. Seems like nobody thought that out before hand. They will have to use the order type to decide from which module the order came and then pick that module's delivery address from DR.
And another decision concerning the II and DR has been made. All the existing records will be triplicated but new records will only be made for the module that actually needs them. That means I will have to check the programs just a tad more careful.

On the TeleSales front things are grinding to a halt. Progress V9 must be installed and everything migrated to that version but Wilbert has no time. Until everything is installed and converted Ronny has no real job apart from some minor bug fixes. See it is no good if you solve all the major bugs in a piece of software :-)

And there is a request from America to adapt the program just a little. the only way to actually do it is by redesigning the whole technical foundation. Au. The problem is that they have used the flexibility of the design to make a field required while, in the original setup it was optional. Of course the database contains no data for that field because it wasn't required. Now they want to get an error message whenever they view a record that doesn't comply with the new rules. But all the tests are built into a database write-trigger and that only goes off when a new record is added or when an existing record is changed, not when an existing record is merely displayed. There is no way we can make that trigger go off unless we actually change a field but that means double accesses to the database with double validations. On top of that we corrupt the data. OK, only temporally but nonetheless. The only satisfactory way out is by removing the validation from the database trigger and put them in the presentation code. This would cause maintenance problems and it would leave us with a weak database, open to illegal updates.

My proposal is to cut into the flexibility. If it becomes difficult to fiddle with the validation settings we can prevent the problem. For example by adding a simple program that, upon changing a rule, checks the database and presents all the problem records for correction before committing the rule change. The possibility is still there but it becomes a hell of a job. (Have I been reading too much BOFH sections lately?) That would not stop the discussion which is now raging on an architectural level.
Ronny may not have verry pressing work but he does have a lot explaining and defending to do <G>

I took another route home, much slower but with a far less trafficked border control. Result, no pile up and I am home at 20h05.

Adios