Fascinating series of articles, I have been developing a bit of an offshoot to these procedures and only stumbled upon this articles by accident.

My variation on this takes a copy of database structures after a milestone release, placing them inside a locked down database and time stamps them. A familar story I am sure, I have been working with a someone who will not adhere to team standards and will 'tinker' with table structures, SSIS packages, stored procedures etc without testing, and the rest of the team only become aware when the overnight ETL process fails.

Yes, I can hear you all shouting 'lock him down, reduce his permissions, sack him!', but it is not easy to control a senior member, with some SQL knowledge, and also happens to be the company system accountant/business process guru.

My process will compare the latest stored version with the current structures and report the changes.

If there are articles eluding to controlling development by 'loose canons' they seem to be off the beaten track or hidden in the dark corridors of HR.

The problem is magnified by joining a project that appears to have evolved rather than a nice clean green field project. By combining any new work with the TDD approach, and running the comparison, I would have some control over testing. The person in question is very open to new ideas, 'Tinkering' being the result, and will hopefully latch onto this TDD concept.

On a different note, not one for re-inventing the wheel, I noticed the project was made available during part 2, could the project containing additions from parts 3, 4 and the suggested part 5 be made available?

Kind Regards

Paul Grubb