Error when install for the second time in the same server

I have problem install concrete 7.2.1 when i shall install it for the second time, after deleted concrete and all databases from sql. This problen ONLY happend if i choose FULL SITE in the install procedure, and NOT if i choose Empty site. Here is the errorcode. And can someone tell me what i shall do ti install it once again on the same server with FULL page.??

Install concrete5

An exception occurred while executing 'INSERT INTO FileStorageLocationTypes (fslTypeHandle, fslTypeName, pkgID) VALUES (?, ?, ?)' with params ["default", "Default", 0]: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'default' for key 'fslTypeHandle'.

#0 /customers/6/4/f/ Doctrine\DBAL\DBALException::driverExceptionDuringQuery(Object(PDOException), 'INSERT INTO Fil...', Array) #1 /customers/6/4/f/ Doctrine\DBAL\Statement->execute() #2 /customers/6/4/f/ Doctrine\ORM\Persisters\BasicEntityPersister->executeInserts() #3 /customers/6/4/f/ Doctrine\ORM\UnitOfWork->executeInserts(Object(Doctrine\ORM\Mapping\ClassMetadata)) #4 /customers/6/4/f/ Doctrine\ORM\UnitOfWork->commit(NULL) #5 /customers/6/4/f/ Doctrine\ORM\EntityManager->flush() #6 /customers/6/4/f/ Concrete\Core\File\StorageLocation\Type\Type::add('default', 'Default') #7 [internal function]: Concrete\Core\Package\StartingPointPackage->import_files() #8 /customers/6/4/f/ call_user_func(Array) #9 [internal function]: Concrete\Controller\Install->run_routine('elemental_full', 'import_files') #10 /customers/6/4/f/ call_user_func_array(Array, Array) #11 /customers/6/4/f/ Concrete\Core\Controller\AbstractController->runAction('run_routine', Array) #12 /customers/6/4/f/ Concrete\Core\Routing\ControllerRouteCallback->execute(Object(Concrete\Core\Http\Request), Object(Concrete\Core\Routing\Route), Array) #13 /customers/6/4/f/ Concrete\Core\Routing\Router->execute(Object(Concrete\Core\Routing\Route), Array) #14 /customers/6/4/f/ Concrete\Core\Support\Facade\Facade::__callStatic('execute', Array) #15 /customers/6/4/f/ Concrete\Core\Support\Facade\Route::execute(Object(Concrete\Core\Routing\Route), Array) #16 /customers/6/4/f/ Concrete\Core\Application\Application->dispatch(Object(Concrete\Core\Http\Request)) #17 /customers/6/4/f/ require('/customers/6/4/...') #18 /customers/6/4/f/ require('/customers/6/4/...') #19 {main}

View Replies:
IGotNothin replied on at Permalink Reply
I'm having the same issue. I've deleted the database, code, etc. multiple times. It seems to fail at different points in the install each time I try, but with similar error messages. Permissions are all correct and my first install went smooth. Just won't let me install a 2nd instance. Very odd.

I'll post again if I find an answer.
robodev replied on at Permalink Reply
This, from what I can tell, is a bug in the installer. It's trying to create a unique value in a table. Creating a unique key works the first time, but on second install, it's not unique anymore.

It's because the db.xml is requiring a unique key on the fslTypeHandle field.

The first time you run it you have a record with a default value of "default" for fslTypeHandle, so it won't let you enter any more.

The db.xml for the application has:

<index name="fslTypeHandle">

I could be wrong, but make sure the table called 'FileStorageLocationTypes'

has something other than 'default' as the value for "fslTypeHandle" column
IGotNothin replied on at Permalink Reply
But given each install is using a different database, I wouldn't think this would be an issue. And in my multiple tries, the table that ends up with the error changes, so not always that one. That and I used the same installer on the first instance and it worked just fine then.

Good thought though, thanks for trying to help!
Falconova replied on at Permalink Reply
I cant find that db.xml you describe here. My db.xml in concrete / autentication is like this.

<?xml version="1.0"?>
<schema version="0.3">
<table name="authTypeConcreteCookieMap">
<field name="ID" type="I">
<key />
<unsigned />
<autoincrement />
<field name='token' type="C" size='32' />
<field name="uID" type="I" size='10' />
<field name="validThrough" type="I" size='10' />
<index name="token">
<index name="uID">
robodev replied on at Permalink Reply
I don't have a copy of the source code in front of me, but there is a Db.xml that that installer uses when running the install script. That xml file is what builds the database, afaik.

My overall theory about what is happening here:

1) Theory One:

