I rolled the site back to 1.67, and it starts up ok, so that still works. I can log in and the defects are all still there, so the good news is that it did not stomp on me defects database. Phew.
I guess I can copy my entire install, duplicate the database and then thrash this problem out on a sacrificial system, but if anyone knows anything more than that it would help. I had a look at the sql script in question but I'm not sure what it's working with. Where is the user database stored? I assume that's the ExtendedSqlMembershipProvider, but I can't see what/ where that is, data wise. Is it an mdf file, and if so, where is it? My connexion string points at the defect database, not the membership/ roles provider, so it's nothing to do with that. Where physically does my membership databse live - I followed the instructions and so did not keep the App_Data thing as I don't use SQL Server Express. But there is something in there - what's that for? I'm just thinking that it needs to be able to see my user database to use it, and how's it going to do that?
What's the significance of "installation date"? This is written into the web.config by the program (thereby ensuring you can't run the install on medium trust). So I have to run it on a test machine (under full trust), then deploy to live once the install is done. I don't see why that should be an issue, but is this date used as a flag of some sort, and if so, what does it control?
Can I run the sql script directly from MSSS and see if I can figure out what it's up to from there? I'm sure my install is good (I documented what I did last time, and repeated the steps this time).