Foreign Key constraint error when performing fresh install of Piranha CMS

Piranha CMS is a programmer oriented CMS (I prefer to write it since I've been downvoted last time!). I've spent all the afternoon trying to fix this problem : Whether I try to migrate from a Sql Compact Server Database to a SQL Server Database, or to start everything from scratch with an empty SQL Server Database, I get the following error :

Introducing FOREIGN KEY constraint 'FK_dbo.category_dbo.sysuser_category_updated_by' on table 'category' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints.

I am able to pass the first step (admin account and password creation), but this exception is thrown whenever I try to log in.

What am I doing wrong ?

Thanks for your help !

UPDATE

The stack indicates where the error is coming from :

[HttpException (0x80004005): The pre-application start initialization method 
Start on type Piranha.Web.ApplicationModule threw an exception with the following
error message: Introducing FOREIGN KEY constraint
 'FK_dbo.category_dbo.sysuser_category_updated_by' on table 'category' 
may cause cycles or multiple cascade paths. Specify ON 
DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints.
Could not create constraint. See previous errors..]
System.Web.HttpRuntime.FirstRequestInit(HttpContext context) +9915300
System.Web.HttpRuntime.EnsureFirstRequestInit(HttpContext context) +101
System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, 
HttpContext context) +254

There seem to be a problem with the Method Start of Piranha.Web.ApplicationModule.

Also I have noticed the configuration of Entity Framework is :

<entityFramework>
<defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework" />
<providers>
  <provider invariantName="System.Data.SqlClient" type="System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer" />
</providers>

I wonder about the :

invariantName="System.Data.SqlClient

Since System.Data.SqlClient is the Provider mentionned in my connection string. But I don't know if it's relevant since it may just mean that EF is used to retrieve the data. But I wonder if there might not be a conflict since both your internal scripts and EF use this connection string with this provider that is mentionned. Also, I'm not sure, but I know that with code-first EF also creates meta-data when it creates a database. Perhaps since your internal scripts doesn't create them, EF considers that the DB doesn't exist ?

Update 2

I have some news, I have added

Database.SetInitializer<Piranha.DataContext>(null);

In Application_Start to avoid Database recreation. It seems to have solved the database re-creation problem. I no longer see the exception concerning the constraint. However now the PageController throws a null reference exception after trying to log in, and I still can't see anypage of the public website (The publc site throws an internal server error). My guess is that when I set the Initializer to null, it also prevents EF from populating the DB with the basic data of the Framework. That's a good step further, so it seems that the problem comes from the Piranha DataContext Configuration.

Update 3

Just to give more details :

When trying to log in, I'm redirected to manager/page which throws a null reference exception as I said before. This exception is thrown when I try to access most of the pages of the manager (I have tried template/pagelist, setting/userlist) however, when I try "manager/post" I get the following error :

Invalid object name 'dbo.post'.  
Exception Details: System.Data.SqlClient.SqlException: Invalid object name 'dbo.post'.

But the 'post' Table do exist in the Database... It's a fresh install, I only changed two things : the connection string, and the Database Initializer code I added in Global Asax.

Solution

Reason for error is Schema name in my case.

Solution: You require to have database objects belonging to dbo schema, if you've installed on fresh database with different schema name, it will throw this error. To fix it, change schema name of those tables to dbo and it will work like a charm.