the PHP script is timing out due to slow database response. Those reporting that it worked after they tried a few times, or it fails at different points in the process....that sounds like the database is laggy.

There are some PHP session timeout parameters...not sure if these are implemented in the PHP scripts themselves or as a configuration setting (e.g. PHP.ini). Thus if the script is timing out, that can be fixed via PHP session timeout settings.

1A) Theory 1A:

The underlying issue could be related to the version of PHP, the PHP.ini settings, etc., as those may affect how well the server deals with errors and so forth.

2) Theory 2:

For whatever reason, the table or index that is created as part of the install is in the database somewhere unexpected, therefore somehow that is missed when getting rid of the database and/or adding a second intance of C5 to the same server.

As a user myself who makes errors, I never want to point to user error as the likely cause, as people do not like that, however if that this is the root cause, we need to determine that it is.

As I mentioned earlier, I did note that the most common failure point in the install seems to be with respect to the fslTypeHandle database attribute.

Since this column is the key to the FileStorageLocationTypes table, it needs to be unique, however a script that runs a second time and tries to set a unique value for that attribute will fail, as it is already set. This would be an error in the install script.

The 'hack' would be to comment out where the install tries to set that value and see if it completes or not. (However I would advise against hacking into the installer unless your life depends on it, you have a good backup, good insurance, etc. etc.)
IGotNothin replied on at Permalink Reply
Just a minor update. I just tried with 7.3 and I get similar results.
AndyJ replied on at Permalink Reply
you are using a new database each time. Is it differently named or are you creating a new one each time with a new name and changing the config file to point at the newly created database?
IGotNothin replied on at Permalink Reply
I'm creating a new database using a different name than the first one. Then in the install process I specify that new database name. It successfully connects and creates tables, it just eventually errors out at different points. As an illustration:

Site 1 - database = concrete_site1, web site =, site code = d:\site1\
- Install ran fine, site works.

Site 2 - database = concrete_site2, web site =, site code = d:\site2\
- Install makes it part way through, then errors on some database conflict.

Both are on the same mysql and iis instances, otherwise they are completely separate code and database locations.

I'd be curious to hear if anyone has successfully done this. If so, maybe we could determine a difference in environments that might be the cause.
Falconova replied on at Permalink Reply
I use the same database after i have deleted all files in it. The host i use not allowe me to make new databases. But HOW could concrete recognice that it have been installed before in that database when all files is deleted, and deletet all concrete files before sendig the complete concretefiles to server again? Is there a cookie somewere that recognice that?? The strange is - if i install with "empty site" and not choose "full site" - The install prosedure goes perfect. All the errors come if i try install with "full site".
But when i use empty site and begin work in it, and add more pages. The menu on top be vertical and not horisontal, and there is no way to get it horisontal.
slyskawa replied on at Permalink Reply
I am having the same problem when installing I reported the problem on IRC but didn't get any response there either. Here is where I posted my error:

I create a brand new database with a different username and password and I install it into a brand new directory. It creates 245 tables in the database and populates a lot of the tables. I ended up installing 5.6 using a new database, directory, etc. and it worked okay.

I didn't realize that it would work if you use a blank template, that may work for me. I'm installing this for my church so using a paid hosting site is not an option.
AndyJ replied on at Permalink Reply
also windows? What platform are you installing on?
slyskawa replied on at Permalink Reply
shared hosting site dreamhost using Linux.
slyskawa replied on at Permalink Reply
More information. This hosting provider has its database on a different server then localhost (they use separate servers for web and database). I tried install to a different domain on the same servers and it failed there. I'm beginning to suspect that the creation and populating of the database is timing out and the installer is not recovering properly, that is, it is trying the same insert operation again. I was trying to install today and the database server seemed slow (based on what I was seeing when I was dropping the tables in the database).

Installing using the empty site did not work for me also. I can get it to fail 100% of the time right now.
IGotNothin replied on at Permalink Reply
I think you're on to something there. I just freed up some resources on my server, then reran the install using a browser on the server itself and monitored resources. This time it actually ran all the way through successfully. I noticed the memory usage stopped at a certain percentage and never went higher which makes me think mysql is using all it can, but has some limit I need to adjust. So that could have caused a timeout or something as you suggest. Don't know if the folks at concrete could account for that somehow in their install code. Good luck with getting your install complete!
robodev replied on at Permalink Reply
That makes perfect sense, the php script does not receive quick enough response from database, and it assumes the request failed.

Provided that the correct change was made to the database, then what I would be tempted to do is start hacking into the installer to allow it to jump past the failure points.

Not sure if it's possible to code in a 'Press OK to retry' statement in there somewhere?