zmajček is now zmycheck7, and on 11th it was 5. Maybe I'll find some trace as to what happened meanwhile.
Had a chat with the guy at Lab, voice only, don't know what it was. More work on CAAR. Cryptic remarks like "Testicular NOA and OA would be TESE or TESA however we aren't able to determine whether its non-obstructive azoospermia (NOA) or obstructive azoospermia (OA) based on the production method. We are therefore better to leave it blank for this option and have a validation rule that it's empty so they can select the right one." abound. The "F#2613 'Reason why some oocytes were not used' - they have two identical lists with different codes, so just substitute". It seems that 2613 is the bug number in FogBugz (by Joel Spolsky). It seems I reran my builder for the CAAR page, as the whole library is marked with this date, though the code indicated this happened two weeks ago.
Next day: in upFeds I had to set the collation to default on new fields. While SQL server is mostly good, it's still m$ and has some stupid decisions made. When adding a field, it has to assign some collation to it, but it takes the wrong default (as m$ often does), that of the temp database (which is permanently there :)), not of the database in which its table is. So I have to tell it. It refuses to compare strings of different collations unless specifically told how to convert them.
Restored the Lab database from backup, running the looong script on it.
On 17th, a weird thing, typically a programmer glitch. I have a routine called bumpdate, which would go through the whole database and bring all the dates closer to today - let's say, to have the latest cycle or scan happen today - so that checking the calendar etc would not require too much search for dates where we do have something. In the long run, saves a lot of time and allows for reuse of old databases - typically, the tests would be run on a copy of something from SFBC from 2009 or so. And then I'd hit a snag, because there were dates like 31.12.9999 - someone somewhere had the bright idea to push something into future that way. Then bumpdate would try to add a thousand-some days to that and it would bang, fox can't do dates after that date, that's its y10k bug. So because of someone's bright idea, I'd have to check a couple of million date values against this max date.
Not different from what users used to do in the nineties - the customer codes would be four digit, and they incremented them manually, and so when I tried to add the automatic increment-by-one, I'd usually check for the largest one so far and add one. Nope, they already used 9999 and 9998 and 9997 for some special purposes.