In the last days I moved a Magento installation over a new staging server and a new production server. Everything went well on the production server, where the site is back againg, but I'm not able to make it work on the staging server... It keeps saying that the table "admin_assert" is already present (mysql error) and the error comes from the install script... but I don't want another install.
How's it possible that magento is trying to perform an installation over another preconfigured base?
I moved the whole base (source code), without performing a clean install, then I dumped the DB and changed the base urls.
Do you have any idea?
FYI this is the whole error log:
a:5:{i:0;s:193:"Error in file: "/home/lex/code/mycommerce/app/code/core/Mage/Admin/sql/admin_setup/install-1.6.0.0.php" - SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'admin_assert' already exists";i:1;s:920:"#0 /home/lex/code/mycommerce/app/code/core/Mage/Core/Model/Resource/Setup.php(645): Mage::exception('Mage_Core', 'Error in file: ...')
#1 /home/lex/code/mycommerce/app/code/core/Mage/Core/Model/Resource/Setup.php(421): Mage_Core_Model_Resource_Setup->_modifyResourceDb('install', '', '1.6.1.0')
#2 /home/lex/code/mycommerce/app/code/core/Mage/Core/Model/Resource/Setup.php(327): Mage_Core_Model_Resource_Setup->_installResourceDb('1.6.1.0')
#3 /home/lex/code/mycommerce/app/code/core/Mage/Core/Model/Resource/Setup.php(235): Mage_Core_Model_Resource_Setup->applyUpdates()
#4 /home/lex/code/mycommerce/app/code/core/Mage/Core/Model/App.php(412): Mage_Core_Model_Resource_Setup::applyAllUpdates()
#5 /home/lex/code/mycommerce/app/code/core/Mage/Core/Model/App.php(338): Mage_Core_Model_App->_initModules()
#6 /home/lex/code/mycommerce/app/Mage.php(640): Mage_Core_Model_App->run(Array)
#7 /home/lex/code/mycommerce/index.php(90): Mage::run('', 'store')
#8 {main}";s:3:"url";s:1:"/";s:11:"script_name";s:10:"/index.php";s:4:"skin";s:7:"default";}
Not a big deal. You will find many more errors like this.
The error simple says your DB already has table name admin_assert.
You can ignore this by opening the install script and comment out the code which tries to re-create the table, and refresh the magento again.
Once everything is set up properly, don't forget to uncomment the commented create table script.
I ran into this issue as well with a rather large database and it turned out that PHPMyAdmin was unable to export the entire thing at the same time, so my data was incomplete. The solution in my case was to export tables in batches instead of all at once, and then import them in the same way.
tl;dr
Make sure that your databases match
Related
I have this site that runs Magento. The index.php file outputs a list of emails and encrypted stuff that seems to be a passwords.
I have marked out with red sensible information.
-All URLs give internal server error 500
-I have done the step by step verification recommended by a lot of sites, like this one:[https://techjam.gr/2012/magento/solve-magento-500-internal-server-errors/][2] but it has not solved the issue at all.
The error message I found at /var/report was the following: I cant really understand what it means.
a:5:{i:0;s:45:
"Mage registry key "controller" already exists"
;i:1;s:631:"
#0 /home/filomena/public_html/app/Mage.php(223): Mage::throwException('Mage registry k...')
#1 /home/filomena/public_html/app/code/core/Mage/Core/Model/App.php(747): Mage::register('controller', Object(Mage_Core_Controller_Varien_Front))
#2 /home/filomena/public_html/app/code/core/Mage/Core/Model/App.php(1094): Mage_Core_Model_App->_initFrontController()
#3 /home/filomena/public_html/app/code/core/Mage/Core/Model/App.php(354): Mage_Core_Model_App->getFrontController()
#4 /home/filomena/public_html/app/Mage.php(684): Mage_Core_Model_App->run(Array)
#5 /home/filomena/public_html/index.php(87): Mage::run('', 'store')
#6 {main}"
;s:3:"url";s:1:"/";s:11:"script_name";s:10:"/index.php";s:4:"skin";s:7:"default";}
I cant open the admin panel ,also I get internal server error 500
I wonder if there is a guide to recover from this kind of issues.
Have I been hacked?
Try to flush whole Magento cache. If you use Redis, connect to server via SSH, then:
redis-cli
flushall
exit
If no, remove all files and directories from: magento_root_dir/var/cache
Today I tried to access localhost/magento and the page would not load. Then, I just tried using localhost/phpmyadmin and the same thing. I read somewhere that the default port could be in use and cause this issue, so I changed the listener to 100 and localhost:100/phpmyadmin worked. Now, Magento gets an error every time I try to access it.
I've tried changing the web/unsecure/base_url and web/secure/base_url tables to http://localhost:100/magento/ and manually deleting my var/cache folder contents... still no luck.
Is there something I'm missing or an extra step I need to do with magento?
By the way I have it installed on XAMPP with windows 7 64-bit. Everything was working fine the day before.
edit: error codes
Module "Practice_OneStepCheckout" requires module "Mage_CatalogInventorty".
Trace:
#0 C:\xampp\htdocs\magento\app\code\core\Mage\Core\Model\Config.php(849): Mage::throwException('Module "Practic...')
#1 C:\xampp\htdocs\magento\app\code\core\Mage\Core\Model\Config.php(812): Mage_Core_Model_Config->_sortModuleDepends(Array)
#2 C:\xampp\htdocs\magento\app\code\core\Mage\Core\Model\Config.php(315): Mage_Core_Model_Config->_loadDeclaredModules()
#3 C:\xampp\htdocs\magento\app\code\core\Mage\Core\Model\App.php(414): Mage_Core_Model_Config->loadModules()
#4 C:\xampp\htdocs\magento\app\code\core\Mage\Core\Model\App.php(343): Mage_Core_Model_App->_initModules()
#5 C:\xampp\htdocs\magento\app\Mage.php(684): Mage_Core_Model_App->run(Array)
#6 C:\xampp\htdocs\magento\index.php(87): Mage::run('', 'store')
#7 {main}
Thanks in advance for your help!
Is there something I'm missing or an extra step I need to do with magento?
Nope, it should work out of the box. What is the error you get?
I can recommend to use vhosts, that wil save you allot of time in the future: http://butlerccwebdev.net/support/testingserver/vhosts-setup-win.html
(Also, the most common port 80 issue under windows/xampp users is TeamViewer)
I have installed magento 1.9 CE on my local server and it was working fine. Suddenly it stopped working and shows error like
There has been an Error processing your request.
When I check error report from report folder then I got logs like
a:5:{i:0;s:219:"Error in file: "C:\wamp\www\anzonline\app\code\core\Mage\XmlConnect\sql\xmlconnect_setup\upgrade-1.6.0.0-1.6.0.0.1.php" - SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'xmlconnect_images' already exists";i:1;s:950:"
#0 C:\wamp\www\anzonline\app\code\core\Mage\Core\Model\Resource\Setup.php(645): Mage::exception('Mage_Core', 'Error in file: ...')
#1 C:\wamp\www\anzonline\app\code\core\Mage\Core\Model\Resource\Setup.php(437): Mage_Core_Model_Resource_Setup->_modifyResourceDb('upgrade', '1.6.0.0', '1.6.0.0.1')
#2 C:\wamp\www\anzonline\app\code\core\Mage\Core\Model\Resource\Setup.php(320): Mage_Core_Model_Resource_Setup->_upgradeResourceDb('1.6.0.0', '1.6.0.0.1')
#3 C:\wamp\www\anzonline\app\code\core\Mage\Core\Model\Resource\Setup.php(235): Mage_Core_Model_Resource_Setup->applyUpdates()
#4 C:\wamp\www\anzonline\app\code\core\Mage\Core\Model\App.php(417): Mage_Core_Model_Resource_Setup::applyAllUpdates()
#5 C:\wamp\www\anzonline\app\code\core\Mage\Core\Model\App.php(343): Mage_Core_Model_App->_initModules()
#6 C:\wamp\www\anzonline\app\Mage.php(684): Mage_Core_Model_App->run(Array)
#7 C:\wamp\www\anzonline\index.php(87): Mage::run('', 'store')
#8 {main}";s:3:"url";s:11:"/anzonline/";s:11:"script_name";s:20:"/anzonline/index.php";s:4:"skin";s:7:"default";}
I have found several solutions from Google but none of those worked out for me example.
The error message is telling you that Magento tries to create a table which already exists. This takes place in an upgrade script and was probably caused by an incomplete previous run of said upgrade script. Magento executes upgrade scripts, but only marks them done when they complete without error. Even an incompletely run script can have created tables, though, and next time Magento tries to run that update script the exstance of those tables cause a problem.
So you can either do some Database work and do some tweeking like removing the tables in question (with saving the data if needed), or you redo your Magento Installation.
This can also be caused by recently installed extensions, if so uninstalling them with the Connect Manager and reinstalling them might work.
Use
DROP TABLE IF EXISTS xmlconnect_images;
then, refresh your brownser. It works for me.
You can clear cache if you dont see any changes:
To clear the cache, simply delete everything from the /var/cache directory and then reload your website in your browser.
rm -rf magento/var/cache/*
To clear all sessions, you can also delete everything from the /var/session folder within your Magento installation directory.
rm -rf magento/var/session/*
I have recently caught wind of the inherent Zend problem that Magento is built upon. I took that initiative to upgrade my sites from 1.6.2 to the newest 1.7.0.2 to resolve that problem. All my sites upgraded beautifully except 1. All the files are up to date on the server now, but when I try to access my site and it runs the upgrades, I get the below report saved in my reports folder without access to my site.
a:5:{i:0;s:216:"Error in file: "/home/xxxxx/public_html/app/code/core/Mage/Sales/data/sales_setup/data-upgrade-1.6.0.4-1.6.0.5.php" - SQLSTATE[42S22]: Column not found: 1054 Unknown column 'main.base_tax_refunded' in 'field list'";i:1;s:883:"#0 /home/xxxxx/public_html/app/code/core/Mage/Core/Model/Resource/Setup.php(645): Mage::exception('Mage_Core', 'Error in file: ...')
#1 /home/xxxxxx/public_html/app/code/core/Mage/Core/Model/Resource/Setup.php(407): Mage_Core_Model_Resource_Setup->_modifyResourceDb('data-upgrade', '1.6.0.4', '1.6.0.7')
#2 /home/xxxxxx/public_html/app/code/core/Mage/Core/Model/Resource/Setup.php(286): Mage_Core_Model_Resource_Setup->_upgradeData('1.6.0.4', '1.6.0.7')
#3 /home/xxxxxx/public_html/app/code/core/Mage/Core/Model/Resource/Setup.php(269): Mage_Core_Model_Resource_Setup->applyDataUpdates()
#4 /home/xxxxxx/public_html/app/code/core/Mage/Core/Model/App.php(351): Mage_Core_Model_Resource_Setup::applyAllDataUpdates()
#5 /home/xxxxxx/public_html/app/Mage.php(683): Mage_Core_Model_App->run(Array)
#6 /home/xxxxxx/public_html/index.php(87): Mage::run('', 'store')
#7 {main}";s:3:"url";s:1:"/";s:11:"script_name";s:10:"/index.php";s:4:"skin";s:7:"default";}
Or if I try to upgraded via the downloader I get:
Exception during cache and session cleaning: Error in file: "/home/xxxxxx/public_html/app/code/core/Mage/Sales/data/sales_setup/data-upgrade-1.6.0.4-1.6.0.5.php" - SQLSTATE[42S22]: Column not found: 1054 Unknown column 'main.base_tax_refunded' in 'field list'
This is a problem I have yet to run into with my many moons of administering magento. Lookin into the code for that php, everything seems standard, and matches the other sites i have installed the upgrade on.
Anyone run into such an issue?
Ben, I've upgraded four Magento stores now to 1.7.0.2 from 1.5.1.0 and 1.6.2.0. Not exactly the same problem, but two had some form of missing table (one was a captcha_log, the other was sales_order_tax_item. Once I created the 'missing' table each installation was fine. Not sure why they were or went missing. Might you just add the missing column or replace the table with a correct version? base_tax_refunded is in the sales_flat_order table.
My problem is solved.
Turns out my index.php file was set to 666. Ran a chmod to change it to 755 and all is well again!
I've had the same problem but the field was in my main orders table and changing permissions of files had no effect, so eventually after looking at the files that was given the errors more closely (i.e. data-upgrade-1.6.0.4-1.6.0.5.php) I added following columns to the following tables and at last I can get back into my admin panel.
Columns Added: base_tax_refunded,discount_refunded,base_discount_refunded
to Tables: sale_flat_creditmemo,sales_flat_creditmemo_item,sales_flat_order_item
Surely this kind of thing would be done automatically by the upgrade scripts? unless I missed some step...
I've been trying now for a few hours to move our Magento installation from dev to live. I found multiple links on the web saying that to move a Magento Installation you need to edit /app/etc/local.xml and update it with the new MySQL credentials and then delete the contents of /var/cache/ (a few even suggested deleting the whole /var folder. I also deleted the contents of /var/session/. Our server is NOT cached (no memcached, varnish, etc). I even restarted apache to see if I could flush any cache that might be running.
So the problem is our Magento installation is still attempting to connect to the old database somehow. We are given this error:
SQLSTATE[28000] [1045] Access denied for user 'oldDBUsername'#'localhost' (using password: YES)
If anyone has any ideas on how to fix this that I haven't already mentioned it would be greatly appreciated.
EDIT:
Here is the stack trace that Magento also reports:
Trace:
#0 fileroot/lib/Zend/Db/Adapter/Pdo/Mysql.php(96): Zend_Db_Adapter_Pdo_Abstract->_connect()
#1 fileroot/lib/Varien/Db/Adapter/Pdo/Mysql.php(300): Zend_Db_Adapter_Pdo_Mysql->_connect()
#2 fileroot/lib/Zend/Db/Adapter/Abstract.php(459): Varien_Db_Adapter_Pdo_Mysql->_connect()
#3 fileroot/lib/Zend/Db/Adapter/Pdo/Abstract.php(238): Zend_Db_Adapter_Abstract->query('SET NAMES utf8', Array)
#4 fileroot/lib/Varien/Db/Adapter/Pdo/Mysql.php(389): Zend_Db_Adapter_Pdo_Abstract->query('SET NAMES utf8', Array)
#5 fileroot/app/code/core/Mage/Core/Model/Resource.php(169): Varien_Db_Adapter_Pdo_Mysql->query('SET NAMES utf8')
#6 fileroot/app/code/core/Mage/Core/Model/Resource.php(110): Mage_Core_Model_Resource->_newConnection('pdo_mysql', Object(Mage_Core_Model_Config_Element))
#7 fileroot/app/code/core/Mage/Core/Model/Resource/Db/Abstract.php(320): Mage_Core_Model_Resource->getConnection('core_read')
#8 fileroot/app/code/core/Mage/Core/Model/Resource/Db/Abstract.php(335): Mage_Core_Model_Resource_Db_Abstract->_getConnection('read')
#9 fileroot/app/code/core/Mage/Core/Model/Resource/Cache.php(53): Mage_Core_Model_Resource_Db_Abstract->_getReadAdapter()
#10 fileroot/app/code/core/Mage/Core/Model/Cache.php(449): Mage_Core_Model_Resource_Cache->getAllOptions()
#11 fileroot/app/code/core/Mage/Core/Model/Cache.php(491): Mage_Core_Model_Cache->_initOptions()
#12 fileroot/app/code/core/Mage/Core/Model/App.php(1175): Mage_Core_Model_Cache->canUse('config')
#13 fileroot/app/code/core/Mage/Core/Model/Config.php(414): Mage_Core_Model_App->useCache('config')
#14 fileroot/app/code/core/Mage/Core/Model/Config.php(294): Mage_Core_Model_Config->_canUseCacheForInit()
#15 fileroot/app/code/core/Mage/Core/Model/App.php(408): Mage_Core_Model_Config->loadModulesCache()
#16 fileroot/app/code/core/Mage/Core/Model/App.php(338): Mage_Core_Model_App->_initModules()
#17 fileroot/app/Mage.php(640): Mage_Core_Model_App->run(Array)
#18 fileroot/index.php(80): Mage::run('', 'store')
#19 {main}
I figured it out.
When I brought over the dev installation to live I had copied local.xml to local_bk.xml I discovered that Magento will attempt to autoload ALL xml files in the /app/etc/ folder so it was trying to load my backed up file, soon as I renamed my backup to something that didn't end in .xml it worked.
When you install magento you have to select whether cache and session data is stored on the file system or db.
It may be the following line in local.xml, cant quite remember right now.
<session_save><![CDATA[files]]></session_save>
if you are using the db then it stores data in the core_cache table maybe in the database.
See if your db cache tables are empty if they are not truncate them.
You will also need to update your base url both secure and unsecure in core_config_data
see the following for SQL to do the update
http://www.magentocommerce.com/wiki/1_-_installation_and_configuration/update_site_url_in_core_config_data
The correct path is
app/etc/local.xml
instead of:
etc/app/local.xml
Does this solve your issue?
For others having this issue in the future here is some documentation on Magento's wiki. http://www.magentocommerce.com/wiki/groups/227/moving_magento_to_another_server
Your answer saved me! I spent a lot of time on this issue and only stumbled on this answer. I usually copy and paste to search for the error, so I wanted to give more of the actual error so that others could benefit.
I named my local.xml file to local.bak and that's where my mistake was. Comparison against all files of a working Magento instance yielded only the extra file.
The error led me to believe that maybe mySQL was the issue but it had nothing to do with it. Perhaps someone might be able to post a log or method that shows what file is actually being used. I didn't see any notice written to any log.
Here is more of the error, excluding anything site specific:
"SQLSTATE[HY000] [1045] Access denied for user '*myuser*'#'localhost' (using password: YES) /lib/Zend/Db/Adapter/Pdo/Mysql.php(111): Zend_Db_Adapter_Pdo_Abstract->_connect()
Also changing my file names in app/etc/ removing the .xml in the middle worked for me:
local.xml.template to local.template and local.xml.additional
to local.additional
Thanks #Peter.
Within your magento folder you need to edit app/etc/local.xml as Gershon mentioned.
You will also as root or sudo need to remove all files and directories in your magento folder's var/cache that magento creates.