Magento 2.2.4, PHP 7.0.30.
While running setup:upgrade command in SSH, a list of modules appear then I get:
Module 'Magento_SalesSequence':
Running data recurring...Unique constraint violation found
Then the upgrade seems to stop. How do I identify the data causing the unique constraint violation? I have checked some log files in var/logs and some tables containing "sequence" in the database using PHPMyAdmin, but there is probably a better way.
Any help appreciated.
Can run the following command php bin/magento setup:db-data:upgrade
It would be mostly the unique value issue in table "cym_sales_sequence_meta" for the field "sequence_table". You can remove the values or empty the table and run the setup upgrade again. The issue will be sorted.
Related
I am trying to restore a postgresql database backup file of power outage information sent by a work colleague and keep running into an error. They sent a file with a .backup extension and said "it should restore to the public schema of an empty postgresql database". I am using pgAdmin 4 and following the steps suggested here https://o7planning.org/11913/backup-and-restore-postgres-database-with-pgadmin to restore the database of
creating a new empty database
right clicking on the new database and clicking restore
linking to file path of backup and running
however, each time I get the error
pg_restore: error: could not execute query: ERROR: schema "outage_data" does not exist
Not sure how to solve it. Any help would be greatly appreciated!
(Not sure if it is important but I am running on Windows 10 and pgAdmin4 version 6)
Do you get more errors after that? This might be a harmless error.
For example, if a table in "public" references a table in "outage_data", but only public was dumped, then you will get this error when it tries to recreate the foreign key constraint. That constraint of course will be missing, but no other harm is done. The public table and all of its data will still be there.
I am getting below error while selecting the foreign table from Postgres & please help me on fixing the issue.
ERROR: connection for foreign table "test_enames" cannot be established
DETAIL: ORA-12154: TNS:could not resolve the connect identifier
specified
SQL state: HV00N
Details
1.I am using Postgres 13 version on Windows 10 64 Bit machine.
2.I installed oracle_fdw-2.3.0-pg13-win64 successfully in my Windows 10 6bit machine.
3.Created system variable for TNS_ADMIN=C:\Oracle\product\12.2.0x64\client_1\network\admin
4.Created below steps successfully.
CREATE FOREIGN DATA WRAPPER oracle_fdw
CREATE SERVER foreign_oracle
TYPE 'Oracle12'
VERSION '12'
FOREIGN DATA WRAPPER oracle_fdw
OPTIONS (dbserver '//vms1.abc.com:1524/ABC00D70');
CREATE USER MAPPING FOR postgres SERVER foreign_oracle
OPTIONS ("user" 'Test', password 'Test1');
CREATE FOREIGN TABLE test_enames(
eno numeric NULL,
ename character varying(100),
eloc character varying(100)
) SERVER foreign_oracle
OPTIONS (table 'TEST_ENAMES');
But still getting error while selecting table , let me know incase if i missed any steps.
Thanks
That seems like an Oracle configuration problem.
To debug this, try running the following as the operating system user that runs the PostgreSQL service:
sqlplus Test/Test1#//vms150.abc.com:1524/ABC00D70
If that doesn't work, start debugging that. That should be easier, since oracle_fdw is not part of the equation then.
If the sqlplus call above works as you intend it to, make sure that the PostgreSQL service has the TNS_ADMIN environment variable set (did you restart the service after setting it?). I am not sure how to check the environment for a running process on Windows, but "Process Explorer" might do the trick.
Besides, you shouldn't use CREATE FOREIGN DATA WRAPPER to create the FDW, but create the extension as specified in the documentation:
CREATE EXTENSION oracle_fdw;
That will create the foreign data wrapper for you.
I created a model in no2 branch, then I find some error and decided to delete this branch and start a new one.
But when I rewrote this model and db:migrate , it told me that this table already exist.
I tried db:rollback but didn't work, and the migrate:status showed that:
and my schema.rb is empty
I dropped my db & re db:migrate.
Use sql script, to remove a record from schema_migrations table where version is 20191215065743.
Further, if the boards table exist, drop it using psql command.
I am trying to rename an attribute of a Type in PgSQL using following Alter command
ALTER TYPE typeName
RENAME ATTRIBUTE attrNameOld TO attrNameNew
CASCADE
PgSQL version is 9.5, running on Ubuntu 16.04
However, I receive following error on my Pgsql CLI
ERROR: relation "<typeName>" does not exist
Please help. Thanks.
So, I can't rename an Attribute in PostgreSQL version <10. Thanks to Stephen for sharing the stackoverflow answer.
Alternatives are available though
Remove the Type. Create anew with right Values, and update Table references
Update Catalogs
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.