Remember that I blogged about problem that I had (New MOSS SP2 bug) where suddenly my SharePoint environment died and was giving me the error in the event viewer :
The schema version (22.214.171.124) of the database SharePoint_AdminContent_5e188b87-c7a8-4e0a-a488-b21a4a89e941
on mosswin2k3 is not consistent with the expected database schema version (126.96.36.199) on mosswin2k3.
Connections to this database from this server have been blocked to avoid data loss.
Upgrade the web front end or the content database to ensure that these versions match.
Well.. I had pinpointed the problem to the fact I was using a function of WSPBuilder called “Copy to GAC”. Now this function copies all the .dll’s from the debug/release folder of your project into the GAC. I worked on a solution which I had worked on my local machine before I took into my VPC to develop on. During that time I had copied all the SharePoint dll’s locally in my project (eg. ‘Copy Local’ of the references were set to True) so I could develop against the SharePoint API.
So you can guess what happens if the “Copy to GAC” function copies old versions of the SharePoint .dll’s in the GAC right? ;) Yes, SharePoint was now dealing with old dll’s in the GAC while the databases were running on a higher version. When I copied the .dll’s back from the ISAPI folder in the 12 hive into the GAC, everything worked again! w00h00w!
Concluding that the schema version error was absolutely right and it made sense that the PSConfig could not find the new types that were introduced with SP2 and thus failed. So I wasn’t a bug but merely a stupid action on my account where I didn’t pay attention to the output window of the WSPBuilder of which .dll’s were copied during the “Copy to GAC” function.
Want to thanks Neil Hodgkinson as well for his valuable time in supporting me with this issue ;)
Technorati Tags: SharePoint