not sure what you mean by a finger pointing issue. If you have issues with the paid DNN Support, I suggest you take it up with DNN Support, and not communicate through these forums.

With respect to the error discussed here, i noticed this myself too. The way i set up my local db's is to have DNN connect with an SA account. Not secure, but other than that extremely usefull in a development environment. I got the same error on th  SA account, and of course, the account had no explicit rights on the DB. After i gave that account explicit rights as DBO on the database, DNN installed just fine. So while this will not fix the issue, you might want to check wether or not the account has explicit rights to the db.

DNN Blog | Twitter: @erikvb | LinkedIn:

>/* Set DataType List to be a SystemList */
>/****************************************/
>
>UPDATE Lists SET SystemList = 'True' WHERE ListName = 'DataType'
>
>[end]

I too have found this problem.  It would seem as though the 5.2.1 install/upgrade script hasn't had the {objectQualifier}.

This showed up over about 6 different attempts to install, across two different operating systems and three different sql server versions, all trying to work out where the problem was.   I received various errors, some pointing me to the sqldataprovider log file, and another with a "FAILURE 400 - Generic failure" - which I have never seen before. 

Also, unlike before, you can't re-run the install or you'll trip over the new code which is designed to stop scripts from running.  The symptom is a flashing screen with an 'undefined' error continually scrolling causing an infinite loop.  This means you have to dump your database and start again if something goes wrong during the upgrade process.  This isn't as good as before.  Perhaps the anti-hacking measures could be disabled until the system is first run and the install is finished?

The solution for me (while waiting on 5.2.2) is to update the 5.2.1.SqlDataProvider file (before running the install) so that the above line

UPDATE Lists SET SystemList = 'True' WHERE ListName = 'DataType'
 

Is changed to

UPDATE {databaseOwner}{objectQualifier}Lists SET SystemList = 'True' WHERE ListName = 'DataType'
 

I think a test of the install script including an objectQualifier in the web.config is probably needed for the release process.  I know that using an object qualifier isn't popular, but I always use this to test out my modules, as it is an important part of compatibility.