So, I'm upgrading a Magento install from 1.3.2.1 to 1.7.0.2. But I get the following error when I try to convert the database to the new format.
a:5:{i:0;s:239:"Error in file: "/home/user/public_html/app/code/core/Mage/Customer/sql/customer_setup/mysql4-upgrade-1.4.0.0.7-1.4.0.0.8.php" - SQLSTATE[HY000]: General error: 1005 Can't create table 'user_new.customer_form_attribute' (errno: 150)";i:1;s:994:"#0 /home/user/public_html/app/code/core/Mage/Core/Model/Resource/Setup.php(645): Mage::exception('Mage_Core', 'Error in file: ...')
#1 /home/user/public_html/app/code/core/Mage/Core/Model/Resource/Setup.php(437): Mage_Core_Model_Resource_Setup->_modifyResourceDb('upgrade', '1.4.0.0.7', '1.6.2.0.1')
#2 /home/user/public_html/app/code/core/Mage/Core/Model/Resource/Setup.php(320): Mage_Core_Model_Resource_Setup->_upgradeResourceDb('1.4.0.0.7', '1.6.2.0.1')
#3 /home/user/public_html/app/code/core/Mage/Core/Model/Resource/Setup.php(235): Mage_Core_Model_Resource_Setup->applyUpdates()
#4 /home/user/public_html/app/code/core/Mage/Core/Model/App.php(417): Mage_Core_Model_Resource_Setup::applyAllUpdates()
#5 /home/user/public_html/app/code/core/Mage/Core/Model/App.php(343): Mage_Core_Model_App->_initModules()
#6 /home/user/public_html/app/Mage.php(683): Mage_Core_Model_App->run(Array)
#7 /home/user/public_html/index.php(87): Mage::run('', 'store')
#8 {main}";s:3:"url";s:1:"/";s:11:"script_name";s:10:"/index.php";s:4:"skin";s:7:"default";}
Anybody who have fixed this problem? Google don't give me any answers only people who have the same problem.
The tables in Magento 1.3 are MyISAM and later are converted to InnoDB. Now the 150 error message you are getting is related to FKs:
If MySQL reports an error number 1005 from a CREATE TABLE statement,
and the error message refers to error 150, table creation failed
because a foreign key constraint was not correctly formed. Similarly,
if an ALTER TABLE fails and it refers to error 150, that means a
foreign key definition would be incorrectly formed for the altered
table. To display a detailed explanation of the most recent InnoDB
foreign key error in the server, issue SHOW ENGINE INNODB STATUS.
Source
It is a long way to upgrade Magento from 1.3.2.1 to 1.7.0.2. Errors are almost always happen. You didn't mentioned the way how you plan to upgrade, it plays a vital role in this question. Definitely, it is safer to move step by step 1.3 to 1.4 to 1.5 to 1.6 to 1.7.
Have you made a backup for you data? If yes, it is better to start it all from the very beginning.
Minor problems here are inevitable, especially, if you have really old version
of Magento that you would like to upgrade.
Here is the standard procedure when getting Magento up to date. It is just for you to see, because you can select another way to update the store.
1) Know what are you facing with:
Check google if there is something special about upgrading your specific version of Magento to the newest one.
If nothing else, you will be prepared with issues that you will need to solve.
2) Backup your files
We usually do it from CLI like this:
tar -cvvzf your_site_directory.tar.gz your_site_directory/ 2>error.log
3) Backup your database
You can also do it from CLI like this:
mysqldump -u THIS_IS_YOUR_USERNAME_FOR_DB -h localhost -pTHIS_IS_YOUR_USERNAME_FOR_DB my_database_name | gzip -9 > my_database_name.sql.gz
4) Copy those files to the new location
In case you need to move files between 2 servers, easiest way I can think of in CLI would be this:
scp /path_to_some_file/your_site_directory.tar.gz user#REMOTE_SERVER_ADDRESS:/some_dir_on_remote_server
You can do the same with your backup-ed database
5) Now it is time to import database into new created one:
a) Extract my_database_name.sql.gz
b) mysql –verbose –user=THIS_IS_YOUR_USERNAME –password=THIS_IS_YOUR_PASSWORD newly_created_db < my_database_name.sql
6) Now extract the files this way:
tar -xvvzf your_site_directory.tar.gz
This will extract all files to the current directory
7) Edit db table core_config_data and set new secure/unsecure URLs of your site
8) Disable cache from admin.
9) Delete cache and session directories located here:
/var/cache
/var/session
rm /your_path_to/var/session -R
rm /your_path_to/var/cache -R
10) Execute “clean” bash script located in /downloader/pearlib directory
a) Run chmod +x clean to be able to execute this script
b) ./clean to execute script
11) Finally go to Magento connect manager from your Magento admin
Paste this extension to upgrade Magento: magento-core/Mage_All_Latest
After this is done, you should have new Magento, however if there was some custom coding, you should really know what is going on with your code.
12) All that left is to test it and move those files on production server.
Related
I'm trying to follow the diesel.rs tutorial using PostgreSQL. When I get to the Diesel setup step, I get an "authentication method 10 not supported" error. How do I resolve it?
You have to upgrade the PostgreSQL client software (in this case, the libpq used by the Rust driver) to a later version that supports the scram-sha-256 authentication method introduced in PostgreSQL v10.
Downgrading password_encryption in PostgreSQL to md5, changing all the passwords and using the md5 authentication method is a possible, but bad alternative. It is more effort, and you get worse security and old, buggy software.
This isn't a Rust-specific question; the issue applies to any application connecting to a Postgres DB that doesn't support the scram-sha-256 authentication method. In my case it was a problem with the Perl application connecting to Postgres.
These steps are based on a post.
You need to have installed the latest Postgres client.
The client bin directory (SRC) is "C:\Program Files\PostgreSQL\13\bin" in this example. The target (TRG) directory is where my application binary is installed: "C:\Strawberry\c\bin". My application failed during an attempt to connect the Postgres DB with error "... authentication method 10 not supported ...".
set SRC=C:\Program Files\PostgreSQL\13\bin
set TRG=C:\Strawberry\c\bin
dir "%SRC%\libpq.dll" # to see the source DLL
dir "%TRG%\libpq__.dll" # to see the target DLL. Will be replaced from SRC
cp "%SRC%\libpq.dll" %TRG%\.
cd %TRG%
pexports libpq.dll > libpq.def
dlltool --dllname libpq.dll --def libpq.def --output-lib ..\lib\libpq.a
move "%TRG%"\libpq__.dll "%TRG%"\libpq__.dll_BUP # rename ORIGINAL name to BUP
move "%TRG%"\libpq.dll "%TRG%"\libpq__.dll # rename new DLL to ORIGINAL
At this point I was able successfully connect to Postgres from my Perl script.
The initial post shown above also suggested to copy other DLLs from source to the target:
libiconv-2.dll
libcrypto-1_1-x64.dll
libssl-1_1-x64.dll
libintl-8.dll
However, I was able to resolve my issue without copying these libraries.
Downgrading to PostgreSQL 12 helped
I have a couple of DB2 Backup files as shared with us.
I am unable to recover the data using the DB2 recover command which I used as -
db2 restore db <db-name> from . taken at 20151229234633
Got the following error for the above command.
SQL2071N An error occurred while accessing the shared library
"/resgrp463/db2inst3/db2inst3/NODE0000/SQL00001/4371/libdb2compr.a".
Reason code: "2".
I then modified the Recover command and added another parameter by providing compress library option as mentioned in the following command -
db2 restore db <db-name> from <location> taken at 20151229234633 comprlib /resgrp463/db2inst1/sqllib/lib64/libdb2compr.a
It gave the error as mentioned below.
SQL2079N An error was reported by the shared library "libdb2compr.a".
Return code: "104".
Any help on how to resolve it or any concrete proof specifying that the Backup File is corrupt would be appreciated.
OS Version - AIX 7.1 TL4
DB2 Version - DB2 9.7
Fix Packs Tried - GA, 1, 11 (Target side)
At the source side, we don't know the exact Fix Pack used but the version is confirmed as DB2 9.7 using the db2ckbkp header information which provides release code as D00.
Please view the db2diag log at https://pastebin.com/X8sYELNT
Upon using the command to check the backup's, I get an error as mentioned below.
Command used -
db2ckbkp *
It gave the error as
Buffers processed: #ERROR: Decompression library not initialized
ERROR: Failed to verify media header. Cannot continue.
All three error messages are related to a db2 library which db2 restore command needs as shown at each error messages. There is a problem at db2 restore command executing machine/box, client side and not server side. And this type of situation can be occurred when:
1) db2 restore related file(s) is corrupted, such as the library file in message
2) db2 restore unexpectedly reads the library file by miss configuration
For 1), it may be fixed by:
install product again or create a new instance. this will place normal file(s).
For 2), it may be fixed by:
find out what was changed at the environment then fix. this will pick up correct library file.
For your information. End of support for V9.7 is September 30, 2017 as show below:
Recommended Fix Packs for DB2 for Linux, UNIX and Windows
https://www.ibm.com/support/pages/recommended-fix-packs-db2-linux-unix-and-windows
Hope this helps.
I am unable to complete Moodle installation. I am hosting the site on NearlyFreeSpeech and using PHP 5.6. Moodle doesnt seem to be able to connect to the database and write any tables.
I created the moodledata folder in /protected/moodledata and moodle is in /public/moodle
I receive this error after accepting the terms and conditions.
Error reading from database
More information about this error
It is usually not possible to recover from errors triggered during installation, you may need to create a new database or use a different database prefix if you want to retry the installation.
Normally my first instinct would point to the config.php file but if it's getting as far as telling you that a connection is established with the database but there's a read error ("Error reading from database"), then that generally means your config.php file is probably healthy, but your database is not.
Firstly, check that you're using one of the following database servers that Moodle is compatible with (minimum version)
PostgreSQL 9.1
MySQL 5.5.31
MariaDB 5.5.31
Microsoft SQL Server 2008
Oracle Database 10.2
source.
Secondly, ensure that the user assigned to access your database in config.php has ALL PRIVILEGES set on that database.
Moving on... If this is a fresh install and you have no data to lose, your best bet is to start with a clean database.
You can either delete your existing database and set up a new one, or you can drop all tables from your existing database.
Option 1. Delete your existing database.
Delete your config.php file
Jump to phpMyAdmin (from the 'actions' tab on the MySQL process page)
Click on "Databases"
Delete your existing database
Hit "Create database" to generate a fresh, empty database
Go to http://your.url/install.php and follow the instructions for a fresh install.
Option 2. Clear your existing database
Jump to phpMyAdmin and run the following query:
DECLARE #sql NVARCHAR(max)=''
SELECT #sql += ' Drop table '+TABLE_SCHEMA+'.'+ TABLE_NAME
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_TYPE = 'BASE TABLE'
Exec Sp_executesql #sql
source.
Then go to http://your.url/install.php and follow the instructions for a fresh install.
If you managed to start with a fresh database and you get the same error, please ensure that you have all the prerequisites available from your host. You can find a list of Moodle PHP requirements here.
The only time I've seen that error is when using the wrong MySQL version. Eg currently MySQL 5.5 is supported but if you have 5.1 you would get that error.
Source: http://realtechtalk.com/moodle_install_error_Error_reading_from_database_-2072-articles
I get this exception in PostgreSQL:
org.postgresql.util.PSQLException: ERROR: could not access file "$libdir/plpgsql": No such file or directory
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1721)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1489)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:193)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:452)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:337)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:236)
at org.apache.commons.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:205)
I searched a lot and most solution points to a wrong installation. But this is my test db which has been running without issues for a long time. Also inserts are working. Issue occurs only on select queries.
Apparently, you moved your PostgreSQL lib directory out of place. To confirm this, try the following in psql:
> SET client_encoding TO iso88591;
ERROR: could not access file "$libdir/utf8_and_iso8859_1": No such file or directory
If you get an error message like this, then my theory is correct. You'll need to find out where those files ended up, or you can reinstall PostgreSQL to restore them.
To find out what $libdir is referring to, run the following command:
pg_config --pkglibdir
For me, this produces:
/usr/lib/postgresql
I have the same problem: the other postgres server instance (8.4) was interfering with the 9.1 one; when the 8.4 instance is removed it works.
the other instance can sometimes be removed from the system while still running (e.g. you do a gentoo update and a depclean without stopping and migrating your data). so the error seems particularly mysterious.
the solution is usually going to be doing a slot install/eselect of the old version (in gentoo terms, or simply downgrading on other distros), running its pg_dumpall, and then uninstalling/reinstalling the new version and importing the data.
this worked pretty painlessly for me
I have a database file (*.db) that need to be recovered.
The bad is, the end-user have null idea of the version of the database. Not know the password. The original developer is lost. The computer where was installed was formatted. We have not experience in this database software. Yeah, nightmare.
My guess is a old database. I'm trying to open it in Sybase 11, dev edition.
I follow this steps: http://dcx.sybase.com/1101en/sachanges_en11/unloading-reloading-upgrading-newjasper.html
I try to use the UNLOAD utility from command line & from the Sybase central utility. From command line I do:
./dbinfo -c "DBF=/Users/mamcx/Downloads/CEMDE_ENDOCRINO_S.A.DB;UID=DBA;PWD=sql"
SQL Anywhere Information Utility Version 11.0.1.2045
Unable to start specified database: '/Users/mamcx/Downloads/CEMDE_ENDOCRINO_S.A.DB' was created by a different version of the software
Ok, I try to unload:
./dbunload -c "DBF=/Users/mamcx/Downloads/CEMDE_ENDOCRINO_S.A.DB;UID=DBA;PWD=sql" -n /Users/mamcx/Desktop/
SQL Anywhere Unload Utility Version 11.0.1.2045
Connecting and initializing
***** SQL error: Unable to start database server
Ok, from the server admin tool:
dbunload -v -c "UID=dba;PWD=***;DBF=/Users/mamcx/Downloads/CEMDE_ENDOCRINO_S.A.DB" -an "/Users/mamcx/Desktop/baba.db" -ap 4096 -ea None -ii -sa -so _sc866192545
Connecting and initializing
***** SQL error: Unable to start database server
An error occurred while attempting to unload the database '/Users/mamcx/Downloads/CEMDE_ENDOCRINO_S.A.DB'.
Exist a way to know the version of the database server used to create this? Is possible to recover this file?
I don't know how to get the version out of the Database File if you are not able to start it.
You could get a hint from the hopefully existing Client PC's. Check the ODBC Driver Version they have installed.
I had good success with the support of Sybase. If you or your client has a support contract you can get them involved.
HTH
Try to simply start a server with that database and capture the output with -z -o server.out. The server.out file should contain a more specific error telling you why it can't start the database. This error can occur if you are trying to start something that is not a SQL Anywhere database.
You may also want to post this question over at http://sqlanywhere-forum.sap.com/.