Error when install for the second time in the same server
Permalink
Hi.
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
Version 5.7.2.1
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'.
Trace:
#0 /customers/6/4/f/goto-norway.no/httpd.www/concrete/vendor/doctrine/dbal/lib/Doctrine/DBAL/Statement.php(167): Doctrine\DBAL\DBALException::driverExceptionDuringQuery(Object(PDOException), 'INSERT INTO Fil...', Array) #1 /customers/6/4/f/goto-norway.no/httpd.www/concrete/vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php(279): Doctrine\DBAL\Statement->execute() #2 /customers/6/4/f/goto-norway.no/httpd.www/concrete/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php(966): Doctrine\ORM\Persisters\BasicEntityPersister->executeInserts() #3 /customers/6/4/f/goto-norway.no/httpd.www/concrete/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php(335): Doctrine\ORM\UnitOfWork->executeInserts(Object(Doctrine\ORM\Mapping\ClassMetadata)) #4 /customers/6/4/f/goto-norway.no/httpd.www/concrete/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php(389): Doctrine\ORM\UnitOfWork->commit(NULL) #5 /customers/6/4/f/goto-norway.no/httpd.www/concrete/src/File/StorageLocation/Type/Type.php(93): Doctrine\ORM\EntityManager->flush() #6 /customers/6/4/f/goto-norway.no/httpd.www/concrete/src/Package/StartingPointPackage.php(149): Concrete\Core\File\StorageLocation\Type\Type::add('default', 'Default') #7 [internal function]: Concrete\Core\Package\StartingPointPackage->import_files() #8 /customers/6/4/f/goto-norway.no/httpd.www/concrete/controllers/install.php(282): call_user_func(Array) #9 [internal function]: Concrete\Controller\Install->run_routine('elemental_full', 'import_files') #10 /customers/6/4/f/goto-norway.no/httpd.www/concrete/src/Controller/AbstractController.php(156): call_user_func_array(Array, Array) #11 /customers/6/4/f/goto-norway.no/httpd.www/concrete/src/Routing/ControllerRouteCallback.php(25): Concrete\Core\Controller\AbstractController->runAction('run_routine', Array) #12 /customers/6/4/f/goto-norway.no/httpd.www/concrete/src/Routing/Router.php(59): Concrete\Core\Routing\ControllerRouteCallback->execute(Object(Concrete\Core\Http\Request), Object(Concrete\Core\Routing\Route), Array) #13 /customers/6/4/f/goto-norway.no/httpd.www/concrete/src/Support/Facade/Facade.php(116): Concrete\Core\Routing\Router->execute(Object(Concrete\Core\Routing\Route), Array) #14 /customers/6/4/f/goto-norway.no/httpd.www/concrete/src/Application/Application.php(340): Concrete\Core\Support\Facade\Facade::__callStatic('execute', Array) #15 /customers/6/4/f/goto-norway.no/httpd.www/concrete/src/Application/Application.php(340): Concrete\Core\Support\Facade\Route::execute(Object(Concrete\Core\Routing\Route), Array) #16 /customers/6/4/f/goto-norway.no/httpd.www/concrete/bootstrap/start.php(196): Concrete\Core\Application\Application->dispatch(Object(Concrete\Core\Http\Request)) #17 /customers/6/4/f/goto-norway.no/httpd.www/concrete/dispatcher.php(36): require('/customers/6/4/...') #18 /customers/6/4/f/goto-norway.no/httpd.www/index.php(2): require('/customers/6/4/...') #19 {main}
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
Version 5.7.2.1
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'.
Trace:
#0 /customers/6/4/f/goto-norway.no/httpd.www/concrete/vendor/doctrine/dbal/lib/Doctrine/DBAL/Statement.php(167): Doctrine\DBAL\DBALException::driverExceptionDuringQuery(Object(PDOException), 'INSERT INTO Fil...', Array) #1 /customers/6/4/f/goto-norway.no/httpd.www/concrete/vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php(279): Doctrine\DBAL\Statement->execute() #2 /customers/6/4/f/goto-norway.no/httpd.www/concrete/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php(966): Doctrine\ORM\Persisters\BasicEntityPersister->executeInserts() #3 /customers/6/4/f/goto-norway.no/httpd.www/concrete/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php(335): Doctrine\ORM\UnitOfWork->executeInserts(Object(Doctrine\ORM\Mapping\ClassMetadata)) #4 /customers/6/4/f/goto-norway.no/httpd.www/concrete/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php(389): Doctrine\ORM\UnitOfWork->commit(NULL) #5 /customers/6/4/f/goto-norway.no/httpd.www/concrete/src/File/StorageLocation/Type/Type.php(93): Doctrine\ORM\EntityManager->flush() #6 /customers/6/4/f/goto-norway.no/httpd.www/concrete/src/Package/StartingPointPackage.php(149): Concrete\Core\File\StorageLocation\Type\Type::add('default', 'Default') #7 [internal function]: Concrete\Core\Package\StartingPointPackage->import_files() #8 /customers/6/4/f/goto-norway.no/httpd.www/concrete/controllers/install.php(282): call_user_func(Array) #9 [internal function]: Concrete\Controller\Install->run_routine('elemental_full', 'import_files') #10 /customers/6/4/f/goto-norway.no/httpd.www/concrete/src/Controller/AbstractController.php(156): call_user_func_array(Array, Array) #11 /customers/6/4/f/goto-norway.no/httpd.www/concrete/src/Routing/ControllerRouteCallback.php(25): Concrete\Core\Controller\AbstractController->runAction('run_routine', Array) #12 /customers/6/4/f/goto-norway.no/httpd.www/concrete/src/Routing/Router.php(59): Concrete\Core\Routing\ControllerRouteCallback->execute(Object(Concrete\Core\Http\Request), Object(Concrete\Core\Routing\Route), Array) #13 /customers/6/4/f/goto-norway.no/httpd.www/concrete/src/Support/Facade/Facade.php(116): Concrete\Core\Routing\Router->execute(Object(Concrete\Core\Routing\Route), Array) #14 /customers/6/4/f/goto-norway.no/httpd.www/concrete/src/Application/Application.php(340): Concrete\Core\Support\Facade\Facade::__callStatic('execute', Array) #15 /customers/6/4/f/goto-norway.no/httpd.www/concrete/src/Application/Application.php(340): Concrete\Core\Support\Facade\Route::execute(Object(Concrete\Core\Routing\Route), Array) #16 /customers/6/4/f/goto-norway.no/httpd.www/concrete/bootstrap/start.php(196): Concrete\Core\Application\Application->dispatch(Object(Concrete\Core\Http\Request)) #17 /customers/6/4/f/goto-norway.no/httpd.www/concrete/dispatcher.php(36): require('/customers/6/4/...') #18 /customers/6/4/f/goto-norway.no/httpd.www/index.php(2): require('/customers/6/4/...') #19 {main}
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">
<unique></unique>
<col>fslTypeHandle</col>
I could be wrong, but make sure the table called 'FileStorageLocationTypes'
has something other than 'default' as the value for "fslTypeHandle" column
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">
<unique></unique>
<col>fslTypeHandle</col>
I could be wrong, but make sure the table called 'FileStorageLocationTypes'
has something other than 'default' as the value for "fslTypeHandle" column
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!
Good thought though, thanks for trying to help!
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>
<field name='token' type="C" size='32' />
<field name="uID" type="I" size='10' />
<field name="validThrough" type="I" size='10' />
<index name="token">
<UNIQUE/>
<col>token</col>
</index>
<index name="uID">
<col>uID</col>
</index>
</table>
</schema>
<?xml version="1.0"?>
<schema version="0.3">
<table name="authTypeConcreteCookieMap">
<field name="ID" type="I">
<key />
<unsigned />
<autoincrement />
</field>
<field name='token' type="C" size='32' />
<field name="uID" type="I" size='10' />
<field name="validThrough" type="I" size='10' />
<index name="token">
<UNIQUE/>
<col>token</col>
</index>
<index name="uID">
<col>uID</col>
</index>
</table>
</schema>
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.)
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.)
Just a minor update. I just tried with 7.3 and I get similar results.
hi,
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?
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?
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 = site1.example.com, site code = d:\site1\
- Install ran fine, site works.
Site 2 - database = concrete_site2, web site = site2.example.com, 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.
Site 1 - database = concrete_site1, web site = site1.example.com, site code = d:\site1\
- Install ran fine, site works.
Site 2 - database = concrete_site2, web site = site2.example.com, 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.
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.
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.
I am having the same problem when installing 5.7.2.3. I reported the problem on IRC but didn't get any response there either. Here is where I posted my error: http://laravel.io/bin/MkbxJ
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.
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.
also windows? What platform are you installing on?
shared hosting site dreamhost using Linux.
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.
Installing using the empty site did not work for me also. I can get it to fail 100% of the time right now.
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!
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?
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?
I'll post again if I find an answer.