Context: I want to update a table called "Projects" and change the project number from 10 to 45 where the project name is "Website". This Project table has a PK (pnumber attribute) and its related to another table called "WorksOn" that has a FK (attribute pno) related to the primary key pnumber of Project table.
The diagram would be something like this:
I was trying something like:
BEGIN TRANSACTION;
ALTER TABLE Workson DROP CONSTRAINT fk_workson_projects;
ALTER TABLE Projects DROP CONSTRAINT pk_projects;
UPDATE Projects
SET pnumber = 45
WHERE pname = 'Website';
ALTER TABLE Workson ADD CONSTRAINT fk_workson_projects FOREIGN KEY (pno) REFERENCES projects(pnumber);
ALTER TABLE Projects ADD CONSTRAINT pk_projects PRIMARY KEY (pnumber);
COMMIT;
Essentially dropping the constraints, updating the table and adding the same constraints again but I keep getting this error:
ERROR: current transaction is aborted, commands ignored until end of transaction block
SQL state: 25P02
How could I update the information by dropping the constraints and adding them back again inside a transaction?
Thank you in advance
You need to create the primary key before you can create a foreign key that references it. Looking at the error messages would have told you that.
IntegrityError: insert or update on table "procurement_order" violates foreign key constraint "procurement_order_sale_line_id_fkey"
DETAIL: Key (sale_line_id)=(71) is not present in table "sale_order_line".
I have this error and I know that if I will wipe the value in procurement_order table then the problem will be solved.
So the question is how can I do this using PostgreSQL because I'm not really used it before.
No problem, just make sure you back up the database first, in case something goes wrong.
The following command will wipe all data from table procurement_order:
TRUNCATE TABLE procurement_order;
If this gives you an error, it means that wiping the table violates one or more foreign key constraints. In this case, run the following command -- but understand that it will also wipe the contents of referencing tables:
TRUNCATE TABLE procurement_order CASCADE;
Good luck!
Post the data from both procurement_order and sale_order_line, you are probably just using the wrong value for a foreign key
Let me start by saying that I’m a Linux/Unix admin. That being said my manager has tasked me with moving older PostgreSQL databases to a RedHat server running 8.4.20. I was successful moving a 7.2.1 db but I’m running into issues moving a 7.4.20 db.
I use pg_dump –c filename and psql < filename. For the problematic db everything runs until I get to a CREATE CONSTRAINT TRIGGER statement. If I run it as it is in the file I get :
NOTICE: ignoring incomplete trigger group for constraint "" FOREIGN KEY data(ups) REFERENCES upsinfo(ups)
DETAIL: Found referenced table's DELETE trigger.
CREATE TRIGGER
If I run set schema 'pg_catalog'; I get:
ERROR: relation "upsinfo" does not exist
The tables (I think) involved are:
CREATE TABLE upsinfo (
ups text NOT NULL,
ipaddr inet,
rcomm text,
wcomm text,
reachable boolean,
managed boolean,
comments text,
region text
);
CREATE TABLE data (
date timestamp with time zone,
ups text,
mib text,
value text
);
The trigger problem trigger statement:
CREATE CONSTRAINT TRIGGER "<unnamed>"
AFTER DELETE ON upsinfo
FROM data
NOT DEFERRABLE INITIALLY IMMEDIATE
FOR EACH ROW
EXECUTE PROCEDURE "RI_FKey_cascade_del"('<unnamed>', 'data', 'upsinfo', 'UNSPECIFIED', 'ups', 'ups');
I know that the RI_FKey_cascade_del function is defined differently in the different versions of pg_catalog. Note that search_path is set to ‘public, pg_catalog’ so I’m also confused why I have to set the schema.
Again I’m not a real PostgreSQL DBA so try to be kind.
Oof, those are really old postgres versions, including the version you're upgrading to (8.4 was released in 2009, and support ended in 2014).
The short answer is that, as long as upsinfo and data are being created and populated, you're probably fine, and good to go. But one of your foreign key relationships is broken.
The long answer, well, let me see if I can explain what is going on (or, at least, what I think is going on).
I'm guessing that the original table definition of data included something like FOREIGN KEY (ups) REFERENCES upsinfo (ups) ON DELETE CASCADE. That causes postgres to automatically make some trigger constraints: 1- every time there's a new row for data, make sure that its ups column matches an existing row in upsinfo, and 2- every time you delete a row from upsinfo, delete the corresponding rows in data, based on the matching ups value.
That (not very informative) error message can come up when the foreign key relationship doesn't work. In order for a foreign key to make sense, the referenced value needs to be unique -- there should be only one row in upsinfo for each distinct value of ups. In order for postgres to know that, there needs to be a unique index or primary key on upsinfo.ups.
In this case, one of a couple things could be breaking it:
There's no primary key or unique index on upsinfo.ups (postgres should not have allowed a foreign key, but may have in very old versions)
There used to be a unique index, but it hadn't properly enforced uniqueness, so it didn't get successfully imported (a bug, again likely from a very old version)
In either case, if that foreign key relationship is important, you can try to fix it once the import is complete. Start by trying to make a unique index on upsinfo.ups, and see if you have problems. If you do, resolve the duplicate entries, and try again till it works. Then issue something like:
ALTER TABLE data
ADD FOREIGN KEY (ups) REFERENCES upsinfo (ups) ON DELETE CASCADE;
Of course, if things are working, it's possible you don't need to fix the foreign key, in which case you're probably able to ignore those errors and just move forward.
Hope that helps, and good luck!
This seems to be a part of ON DELETE CONSTRAINT. If I were you I would delete all such statements and replace them with a proper constraint definition on the target table.
Table definition should then look like this:
CREATE TABLE bookings (
boo_id serial NOT NULL,
boo_hotelid character varying NOT NULL,
boo_roomid integer NOT NULL,
CONSTRAINT pk_bookings
PRIMARY KEY (boo_id),
CONSTRAINT fk_bookings_boo_roomid
FOREIGN KEY (boo_roomid)
REFERENCES rooms (roo_id) MATCH SIMPLE
ON UPDATE CASCADE ON DELETE CASCADE
) WITHOUT OIDS;
And this part is what will internally create the trigger:
CONSTRAINT fk_bookings_boo_roomid
FOREIGN KEY (boo_roomid)
REFERENCES rooms (roo_id) MATCH SIMPLE
ON UPDATE CASCADE ON DELETE CASCADE
But, to be honest, I do not have an understanding for an upgrade to an unsupported version. You know the Postgres is version 9.5 now, right?
I searched for this problem. But my postgres user has enough grant and I do not think I have misspelling error. However I am newbie.
I have this error message:
21:38:03 set search_path='public'
21:38:03 ALTER TABLE public.tbl_user DROP CONSTRAINT "fk-user-access-user-id"
21:38:03 ERROR: constraint "fk-user-access-user-id" of relation "tbl_user" does not exist
I use the PhpStorm. I just open the database view, expanded the tbl_user table, right click and select "drop". And I got this error in the console.
So the above SQL command generated by the PhpStorm.
Then I tried with these commands manually on Ubuntu:
ALTER TABLE tbl_user DROP CONSTRAINT "fk-user-access-user-id"
ALTER TABLE "tbl_user" DROP CONSTRAINT "fk-user-access-user-id"
But I get the same error.
In the PhpStorm I see this definition:
"fk-user-access-user-id" FOREIGN KEY (access_id) REFERENCES tbl_access (id)
The tbl_access table exists with the primary id key.
I do not understand this error message, because the "fk-user-access-user-id" foreign key is at the tbl_user and so for me the 'relation "tbl_user" does not exist' strange. I do not understand.
I tried to find similar problem on StackOverflow, but I gave up after 20x question reading.
By the way, the postgres code was generated by the Yii framework.
$this->addColumn('{{%user}}', 'access_id', $this->integer()->notNull()->defaultValue(1)->after('status'));
$this->addForeignKey('fk-user-access-user-id', '{{%user}}', 'access_id', '{{%access}}', 'id');
first row mean add access_id column to the user table.
second row: create foreign key with 'fk-user...' name on tbl_user table's access_id column references to tbl_access table's id column.
So I used this PHP code to generate this SQL commands. I prefer this way because for me the migration files are very useful.
Most likely the definition and actual implementation in your underlying DB has changed from what the app has recorded. Depending on what the history is, either a change in the app for that foreign key relationship was not migrated to persist the change at the database level, or someone has executed some operation directly at the DB level to remove the relationship. You will need to sync up the app layer to the DB at this point I would think.
When creating a foreign key constraint in PostgreSQL from pgAdmin (1.12.2 in my case), the following option is checked:
Auto FK index
I would like to know if it's right to leave it checked all the time, and also understand how that overhead actually works.
For instance, the following constraint:
ALTER TABLE "user"
ADD CONSTRAINT fk_user_region FOREIGN KEY (intregionid)
REFERENCES region (intid) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION;
Creates the following index:
CREATE INDEX fki_user_region
ON "user"
USING btree
(intregionid);
Note that it creates an index only when creating the constraint from pgAdmin.
There is not much documentation about pgAdmin, and nothing specifically about that option.
Thank you.
This creates an Index for the Foreign Key column. By Default, the SGBD´s not created an index for FKs Columns (Index are created by default to Primary Keys and Unique Constraints).
This is a good practice to tuning your database.
Att,
set to No during creation process...
and then seems to be enabled by default:
so everything seems to be fine!