I have exactly the same issue having upgraded from 4.9.4 to 5.1.2. My upgrade log files are empty, which would appear to indicate that everything went perfectly. No sign of Extensions (Module Defs replacement) and whatever replaced Skins in 5.x.

Please help, somebody, this is a problem that many people are clearly having, and it needs fixing!

---

Jon Silver
JFDI Phoenix Ltd
Microsoft Gold Certified Partner

I hit a series of similar and I believe related set of problems on a test upgrade from DNN 4.09.02 to 5.01.02 but did show SQL errors in the 05.00.00, 05.01.00, and 05.01.01.log files. All of the errors stemmed from failures to drop and the re-create the Packages table with major changes in its structure. Without the proper columns in the Packages table, many of the administrative controls (which moved from the \admin\controls folder to \DesktopModules\admin folder were not properly registered resulting in errors when navigating to Module Definitions, Extensions (was completely missing), Skins, etc.

Further analysis showed that the root of the problem was failure (in 05.00.00.SqlDataProvider script) when attempting to drop the foreign key constraint FK_DNN_PackageAssemblies_PackageAssemblies on the DNN_Packages table. Apparently back in DNN 4.06.xx or so when the Packages table was added to the database, there was a missing {objectQualifier} token in the name of this FK. For those of us who had defined an objectQualifier in their web.config (in my case it was DNN_, the resulting FK constraint name then became FK_PackageAssemblies_PackageAssemblies. For those not using an objectQualifier, there would be no problem in dropping the FK constraint.

In the 05.01.01.SqlDataProvider script another attempt is made (apprently to fix a related issue of the script not completing when run on MS SQL Server 2000) to restructure the Packages table but that too fails in when first attempting to drop the FK constraint FK_DNN_PackageAssemblies_PackageAssemblies which did not exist. With th FK constraint FK_PackageAssemblies_PackageAssemblies still in place on the Packages table, the table itself could not be dropped and replaced by the newly structured Packages table.

I finally worked around this first on the test site then the production site by directly editing the database to rename the FK constraint "FK_PackageAssemblies_PackageAssemblies on the Packages table to "FK_DNN_PackageAssemblies_PackageAssemblies" before triggering the upgrade. This time the upgrade completed without error and the site appeared to be working well.

Caution: The above would apply ONLY if your site uses a non-blank objectQualifier. If your objectQualifier is something other than "DNN", use that when renaming the FK constraint. As always take a full filesystem and database backup before attempting the upgrade. 

---

Bill, WESNet Designs
Team Lead - DotNetNuke Gallery Module Project (Not Actively Being Developed)
Extensions Forge Projects . . .
Current: UserExport, ContentDeJour, ePrayer, DNN NewsTicker, By Invitation
Coming Soon: FRBO-For Rent By Owner