I have run into a couple quirks, and think I have them addressed.

In /install/mssql/views.sql the views "vaccess" and "vaccessfull" and "PMessageView" in this database are 'tables' and not views. I have added some SQL in the file to check for this and drop those tables so the views can be created. So now the views.sql checks for views and drops, then checks for those three tables and drops, before trying to create views --

In /install/mssql/constraints.sql the FK_YAF_Group_YAF_Medal fails because there are no 'candidate keys' in the YAF_Medal table. I added a step in constraints to create the PK_YAF_Medal on the MedalID column (to reflect what one of my 1.9.6.2 databases shows as exists) in the Primary Keys section prior to the FK being created in the FK section. Once testing succeeds, would you rather I post the updates here or create a pull on Codeplex?

These issues are present in the current repository as of 2012/10/06 - so the changes (if they are usable and proper for YAF team) would need to be added still into the repository.

It was being added when the table was created. I'll add it.

Please post here, I'll simply merge it. The changes are not bulky.

No changes needed --

An extra note -- even though it returns false to test if the forum is new or upgrade, and hides the checkbox for 'upgrade/install bbcodes - topic statuses - file extensions', it attempted to perform that task and threw the exception - as if the installer was in upgrade mode and trying to upgrade the BBcodes...

But again - we do have a populated database that runs under 1.9.3 - so I'm not sure if there's a corrupted entry in my DB that I need to look for to get this phase to function properly. Other than the exception when the BBCodes tried to process, the upgrade did successfully upgrade the database - I see all the new procedures and other things that come in 1.9.6.2 - but the installer did not complete properly... When it tried to refresh after the DB 'initialize', that's when it threw the BBCode exception. For what it's worth, my db is still populated...

It is in a try - catch block and it silently drops all exceptions, if something goes wrong it simply returnes false. It should be converted to a method too.

For my purposes, would it help if I told the 'catch' to throw the exception and see what error I'm getting instead of just returning false? Would probably help pinpoint the error --

[SqlException (0x80131904): Could not find stored procedure 'dbo.yaf_board_list'.]

So I restored the DB back to the 1.9.3 original backup and attempted to get a listing of the stored procedures in the database - there are none.

So I'm going to pull down a copy of 1.9.3 and find out of there is something screwed up in my database. I was under the understanding that sprocs were used in YAF back to 1.9.1.x and even before -- but I might be wrong --

If I'm wrong - then basically I would need to add that sproc to the database prior to running the upgrade and it should process. Will test and report.

UPDATED: There's something screwed up in my database. I have no stored procedures at all in there after restoring from my 'live backup'... I f****** hate Plesk sometimes...

Not a YAF issue at this point...

For some reason, when I backed up this database originally to test the upgrades, the way Plesk backed it up, I got a properly sized file reflecting my database content, but inside the database, there were things that were wrong. The two vaccess views were stored as tables in the backup instead of views. No stored procedures were copied over. Nothing proper. The only thing that was right was the data itself... Even some indices were missing.

I went through the SSMS and repulled a native backup. This time, the views were actually views and the tables had the missing data.

The give-away should have been that the installer was operating in "Install" mode instead of "Upgrade Mode" - when I knew I had data in the database. The installer saw a problem but because no exception was thrown when the installer tried to query the sproc that did not exist, it defaulted to 'new install' -- other than the logic of try/catch in the IsForumInstalled being a little lacking, the installer functioned as it was supposed to and tried to install a new forum. That's where the .sql files were having problems - because there was data in the db but the installer was treating it as a 'fresh install'.

My deepest apologies for the false alarm on the SQL files. It almost makes me wonder maybe a way to test if this is an existing forum database would be to query the YAF_registry table directly maybe query the version or versionname fields if querying the sproc fails or if there is an exception... I'm probably overthinking it...