Ошибка связь уже существует

I am trying to create a table that was dropped previously.

But when I do the CREATE TABLE A ... I am getting below error:

Relation ‘A’ already exists.

I verified doing SELECT * FROM A, but then I got another error:

Relation ‘A’ does not exists.

I already tried to find it in \dS+ listing all relations, and it is not there.
To complicate this, I have tested this by creating this table in another database and I got the same error. I am thinking that could be an error when this table was dropped. Any ideas?

Here is the code: I’m using a generated code from Power SQL. I have the same error without using the sequence. It just works when I change the name and in this case I can not do that.

CREATE SEQUENCE csd_relationship_csd_relationship_id_seq;
CREATE TABLE csd_relationship (
    csd_relationship_id INTEGER NOT NULL DEFAULT nextval('csd_relationship_csd_relationship_id_seq'::regclass),  
    type_id INTEGER NOT NULL,
    object_id INTEGER NOT NULL,
    CONSTRAINT csd_relationship PRIMARY KEY (csd_relationship_id)
);

Brian Tompsett - 汤莱恩's user avatar

asked Jan 9, 2012 at 17:55

nsbm's user avatar

2

I finally discover the error. The problem is that the primary key constraint name is equal the table name. I don know how postgres represents constraints, but I think the error «Relation already exists» was being triggered during the creation of the primary key constraint because the table was already declared. But because of this error, the table wasnt created at the end.

answered Jan 12, 2012 at 12:57

nsbm's user avatar

nsbmnsbm

5,8426 gold badges30 silver badges45 bronze badges

5

There should be no single quotes here 'A'. Single quotes are for string literals: 'some value'.
Either use double quotes to preserve the upper case spelling of «A»:

CREATE TABLE "A" ...

Or don’t use quotes at all:

CREATE TABLE A ...

… which is identical to:

CREATE TABLE a ...

… because all unquoted identifiers are folded to lower case in Postgres. See:

  • Are PostgreSQL column names case-sensitive?

You can avoid problems with the index name completely by using simpler syntax:

CREATE TABLE csd_relationship (
  csd_relationship_id serial PRIMARY KEY
, type_id             integer NOT NULL
, object_id           integer NOT NULL
);

Does the same as your original query, only it avoids naming conflicts by picking the next free identifier automatically. More about the serial type in the manual.

answered Jan 9, 2012 at 18:42

Erwin Brandstetter's user avatar

Erwin BrandstetterErwin Brandstetter

608k145 gold badges1083 silver badges1232 bronze badges

1

You cannot create a table with a name that is identical to an existing table or view in the cluster. To modify an existing table, use ALTER TABLE (link), or to drop all data currently in the table and create an empty table with the desired schema, issue DROP TABLE before CREATE TABLE.

It could be that the sequence you are creating is the culprit. In PostgreSQL, sequences are implemented as a table with a particular set of columns. If you already have the sequence defined, you should probably skip creating it. Unfortunately, there’s no equivalent in CREATE SEQUENCE to the IF NOT EXISTS construct available in CREATE TABLE. By the looks of it, you might be creating your schema unconditionally, anyways, so it’s reasonable to use

DROP TABLE IF EXISTS csd_relationship;
DROP SEQUENCE IF EXISTS csd_relationship_csd_relationship_id_seq;

before the rest of your schema update; In case it isn’t obvious, This will delete all of the data in the csd_relationship table, if there is any

jawr's user avatar

jawr

8271 gold badge7 silver badges14 bronze badges

answered Jan 10, 2012 at 17:25

SingleNegationElimination's user avatar

2

Another reason why you might get errors like «relation already exists» is if the DROP command did not execute correctly.

One reason this can happen is if there are other sessions connected to the database which you need to close first.

answered Sep 21, 2018 at 11:58

isedwards's user avatar

isedwardsisedwards

2,42921 silver badges29 bronze badges

In my case, I had a sequence with the same name.

answered Aug 25, 2016 at 15:06

Dave Van den Eynde's user avatar

In my case, it wasn’t until I PAUSEd the batch file and scrolled up a bit, that wasn’t the only error I had gotten. My DROP command had become DROP and so the table wasn’t dropping in the first place (thus the relation did indeed still exist). The  I’ve learned is called a Byte Order Mark (BOM). Opening this in Notepad++, re-save the SQL file with Encoding set to UTM-8 without BOM and it runs fine.

Mogsdad's user avatar

Mogsdad

44.8k21 gold badges153 silver badges275 bronze badges

answered Jan 11, 2016 at 18:25

user5775085's user avatar

0

You may be running the CREATE TABLE after already running it. So you may be creating a table for a second time, while the first attempt already created it.

answered May 14, 2021 at 19:03

ScottyBlades's user avatar

ScottyBladesScottyBlades

12.2k5 gold badges78 silver badges86 bronze badges

In my case I was migrating from 9.5 to 9.6.
So to restore a database, I was doing :

sudo -u postgres psql -d databse -f dump.sql

Of course it was executing on the old postgreSQL database where there are datas! If your new instance is on port 5433, the correct way is :

sudo -u postgres psql -d databse -f dump.sql -p 5433

answered Oct 5, 2016 at 10:30

Nicolas Boisteault's user avatar

Sometimes this kind of error happens when you create tables with different database users and try to SELECT with a different user.
You can grant all privileges using below query.

GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA schema_name TO username;

And also you can grant access for DML statements

GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA schema_name TO username;

answered Nov 10, 2020 at 2:19

Akila K Gunawardhana's user avatar

1

  • The problem is that the primary key constraint name is equal the table name.

  • I don’t know how postgres represents constraints, but I think the error “Relation
    already exists” was being triggered during the creation of the primary key
    constraint because the table was already declared. But because of this error,
    the table wasnt created at the end.

  • give different name to constrain

    Note- go to SQL tab and check table name and constrain

Enjoy :)

answered Oct 20, 2022 at 15:54

Manas Kumar Maharana's user avatar

You already found that the root of the problem was that the primary key had the same name as the table, but let me explain why that is a problem.

All primary and unique constraints are implemented using unique indexes. In PostgreSQL, that index must have the same name as the constraint. So your command tries to create an index named csd_relationship, just like the table.

Now in PostgreSQL, tables, indexes, sequences, views and composite data types all share the same name space, that is, there cannot be two of them with the same name in the same schema. The technical reason is that the metadata of all these objects are stored in the catalog table pg_class, and pg_class has a unique constraint on (relname, relnamespace), that is, the combination of table name and schema.

answered Aug 2 at 6:17

Laurenz Albe's user avatar

Laurenz AlbeLaurenz Albe

211k17 gold badges207 silver badges266 bronze badges

I got this error after running the terminal command «dotnet ef database update». My solution was to open the database and delete/drop tables with the same name.

answered May 4 at 11:11

ZCan's user avatar

my error is :

cteate table xr_inbound_req(.......
   CONSTRAINT table_name PRIMARY KEY (id)
)

when change to this:

cteate table xr_inbound_req(.......
   CONSTRAINT pk_table_name PRIMARY KEY (id)
)

is ok
add pk_ to prefix

Ryan M's user avatar

Ryan M

18.4k31 gold badges67 silver badges75 bronze badges

answered Aug 2 at 6:01

panlufei's user avatar

1

Создаю из 1125 городов базу, но высвечивается ошибка при выполнении кода. Использую postgresql и создаю запрос в pgAdmin 4

Ошибка:

ERROR: ОШИБКА:  отношение "city_id_seq" уже существует


SQL-состояние: 42P07

Запрос:

CREATE TABLE city
(
  id SERIAL PRIMARY KEY,
  id SERIAL,
  id_region integer NOT NULL,
  name varchar(250) NOT NULL

);

INSERT INTO city (id, id_region, name) VALUES
(1, 1, 'Адыгейск'),
(2, 1, 'Майкоп'),
(3, 2, 'Горно-Алтайск'),
(4, 3, 'Алейск'),
(5, 3, 'Барнаул'),
(6, 3, 'Белокуриха'),
(7, 3, 'Бийск'),
(8, 3, 'Горняк'),
(9, 3, 'Заринск'),
(10, 3, 'Змеиногорск'),
(11, 3, 'Камень-на-Оби'),
(12, 3, 'Новоалтайск'),
(13, 3, 'Рубцовск'),
(14, 3, 'Славгород'),
(15, 3, 'Яровое'),
(16, 4, 'Белогорск'),
(17, 4, 'Благовещенск'),
(18, 4, 'Завитинск'),
(19, 4, 'Зея'),
(20, 4, 'Райчихинск'),
(21, 4, 'Свободный'),
(22, 4, 'Сковородино'),
(23, 4, 'Тында'),
(24, 4, 'Шимановск'),
(25, 5, 'Архангельск'),
(26, 5, 'Вельск'),
(27, 5, 'Каргополь'),
(28, 5, 'Коряжма'),
(29, 5, 'Котлас'),
(30, 5, 'Мезень'),
(31, 5, 'Мирный'),
(32, 5, 'Новодвинск'),
(33, 5, 'Няндома'),
(34, 5, 'Онега'),
(35, 5, 'Северодвинск'),
(36, 5, 'Сольвычегодск'),
(37, 5, 'Шенкурск'),
(38, 6, 'Астрахань'),
(39, 6, 'Ахтубинск'),
(40, 6, 'Знаменск'),
(41, 6, 'Камызяк'),
(42, 6, 'Нариманов'),
(43, 6, 'Харабали'),
(44, 7, 'Агидель'),
(45, 7, 'Баймак'),
(46, 7, 'Белебей'),
(47, 7, 'Белорецк'),
(48, 7, 'Бирск'),
(49, 7, 'Благовещенск'),
(50, 7, 'Давлеканово'),
(51, 7, 'Дюртюли'),
(52, 7, 'Ишимбай'),
(53, 7, 'Кумертау'),
(54, 7, 'Межгорье'),
(55, 7, 'Мелеуз'),
(56, 7, 'Нефтекамск'),
(57, 7, 'Октябрьский'),
(58, 7, 'Салават'),
(59, 7, 'Сибай'),
(60, 7, 'Стерлитамак'),
(61, 7, 'Туймазы'),
(62, 7, 'Уфа'),
(63, 7, 'Учалы'),
(64, 7, 'Янаул'),
(65, 8, 'Алексеевка'),
(66, 8, 'Белгород'),
(67, 8, 'Бирюч'),
(68, 8, 'Валуйки'),
(69, 8, 'Грайворон'),
(70, 8, 'Губкин'),
(71, 8, 'Короча'),
(72, 8, 'Новый Оскол'),
(73, 8, 'Старый Оскол'),
(74, 8, 'Строитель'),
(75, 8, 'Шебекино'),
(76, 9, 'Брянск'),
(77, 9, 'Дятьково'),
(78, 9, 'Жуковка'),
(79, 9, 'Злынка'),
(80, 9, 'Карачев'),
(81, 9, 'Клинцы'),
(82, 9, 'Мглин'),
(83, 9, 'Новозыбков'),
(84, 9, 'Почеп'),
(85, 9, 'Севск'),
(86, 9, 'Сельцо'),
(87, 9, 'Стародуб'),
(88, 9, 'Сураж'),
(89, 9, 'Трубчевск'),
(90, 9, 'Унеча'),
(91, 9, 'Фокино'),
(92, 10, 'Бабушкин'),
(93, 10, 'Гусиноозёрск'),
(94, 10, 'Закаменск'),
(95, 10, 'Кяхта'),
(96, 10, 'Северобайкальск'),
(97, 10, 'Улан-Удэ'),
(98, 11, 'Александров'),
(99, 11, 'Владимир'),
(100, 11, 'Вязники'),
(101, 11, 'Гороховец'),
(102, 11, 'Гусь-Хрустальный'),
(103, 11, 'Камешково'),
(104, 11, 'Карабаново'),
(105, 11, 'Киржач'),
(106, 11, 'Ковров'),
(107, 11, 'Кольчугино'),
(108, 11, 'Костерёво'),
(109, 11, 'Курлово'),
(110, 11, 'Лакинск'),
(111, 11, 'Меленки'),
(112, 11, 'Муром'),
(113, 11, 'Петушки'),
(114, 11, 'Покров'),
(115, 11, 'Радужный'),
(116, 11, 'Собинка'),
(117, 11, 'Струнино'),
(118, 11, 'Судогда'),
(119, 11, 'Суздаль'),
(120, 11, 'Юрьев-Польский'),
(121, 12, 'Волгоград'),
(122, 12, 'Волжский'),
(123, 12, 'Дубовка'),
(124, 12, 'Жирновск'),
(125, 12, 'Калач-на-Дону'),
(126, 12, 'Камышин'),
(127, 12, 'Котельниково'),
(128, 12, 'Котово'),
(129, 12, 'Краснослободск'),
(130, 12, 'Ленинск'),
(131, 12, 'Михайловка'),
(132, 12, 'Николаевск'),
(133, 12, 'Новоаннинский'),
(134, 12, 'Палласовка'),
(135, 12, 'Петров Вал'),
(136, 12, 'Серафимович'),
(137, 12, 'Суровикино'),
(138, 12, 'Урюпинск'),
(139, 12, 'Фролово'),
(140, 13, 'Бабаево'),
(141, 13, 'Белозерск'),
(142, 13, 'Великий Устюг'),
(143, 13, 'Вологда'),
(144, 13, 'Вытегра'),
(145, 13, 'Грязовец'),
(146, 13, 'Кадников'),
(147, 13, 'Кириллов'),
(148, 13, 'Красавино'),
(149, 13, 'Никольск'),
(150, 13, 'Сокол'),
(151, 13, 'Тотьма'),
(152, 13, 'Устюжна'),
(153, 13, 'Харовск'),
(154, 13, 'Череповец'),
(155, 14, 'Бобров'),
(156, 14, 'Богучар'),
(157, 14, 'Борисоглебск'),
(158, 14, 'Бутурлиновка'),
(159, 14, 'Воронеж'),
(160, 14, 'Калач'),
(161, 14, 'Лиски'),
(162, 14, 'Нововоронеж'),
(163, 14, 'Новохопёрск'),
(164, 14, 'Острогожск'),
(165, 14, 'Павловск'),
(166, 14, 'Поворино'),
(167, 14, 'Россошь'),
(168, 14, 'Семилуки'),
(169, 14, 'Эртиль'),
(170, 15, 'Буйнакск'),
(171, 15, 'Республика Дагестанские Огни'),
(172, 15, 'Дербент'),
(173, 15, 'Избербаш'),
(174, 15, 'Каспийск'),
(175, 15, 'Кизилюрт'),
(176, 15, 'Кизляр'),
(177, 15, 'Махачкала'),
(178, 15, 'Хасавюрт'),
...

Я пытаюсь создать таблицу, которая была ранее сброшена.

но когда я делаю CREATE TABLE A ... Я получаю ниже ошибки:

отношение » а » уже существует.

Я проверил делаешь SELECT * FROM A, но потом я получил еще одну ошибку:

отношение » а » не существует.

Я уже пытался найти его в dS+ список всех отношений, и его там нет.
Чтобы усложнить это, я протестировал создать эту таблицу в другой базе данных, и я получил ту же ошибку. Я думаю, что это может быть ошибкой, когда эта таблица была удалена. Есть идеи?

вот код: я использую сгенерированный код из Power SQL. У меня такая же ошибка без использования последовательности. Он просто работает, когда я меняю имя, и в этом случае я не могу этого сделать.

CREATE SEQUENCE csd_relationship_csd_relationship_id_seq;
CREATE TABLE csd_relationship (
    csd_relationship_id INTEGER NOT NULL DEFAULT nextval('csd_relationship_csd_relationship_id_seq'::regclass),  
    type_id INTEGER NOT NULL,
    object_id INTEGER NOT NULL,
    CONSTRAINT csd_relationship PRIMARY KEY (csd_relationship_id)
);

7 ответов


Я, наконец, обнаруживаю ошибку. Проблема в том, что имя ограничения первичного ключа равно имени таблицы. Я не знаю, как postgres представляет ограничения, но я думаю, что ошибка «отношение уже существует» запускалась во время создания ограничения первичного ключа, потому что таблица уже была объявлена. Но из-за этой ошибки таблица не была создана в конце.


здесь не должно быть одинарных кавычек 'A'. Одинарные кавычки для строковых литералов: 'some value'.
Либо используйте двойные кавычки, чтобы сохранить правописание верхнего регистра «A»:

CREATE TABLE "A" ...

или вообще не используйте кавычки:

CREATE TABLE A ...

, что соответствует

CREATE TABLE a ...

потому что все без кавычек коды are автоматически складывается в нижний регистр в PostgreSQL.


вы могли избегайте проблем с именем индекса полностью, используя более простой синтаксис:

CREATE TABLE csd_relationship (
    csd_relationship_id serial PRIMARY KEY,
    type_id integer NOT NULL,
    object_id integer NOT NULL
);

делает то же самое, что и ваш исходный запрос, только он избегает конфликтов имен автоматически. Он автоматически выбирает следующий бесплатный идентификатор. Подробнее о серийный тип в руководстве.

10

автор: Erwin Brandstetter


нельзя создать таблицу с именем, идентичным существующей таблице или представлению в кластере. Чтобы изменить существующую таблицу, используйте ALTER TABLE (ссылка), или удалить все данные в таблице и создать пустую таблицу с нужной схемой, вопрос DROP TABLE до CREATE TABLE.

возможно, что последовательность, которую вы создаете, является виновником. В PostgreSQL последовательности реализуются в виде таблицы с определенным набором столбцов. Если у вас уже есть последовательность определена, вы, вероятно, должны пропустить ее создание. К сожалению, эквивалента в CREATE SEQUENCE до IF NOT EXISTS конструкция доступна в CREATE TABLE. Судя по всему, вы можете создавать свою схему безоговорочно, в любом случае, поэтому разумно использовать

DROP TABLE IF EXISTS csd_relationship;
DROP SEQUENCE IF EXISTS csd_relationship_csd_relationship_id_seq;

перед остальной частью обновления схемы; в случае, если это не очевидно,это удалит все данные в csd_relationship таблица, если есть

5

автор: SingleNegationElimination


в моем случае это было не до тех пор, пока я не приостановил пакетный файл и немного прокрутил его, это была не единственная ошибка, которую я получил. Мой стало DROP и поэтому таблица не падала в первую очередь (таким образом, отношение действительно все еще существовало). The  я узнал, что называется меткой порядка байтов (BOM). Открыв это в Notepad++, повторно сохраните файл SQL с кодировкой UTM-8 без BOM, и он работает нормально.


в моем случае, у меня была последовательность с тем же именем.

2

автор: Dave Van den Eynde


в моем случае я мигрировал с 9.5 до 9.6.
Поэтому, чтобы восстановить базу данных, я делал:

sudo -u postgres psql -d databse -f dump.sql

конечно, он выполнялся на старой базе данных postgreSQL, где есть данные! Если ваш новый экземпляр находится на порту 5433, правильный способ:

sudo -u postgres psql -d databse -f dump.sql -p 5433

0

автор: Nicolas Boisteault


еще одна причина, по которой вы можете получить ошибки, такие как» отношение уже существует», если не правильно выполнить.

одна из причин этого может произойти, если есть другие сеансы, подключенные к базе данных, которые необходимо закрыть в первую очередь.


Здравствуйте. Создала таблицы: Страны, Страны-туры, Туры. Связала таблицы Страны и Страны-туры по Id,а вот связать Страны-туры и Туры уже не получилось. Связывала по одному и тому же принципу,но при создании второй связи выдает следующее:

PHP
1
2
3
4
5
6
7
8
9
10
11
SQL-запрос:
 
ALTER TABLE  `Тур-страна` ADD FOREIGN KEY (  `tour_id` ) REFERENCES  `admin`.`Тур` (
 
`Id`
) ON DELETE CASCADE ON UPDATE CASCADE ;
 
 
Ответ MySQL: Документация
 
#1050 - Table '.admin@y0@z0@w0@002d@s0@y1@x0@y0@u0' already exists

Подскажите,пожалуйста, неужели в одной таблице может быть только один атрибут связан? Связывала атрибуты так: в таблице Страны Id имеет тип Int и автоинкремент. В таблице Страны-туры атрибут Id_country,который ссылается на атрибут Id таблицы Страны , имеет по умолчанию NULL и является индексом, далее шла в «Связи», соединяла соответствующие атрибуты и было все ок. Проделала те же действия с таблицами «Туры-страны» и Туры, но выдало вышеизложенное сообщение. Буду благодарна за ответы.

__________________
Помощь в написании контрольных, курсовых и дипломных работ, диссертаций здесь

Вы не вошли. Пожалуйста, войдите или зарегистрируйтесь.

Активные темы Темы без ответов

Страницы 1

Чтобы отправить ответ, вы должны войти или зарегистрироваться

1 2011-05-07 08:34:48 (изменено: dobroe_utro, 2011-05-07 08:43:54)

  • dobroe_utro
  • Новичок
  • Неактивен
  • Зарегистрирован: 2011-05-07
  • Сообщений: 1

Тема: Не отображаются связи в designer базы данных.

Доброе всем утро.
Прошу Вас помочь мне-))))
Создала бд, и мне нужно соединить линиями таблички в designer

один раз  щелкнули на одном поле, потом на другом, с которым нужно соединить, появится окошечко
‘create relation&’ нажала ок. И линия не отображается…. Сорри.

2 Ответ от Hanut 2011-05-07 11:45:37

  • Hanut
  • Hanut
  • Модератор
  • Неактивен
  • Откуда: Рига, Латвия
  • Зарегистрирован: 2006-07-02
  • Сообщений: 9,722

Re: Не отображаются связи в designer базы данных.

dobroe_utro сказал:

один раз  щелкнули на одном поле, потом на другом, с которым нужно соединить

В панели инструментов нажимаем кнопку «Создать связь», после чего рядом с курсором появится надпись «Выберите ссылочный ключ», выбираемое поле ссылочного ключа должно иметь тип индекса (иконка ключика); после выбора ссылочного ключа, рядом с курсором появится надпись «Выберите внешний ключ», выбираем связываемое поле в другой таблице и линия должна появиться. Связь уже создана, но чтобы в поле внешнего ключа отображалась желаемая информация из связанной таблицы, необходимо в панели инструментов нажать кнопку «Выбор отображаемого столбца» и кликнуть по желаемому поля для отображения в первой таблице.

Если не получится, то покажите как выглядят связываемые таблицы и какие поля требуется связать.

3 Ответ от Bernet 2011-05-17 11:36:06 (изменено: Bernet, 2011-05-17 11:54:58)

  • Bernet
  • Редкий гость
  • Неактивен
  • Зарегистрирован: 2011-05-17
  • Сообщений: 5

Re: Не отображаются связи в designer базы данных.

у меня та же беда( сделал всё как вы описали, но всё равно пишет Ошибка. Связь не создана
у вас тут написано http://forum.php-myadmin.ru/viewtopic.php?id=1447 что связи для таблиц MyISAM создать нельзя, то получается надо использовать только таблицы InnoDB? и связи надо задавать через дизайнер когда соединяешь таблицы графично, или всё таки через кнопку Связи->Внутренние связи? а то я не могу понять где их вообще создавать

4 Ответ от Hanut 2011-05-17 11:55:38

  • Hanut
  • Hanut
  • Модератор
  • Неактивен
  • Откуда: Рига, Латвия
  • Зарегистрирован: 2006-07-02
  • Сообщений: 9,722

Re: Не отображаются связи в designer базы данных.

Bernet сказал:

связи зависят от типа таблиц..?

Зависят в любом случае. Хотя даже не знаю что будет, если связать таблицы MyISAM и InnoDB — не пробовал.

5 Ответ от Hanut 2011-05-17 12:01:07

  • Hanut
  • Hanut
  • Модератор
  • Неактивен
  • Откуда: Рига, Латвия
  • Зарегистрирован: 2006-07-02
  • Сообщений: 9,722

Re: Не отображаются связи в designer базы данных.

Bernet сказал:

связи для таблиц MyISAM создать нельзя

Связи для таблиц MyISAM создаются с помощью специального механизма phpMyAdmin, в то время, как связи таблиц InnoDB хранятся в структуре самих таблиц. Связи можно делать для обоих типов этих таблиц.

Bernet сказал:

связи надо задавать через дизайнер когда соединяешь таблицы графично, или всё таки через кнопку Связи->Внутренние связи?

Я делаю связи только через Дизайнер. На странице связей можно более точно определить связь таблиц типа InnoDB, если это надо.

6 Ответ от Bernet 2011-05-17 12:15:57

  • Bernet
  • Редкий гость
  • Неактивен
  • Зарегистрирован: 2011-05-17
  • Сообщений: 5

Re: Не отображаются связи в designer базы данных.

просто я пробовал через дизайнер сначала выбирал поле с ID (первичный ключ) потом FK (вторичный ключ) но связь не создаётся пишет ‘ошибка. Связь не добавлена’, вот скрин моих табличек…
http://nextsoft-obmen.at.ua/_ph/1/677919075.png

7 Ответ от Hanut 2011-05-17 17:36:03

  • Hanut
  • Hanut
  • Модератор
  • Неактивен
  • Откуда: Рига, Латвия
  • Зарегистрирован: 2006-07-02
  • Сообщений: 9,722

Re: Не отображаются связи в designer базы данных.

Bernet сказал:

ID (первичный ключ) потом FK (вторичный ключ)

Вроде все правильно.

Покажите структуры связываемых таблиц, чтобы я попробовал. Если получится, значит проблема где-то у вас.

8 Ответ от Bernet 2011-05-17 21:15:33

  • Bernet
  • Редкий гость
  • Неактивен
  • Зарегистрирован: 2011-05-17
  • Сообщений: 5

Re: Не отображаются связи в designer базы данных.

9 Ответ от Hanut 2011-05-17 21:57:34

  • Hanut
  • Hanut
  • Модератор
  • Неактивен
  • Откуда: Рига, Латвия
  • Зарегистрирован: 2006-07-02
  • Сообщений: 9,722

Re: Не отображаются связи в designer базы данных.

Bernet сказал:

Вот скрины всех трёх табличек

Выберите в phpMyAdmin таблицы и перейдите на страницу экспорта, где сделайте экспорт структур таблиц без данных. Нужны SQL запросы, которые будут выведены. По картинкам я не смогу сделать. smile

10 Ответ от Bernet 2011-05-17 22:31:07

  • Bernet
  • Редкий гость
  • Неактивен
  • Зарегистрирован: 2011-05-17
  • Сообщений: 5

Re: Не отображаются связи в designer базы данных.

извините я просто только начал изучать это дело вот и туплю маленько wink
это оно?) Табличка1:

-- phpMyAdmin SQL Dump
-- version 2.11.4
-- http://www.phpmyadmin.net
--
-- Хост: localhost
-- Время создания: Май 17 2011 г., 22:25
-- Версия сервера: 5.0.51
-- Версия PHP: 5.2.5

SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";

--
-- База данных: `computer_shop`
--

-- --------------------------------------------------------

--
-- Структура таблицы `computer`
--

CREATE TABLE IF NOT EXISTS `computer` (
  `ID_Computer` int(10) unsigned NOT NULL auto_increment,
  `Processor` varchar(20) character set utf8 collate utf8_unicode_ci NOT NULL,
  `Chastota` double NOT NULL,
  `RAM` int(11) NOT NULL,
  `Model` varchar(20) character set utf8 collate utf8_unicode_ci NOT NULL,
  `Release_Date` date NOT NULL,
  PRIMARY KEY  (`ID_Computer`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;

--
-- Дамп данных таблицы `computer`
--

табличка 2:

SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";

--
-- База данных: `computer_shop`
--

-- --------------------------------------------------------

--
-- Структура таблицы `firms`
--

CREATE TABLE IF NOT EXISTS `firms` (
  `ID_Firm` int(11) NOT NULL auto_increment,
  `Firm_name` varchar(30) default NULL,
  `Adres` varchar(50) default NULL,
  PRIMARY KEY  (`ID_Firm`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;

--
-- Дамп данных таблицы `firms`
--

и наконец третья:)

SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";

--
-- База данных: `computer_shop`
--

-- --------------------------------------------------------

--
-- Структура таблицы `market_supply`
--

CREATE TABLE IF NOT EXISTS `market_supply` (
  `ID_Supply` int(10) unsigned NOT NULL auto_increment,
  `Number_comp` int(10) unsigned NOT NULL,
  `Price` int(10) unsigned NOT NULL,
  `FK_Computer` int(10) unsigned NOT NULL,
  `FK_Firms` int(10) unsigned NOT NULL,
  PRIMARY KEY  (`ID_Supply`),
  KEY `FK_Computer` (`FK_Computer`),
  KEY `FK_Firms` (`FK_Firms`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;

--
-- Дамп данных таблицы `market_supply`
--


--
-- Ограничения внешнего ключа сохраненных таблиц
--

--
-- Ограничения внешнего ключа таблицы `market_supply`
--
ALTER TABLE `market_supply`
  ADD CONSTRAINT `market_supply_ibfk_1` FOREIGN KEY (`FK_Computer`) REFERENCES `computer` (`ID_Computer`) ON UPDATE NO ACTION;

11 Ответ от Hanut 2011-05-18 11:41:58

  • Hanut
  • Hanut
  • Модератор
  • Неактивен
  • Откуда: Рига, Латвия
  • Зарегистрирован: 2006-07-02
  • Сообщений: 9,722

Re: Не отображаются связи в designer базы данных.

Судя по запросам, одна связь между computer.ID_Computer и market_supply.FK_Computer у вас есть и она должна отображаться в дизайнере.

Связать firms.ID_Firm и market_supply.FK_Firms у вас не получится, потому что поля имеют разный тип данных int(10) и int(11).

Если вы заходите в phpMyAdmin не под root, то обратите внимание на права пользователя, которые должны распространяться на БД phpmyadmin, где хранятся связи таблиц.

Пока не поздно, советую сделать следующее: смените тип таблиц на MyISAM; проставьте у всех таблиц единую кодировку (сейчас кодировки перемешаны); установите связи в Дизайнере.

12 Ответ от Bernet 2011-05-18 17:29:32

  • Bernet
  • Редкий гость
  • Неактивен
  • Зарегистрирован: 2011-05-17
  • Сообщений: 5

Re: Не отображаются связи в designer базы данных.

Вообщем снёс ту базу сделал заново, связи в дизайнере так и не получились, сделал просто через вкладку Связи, вроде всё нормально  спасибо Вам большое за помощь и потраченное время  smile

Сообщения 12

Страницы 1

Чтобы отправить ответ, вы должны войти или зарегистрироваться

На хостинге есть 3 таблицы (InnoDB) со связями. У каждой есть свой первичный ключ. При добавлении ограничения везде выбирал ON DELETE CASCADE, ON UPDATE CASCADE. Всё отлично работает, но в дизайнере связи не отображаются и появляется данное окно (скрин). Даже перемещать таблицы нельзя.

Причём окно Удалить связь накладывается на Создать связь.

Версия phpMyAdmin: 4.4.15.10

Причём точно так же на локалке с последней версией phpMyAdmin.
В чём может быть проблема?введите сюда описание изображения

задан 11 мая 2018 в 7:46

Евгений's user avatar

1

скачай последнюю версию phpmyadmin и распакуй в папку, где лежит у тебя phpmyadmin (на локальном сервере помогло)

ответ дан 3 июл 2018 в 13:32

Сергей's user avatar

СергейСергей

93 бронзовых знака

Вопрос:

Когда я хочу создать связь между двумя таблицами в режиме конструктора с phpMyAdmin 4.3.8, это дает мне ошибку: Ошибка: реляционные функции отключены!
Когда я пробую это с 4.1.4, он работает отлично.
Кажется, я не могу найти, где я должен изменить настройки, чтобы создавать отношения в режиме конструктора.
Есть идеи?
Спасибо заранее!

Ответ №1

Преобразуйте свой движок table/db в InnoDB, используя

ALTER TABLE имя_таблицы ENGINE = InnoDB;

Ответ №2

У меня была такая же проблема, потому что у меня не было базы данных на сервере mysql для настроек pypMyAdmin.

Поэтому вам может потребоваться обновить базу данных настроек PMA или создать ее…

Существует руководство о том, как это сделать здесь

Ответ №3

Я столкнулся с той же ошибкой, что не создал никаких PMA-пользователей. Я только что обновил версию phpmyadmin до последней версии, и все работало просто отлично.

вот ссылка для скачивания, и для меня это было 4.6.0

https://www.phpmyadmin.net/downloads/

и для меня я работал над MAMP Pro, поэтому я просто сделал:

  • Я остановил сервер (MAMP Pro).
  • Я скопировал файл (config.inc.php) из старой папки phpmyadmin в новую.
  • Я заменил старую версию новой ( “/Applications/MAMP/bin/” ).
  • Я скопировал ту же самую новую папку с версией ( “/Library/Application Support/appsolute/MAMP PRO/” ), потому что я работаю с MAMP Pro, а не с MAMP.
  • И затем я перезапустил сервер (MAMP Pro), и все работало нормально.

Я надеюсь, что это сработает и для вас.

Ответ №4

Измените свою таблицу на InnoDB, используя:

ALTER TABLE имя вашей таблицы ENGINE = InnoDB

The table2 foreign key constraint means that any table2 customerId value must appear as a customerId in table1. You are getting the error because you are inserting a customerID into table2 that doesn’t appear in table1.

Since the DBMS is generating table1 customerIDs by auto increment, if you insert a row you have to get that value in order to insert a row using that customerID into table2.

I guess you say «I already established a relationship between table1 and table2» to mean «I declared a foreign key constraint». And I guess you think that means «after I insert into table1 the DBMS will use the auto-generated key value as the foreign key value when I insert into table2». But it doesn’t mean that. You have to do that yourself. The foreign key constraint just means that the DBMS checks that every table2 customerId value appears as a table1 customerId value.

You can and must use any previously inserted key value as the corresponding value when you insert into a table with a foreign key to that key.

To get back the auto incremented key value generated by the DBMS use LAST_INSERT_ID():

INSERT INTO table1 (CustomerName,Address,State)
VALUES('value1','value2','value3');
INSERT INTO table2 (customerId,product,cost)
VALUES(LAST_INSERT_ID(),'valueA','valueB');

This is what it is for. But here are the problems if you don’t use it.

First, if you are not in a serialized transaction then you must use LAST_INSERT_ID(). Because after your table1 insert but before your table2 insert others could have added rows and/or deleted rows including your new row and/or changed rows including your new row. So you cannot rely on querying table1 after its insert get some customerId value that you know you added.

Second, suppose you are in a serialized transaction and you don’t use LAST_INSERT_ID().

If (CustomerName,Address,State) is also a superkey of table1, ie its values are unique, ie SQL UNIQUE/KEY/PK is declared on all or some of its columns, then you can use it to query for the associated new customerId:

set @customerId = (
    SELECT customerId
    FROM table1
    WHERE CustomerName = 'value1'
    AND Address = 'value2'
    AND State = 'value3');
INSERT INTO table2 (customerId,product,cost)
VALUES(@customerId,'valueA','valueB');

But if (CustomerName,Address,State) is not a superkey of table1 then you cannot do this. Because other rows that are duplicates for that subrow could be in table1. So you could get multiple rows back. So you would not know which is the newest one. Instead you have to query table1 before the insert, then insert, then find the difference between the old and new sets of customerIds:

CREATE TEMPORARY TABLE table1old (
    customerId (int) PRIMARY KEY
    );
INSERT INTO table1old
SELECT customerId FROM table1;

INSERT INTO table1 (CustomerName,Address,State)
VALUES('value1','value2','value3');

set @customerId = (
    SELECT customerId
    FROM table1
    WHERE CustomerName NOT IN table1old);
INSERT INTO table2 (customerId,product,cost)
VALUES(@customerId,'valueA','valueB');

Just use LAST_INSERT_ID().

PS: Interestingly, given the table definitions, ideally one could write:

INSERT INTO (
    SELECT CustomerName,Address,State,A,B
    FROM table1 JOIN table2
    USING (CustomerId))
VALUES('value1','value2','value3','valueA','valueB')

since there is just one pair of new table1 & table2 values that can result. There are some legal updates through views in SQL, although none involving multiple tables in MySQL currently

The table2 foreign key constraint means that any table2 customerId value must appear as a customerId in table1. You are getting the error because you are inserting a customerID into table2 that doesn’t appear in table1.

Since the DBMS is generating table1 customerIDs by auto increment, if you insert a row you have to get that value in order to insert a row using that customerID into table2.

I guess you say «I already established a relationship between table1 and table2» to mean «I declared a foreign key constraint». And I guess you think that means «after I insert into table1 the DBMS will use the auto-generated key value as the foreign key value when I insert into table2». But it doesn’t mean that. You have to do that yourself. The foreign key constraint just means that the DBMS checks that every table2 customerId value appears as a table1 customerId value.

You can and must use any previously inserted key value as the corresponding value when you insert into a table with a foreign key to that key.

To get back the auto incremented key value generated by the DBMS use LAST_INSERT_ID():

INSERT INTO table1 (CustomerName,Address,State)
VALUES('value1','value2','value3');
INSERT INTO table2 (customerId,product,cost)
VALUES(LAST_INSERT_ID(),'valueA','valueB');

This is what it is for. But here are the problems if you don’t use it.

First, if you are not in a serialized transaction then you must use LAST_INSERT_ID(). Because after your table1 insert but before your table2 insert others could have added rows and/or deleted rows including your new row and/or changed rows including your new row. So you cannot rely on querying table1 after its insert get some customerId value that you know you added.

Second, suppose you are in a serialized transaction and you don’t use LAST_INSERT_ID().

If (CustomerName,Address,State) is also a superkey of table1, ie its values are unique, ie SQL UNIQUE/KEY/PK is declared on all or some of its columns, then you can use it to query for the associated new customerId:

set @customerId = (
    SELECT customerId
    FROM table1
    WHERE CustomerName = 'value1'
    AND Address = 'value2'
    AND State = 'value3');
INSERT INTO table2 (customerId,product,cost)
VALUES(@customerId,'valueA','valueB');

But if (CustomerName,Address,State) is not a superkey of table1 then you cannot do this. Because other rows that are duplicates for that subrow could be in table1. So you could get multiple rows back. So you would not know which is the newest one. Instead you have to query table1 before the insert, then insert, then find the difference between the old and new sets of customerIds:

CREATE TEMPORARY TABLE table1old (
    customerId (int) PRIMARY KEY
    );
INSERT INTO table1old
SELECT customerId FROM table1;

INSERT INTO table1 (CustomerName,Address,State)
VALUES('value1','value2','value3');

set @customerId = (
    SELECT customerId
    FROM table1
    WHERE CustomerName NOT IN table1old);
INSERT INTO table2 (customerId,product,cost)
VALUES(@customerId,'valueA','valueB');

Just use LAST_INSERT_ID().

PS: Interestingly, given the table definitions, ideally one could write:

INSERT INTO (
    SELECT CustomerName,Address,State,A,B
    FROM table1 JOIN table2
    USING (CustomerId))
VALUES('value1','value2','value3','valueA','valueB')

since there is just one pair of new table1 & table2 values that can result. There are some legal updates through views in SQL, although none involving multiple tables in MySQL currently

#1 30.03.2017 06:46:14

Ошибка SQLSTATE[42S21]

Формирую миграцию по изменению таблицы

php artisan make:migration ChangeArticlesTable —table=articles
Миграция происходит успешно.

Далее открываю файл миграции, вношу записи по формировании связи с другой таблицей
    $table->integer(‘user_id’)->unsigned()->default(1);
    $table->foreign(‘user_id’)->references(‘id’)->on(‘users’);         
     $table->integer(‘category_id’)->unsigned()->default(1);
     $table->foreign(‘category_id’)->references(‘id’)->on(‘categories’);
Дальше необходимо внести изменения командой
php artisan migrate

Но изменения не вносятся, появляется сообщение об ошибке:

[IlluminateDATABASEQueryException]
SQLSTATE[42S21]: COLUMN already EXISTS: 1060 Duplicate COLUMN name ‘user_id’
(SQL: ALTER TABLE ‘articles’ ADD ‘user_id’ INT UNSIGNED NOT NULL DEFAULT ‘1’, ADD ‘catego ry_id’ INT UNSIGNED NOT NULL DEFAULT ’l’)

[PDOException]
SQLSTATE[42S21]: COLUMN already EXISTS: I960 Duplicate COLUMN name ’user_id’

В чем тут может быть проблема? Конечно, колонки у меня уже есть, но мне нужно выстроить взаимосвязи между таблицами.

#2 30.03.2017 07:45:50

Re: Ошибка SQLSTATE[42S21]

почему связи вообще в миграции-то? туда только колонки добавляются, а связи – в моделях. только если внешние ключи добавить, но если сайт не в продакшене, тогда проще добавить их в ту миграцию где таблица создаётся и заново пересоздать базу. и ещё если не нужны каскадные эффекты, тогда внешние ключи вообще не нужны

#3 30.03.2017 08:20:10

Re: Ошибка SQLSTATE[42S21]

constb пишет:

почему связи вообще в миграции-то? туда только колонки добавляются, а связи – в моделях. только если внешние ключи добавить, но если сайт не в продакшене, тогда проще добавить их в ту миграцию где таблица создаётся и заново пересоздать базу. и ещё если не нужны каскадные эффекты, тогда внешние ключи вообще не нужны

Благодарю! Правильно поправил меня, мне действительно нужно установить внешние ключи. Но тот алгоритм по внешним ключам который я делаю должен выполняться, но где-то ошибка. У меня вначале вообще не устанавливались таблицы, установил только когда перешел mySQL на 5.7-64. Не знаю, может быть есть какой то другой алгоритм действий есть по установлению внешних ключей.

#4 30.03.2017 10:09:57

skiphog

Откуда: Киров, Россия
Сообщений: 26

Re: Ошибка SQLSTATE[42S21]

SZV пишет:

… У меня вначале вообще не устанавливались таблицы, установил только когда перешел mySQL на 5.7-64

Документация https://laravel.com/docs/5.4/migrations#indexes

Laravel 5.4 по умолчанию использует кодировку utf8mb4, которая включает в себя поддержку смайлов «emoji»
Если вы хотите использовать mysql 5.6, то можно в AppServiceProvider => boot добавить Schema::defaultStringLength(191);
либо пойти в config => database и в настройках mysql сменить кодировку utf8mb4 на utf8 и collation на utf8_unicode_ci, но тогда поддержки «emoji» не будет…

Теперь, что касается миграции…

Мускул же вам понятно написал причину ошибки.
Вы пытаетесь добавить столбец, который уже существует в таблице.
Вы уже создавали этот столбец в предыдущей миграции, верно? Если вы действительно хотите его изменить, то добавьте ->change()

$table->integer(‘user_id’)->unsigned()->default(1)->change();
*должен быть установлен doctrine/dbal

Если вам не нужно менять столбец, а нужно только связать ключи, то эту строку вообще удалите, но учтите, что для связывания user_id должен быть unsigned, иначе опять выскочит ошибка.

#5 30.03.2017 12:25:03

Re: Ошибка SQLSTATE[42S21]

skiphog пишет:

SZV пишет:

… У меня вначале вообще не устанавливались таблицы, установил только когда перешел mySQL на 5.7-64

Документация https://laravel.com/docs/5.4/migrations#indexes

Laravel 5.4 по умолчанию использует кодировку utf8mb4, которая включает в себя поддержку смайлов «emoji»
Если вы хотите использовать mysql 5.6, то можно в AppServiceProvider => boot добавить Schema::defaultStringLength(191);
либо пойти в config => database и в настройках mysql сменить кодировку utf8mb4 на utf8 и collation на utf8_unicode_ci, но тогда поддержки «emoji» не будет…

Теперь, что касается миграции…

Мускул же вам понятно написал причину ошибки.
Вы пытаетесь добавить столбец, который уже существует в таблице.
Вы уже создавали этот столбец в предыдущей миграции, верно? Если вы действительно хотите его изменить, то добавьте ->change()

$table->integer(‘user_id’)->unsigned()->default(1)->change();
*должен быть установлен doctrine/dbal

Если вам не нужно менять столбец, а нужно только связать ключи, то эту строку вообще удалите, но учтите, что для связывания user_id должен быть unsigned, иначе опять выскочит ошибка.

Вы правы. Добавил ->change(). Немного продвминулся в решении проблемы, но вышла другая ошибка
«[RuntimeException]
Changing columns for table «articles» requires Doctrine DBAL; install «doctrine/dba 1″.»

Т.е. то о чем Вы пишите. Добавить doctrine/dba 1.

Смею спросить а как правильно установить этот doctrine/dba 1.
Нашел:
«Если вы используете функцию renameColumn в ваших миграциях, то вам надо будет добавить зависимость doctrine/dbal в ваш файл composer.json. Этот пакет больше не входит в Laravel по умолчанию.»

Где находится файл composer.json. что за зависимость необходимо добавить? Я так понимаю, что по умолчанию в Laravel сейчас нет doctrine/dba. Может быть внешние ключи можно установить неким более простым способом? Или все таки установить doctrine, но опять же как?

#6 30.03.2017 14:09:35

Re: Ошибка SQLSTATE[42S21]

ещё раз – если не используешь каскадные эффекты, внешние ключи в mysql добавлять не нужно. связи моделей не используют foreign keys никак вообще, и от их наличия или отсутствия не зависят. внешние ключи нужны только в связке с on cascade delete, on cascade update и on cascade set null.

composer.json находится в корне проекта, doctrine/dbal – это не доктрина, это только её DataBase Abstraction Layer, устанавливается командой composer require doctrine/dbal в корне проекта, нужна только для сложных миграций, то есть не всем и не всегда – потому в стандартную установку и не входит

#7 30.03.2017 14:33:57

skiphog

Откуда: Киров, Россия
Сообщений: 26

Re: Ошибка SQLSTATE[42S21]

SZV пишет:

Может быть внешние ключи можно установить неким более простым способом?

Судя по «mySQL 5.7-64» у вас установлен OpenServer? Там есть PhpMyadmin.
Зайдите туда, выберите вашу БД и выполните запрос
Для юзеров

alter table articles add foreign key articles_user_id_foreign (user_id) references users(id)

И для категорий

alter table articles add foreign key articles_category_id_foreign (category_id) references categories(id)

Ну и да. Вам уже написали

constb пишет:

…внешние ключи нужны только в связке с on cascade delete, on cascade update и on cascade set null

#8 30.03.2017 16:21:51

Re: Ошибка SQLSTATE[42S21]

skiphog пишет:

SZV пишет:

Может быть внешние ключи можно установить неким более простым способом?

Судя по «mySQL 5.7-64» у вас установлен OpenServer? Там есть PhpMyadmin.
Зайдите туда, выберите вашу БД и выполните запрос
Для юзеров

alter table articles add foreign key articles_user_id_foreign (user_id) references users(id)

И для категорий

alter table articles add foreign key articles_category_id_foreign (category_id) references categories(id)

Ну и да. Вам уже написали

constb пишет:

…внешние ключи нужны только в связке с on cascade delete, on cascade update и on cascade set null

Благодарю. К таблице articles в индексах прописалась строка articles_user_id_foreign, но по прежнему нет строки  articles_category_id_foreign.
Блин, а есть более простой способ подключения внешних ключей к готовым таблицам?

#9 31.03.2017 04:44:24

Re: Ошибка SQLSTATE[42S21]

SZV, по-моему ты просто не понимаешь что такое внешний ключ в реляционных СУБД. это не поле, а ограничение (constraint). естественно у тебя никакой строки ниоткуда не появится. я третий и последний раз скажу это – тебе не нужен здесь foreign key

Я пытаюсь создать таблицу, которая была удалена ранее.

Но когда я делаю CREATE TABLE A ... Я получаю сообщение об ошибке ниже:

Отношение «А» уже существует.

Я подтвердил выполнение SELECT * FROM A, но затем получил еще одну ошибку:

Отношения «А» не существует.

Я уже пытался найти его в списке всех отношений dS+, но его там нет.
Чтобы усложнить ситуацию, я проверил это, создав эту таблицу в другой базе данных, и получил ту же ошибку. Я думаю, что это могло быть ошибкой, когда эта таблица была удалена. Любые идеи?

Вот код: я использую сгенерированный код из Power SQL. У меня такая же ошибка без использования последовательности. Это просто работает, когда я меняю имя, и в этом случае я не могу этого сделать.

CREATE SEQUENCE csd_relationship_csd_relationship_id_seq;
CREATE TABLE csd_relationship (
    csd_relationship_id INTEGER NOT NULL DEFAULT nextval('csd_relationship_csd_relationship_id_seq'::regclass),  
    type_id INTEGER NOT NULL,
    object_id INTEGER NOT NULL,
    CONSTRAINT csd_relationship PRIMARY KEY (csd_relationship_id)
);

Я наконец обнаружил ошибку. Проблема в том, что имя ограничения первичного ключа совпадает с именем таблицы. Я не знаю, как postgres представляет ограничения, но я думаю, что ошибка «Связь уже существует» была вызвана во время создания ограничения первичного ключа, потому что таблица уже была объявлена. Но из-за этой ошибки таблица не была создана в конце.


68

nsbm
12 Янв 2012 в 16:57

Другая причина, по которой вы можете получить такие ошибки, как «отношение уже существует», — это неправильное выполнение команды DROP.

Одна из причин, по которой это может произойти, заключается в том, что к базе данных подключены другие сеансы, которые необходимо закрыть в первую очередь.


4

isedwards
21 Сен 2018 в 14:58

В моем случае это было только после того, как я приостановил пакетный файл и немного прокрутил его вверх, это была не единственная ошибка, которую я получил. Моя команда DROP превратилась в DROP, поэтому таблица не удалялась в первую очередь (таким образом, связь действительно все еще существовала). Я узнал, что  называется меткой порядка байтов (BOM). Открыв это в Notepad ++, повторно сохраните файл SQL с кодировкой UTM-8 без спецификации, и он будет работать нормально.


2

Mogsdad
11 Янв 2016 в 22:03

В моем случае у меня была последовательность с таким же названием.


4

Dave Van den Eynde
25 Авг 2016 в 18:06

Иногда такая ошибка возникает, когда вы создаете таблицы с разными пользователями базы данных и пытаетесь SELECT с другим пользователем. Вы можете предоставить все привилегии, используя запрос ниже.

GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA schema_name TO username;

А также вы можете предоставить доступ для операторов DML

GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA schema_name TO username;


1

Akila K Gunawardhana
10 Ноя 2020 в 05:19

В моем случае я переходил с 9.5 на 9.6. Итак, чтобы восстановить базу данных, я делал:

sudo -u postgres psql -d databse -f dump.sql

Конечно, он выполнялся в старой базе данных postgreSQL, где есть данные! Если ваш новый экземпляр находится на порту 5433, правильный способ:

sudo -u postgres psql -d databse -f dump.sql -p 5433


0

Nicolas Boisteault
5 Окт 2016 в 13:30

Возможно, вы запускаете CREATE TABLE после того, как уже запустили его. Таким образом, вы можете создать таблицу во второй раз, а первая попытка уже создала ее.


1

ScottyBlades
14 Май 2021 в 22:03

Содержание

  1. Debugging “relation does not exist” error in postgres
  2. Нельзя просто использовать имя таблицы PostgreSQL («отношение не существует»)
  3. 7 ответов:
  4. Нельзя просто использовать имя таблицы PostgreSQL («отношения не существует»)
  5. org.postgresql.util.PSQLException: ОШИБКА: отношение «app_user» не существует
  6. 3 ответа
  7. Java SQL «ОШИБКА: отношение» Имя_таблицы «не существует»
  8. 4 ответы

Debugging “relation does not exist” error in postgres

So, i was getting this nasty error even when the table clearly existed in t11 database.

Even after lot of googling, debugging and trying Stackoverflow solutions, there was no resolution. Then i got a hunch, that i should check what database and schema were actually being used when done programmatically (even though dbname was clearly provided in connection string).

If you use database t11 by running c t11 and then run:

select * from information_schema.tables where table_schema NOT IN (‘pg_catalog’, ‘information_schema’)

It will tell you that userinfo5 does exist in t11 database. But what happens when we try to access it programmatically?

So, i ran above query in a golang function, the function which was earlier running query select * from userinfo5 where >

Output showed that database name which was actually being used was postgres and not t11 Why?

Because, my postgres user was configured to not use password. But my connection string had password= This was somehow confusing the DB driver and postgres database was being used and not t11 .

remove password= from connection string so that it looks like: “host=localhost port=5432 user=postgres dbname=t11 sslmode=disable”

  1. Alter user postgres so that it uses password: alter user postgres with password ‘pwd123’;
  2. Change connection string: “host=localhost port=5432 user=postgres password=pwd123 dbname=t11 sslmode=disable”

Источник

Я пытаюсь запустить следующий PHP-скрипт для выполнения простого запроса к базе данных:

это приводит к следующей ошибке:

ошибка запроса: ошибка: отношение «sf_bands» не существует

во всех примерах я могу найти, где кто-то получает ошибку о том, что связь не существует, это потому, что они используют прописные буквы в имени своей таблицы. Мое имя таблицы не имеет прописных букв. Есть ли способ запросить мою таблицу без включения имени базы данных, т. е. showfinder.sf_bands ?

7 ответов:

из того, что я прочитал, эта ошибка означает, что вы не ссылаетесь на имя таблицы правильно. Одна из распространенных причин заключается в том, что таблица определяется со смешанным написанием, и вы пытаетесь запросить ее со всеми строчными буквами.

другими словами, следующее терпит неудачу:

используйте двойные кавычки для разграничения идентификаторов, чтобы вы могли использовать конкретное смешанное написание, как определено в таблице.

Re ваш комментарий, вы можете добавить схему в «search_path», чтобы при ссылке на имя таблицы без уточнения ее схемы запрос соответствовал этому имени таблицы, проверяя каждую схему по порядку. Так же, как PATH в оболочке или include_path в PHP и др. Вы можете проверить свой текущий путь поиска схема:

вы можете изменить путь поиска схемы:

у меня были проблемы с этим и это история (печальная, но правдивая) :

если ваше имя таблицы все строчные, как: счета вы можете использовать: select * from AcCounTs и он будет работать нормально

если ваше имя таблицы все строчные, как: accounts Следующее не удастся: select * from «AcCounTs»

если ваше имя таблицы смешанный случай как: Accounts Следующее не удастся: select * from accounts

если ваше имя таблицы это смешанный случай как : Accounts Следующее будет работать нормально: select * from «Accounts»

Я не люблю вспоминать бесполезные вещи, как это, но надо 😉

запрос процесса Postgres отличается от других RDMS. Поместите имя схемы в двойную кавычку перед именем таблицы, например, «SCHEMA_NAME».»SF_Bands»

поместите параметр dbname в строку подключения. Это работает для меня, в то время как все остальное не удалось.

также, когда делаешь выбор, указать your_schema . your_table такой:

У меня была аналогичная проблема на OSX, но я пытался играть с двойными и одинарными кавычками. Для вашего случая, вы могли бы попробовать что-то вроде этого

для меня проблема заключалась в том, что я использовал запрос к этой конкретной таблице во время инициализации Django. Конечно, это вызовет ошибку, потому что эти таблицы не существовали. В моем случае это было get_or_create метод в пределах a admin.py файл, который выполнялся всякий раз, когда программное обеспечение выполняло какую-либо операцию (в данном случае миграцию). Надеюсь, это кому-то поможет.

я копал эту проблему больше, и узнал о том, как установить этот «search_path» по defoult для нового пользователя в текущей базе данных.

открыть Свойства базы данных, затем открыть лист » переменные» и просто добавьте эту переменную для вашего пользователя с фактическим значением.

Так что теперь ваш пользователь получит это schema_name по умолчанию, и вы можете использовать tableName без schemaName.

Источник

Нельзя просто использовать имя таблицы PostgreSQL («отношения не существует»)

Я пытаюсь запустить следующий скрипт PHP, чтобы выполнить простой запрос к базе данных:

Это приводит к следующей ошибке:

Ошибка запроса: ERROR: отношения «sf_bands» не существует

Во всех примерах я могу найти, где кто-то получает ошибку, указывающую, что отношения не существует, потому что они используют заглавные буквы в имени своей таблицы. В моем имени таблицы нет заглавных букв. Есть ли способ запросить мою таблицу без включения имени базы данных, то есть showfinder.sf_bands ?

Из того, что я прочитал, эта ошибка означает, что вы неправильно ссылаетесь на имя таблицы. Одной из распространенных причин является то, что таблица определена с орфографией с смешанным регистром, и вы пытаетесь запросить ее со всеми строчными буквами.

Другими словами, следующее не выполняется:

Используйте двойные кавычки, чтобы разграничить идентификаторы, чтобы вы могли использовать конкретную орфографию с смешанным регистром, поскольку таблица определена.

Повторите свой комментарий, вы можете добавить схему в «путь поиска», чтобы при ссылке на имя таблицы без квалификации ее схемы запрос соответствовал этому имени таблицы, проверив каждую схему в порядке. Точно так же, как PATH в оболочке или include_path в PHP и т. Д. Вы можете проверить свой текущий путь поиска схемы:

Вы можете изменить путь поиска схемы:

У меня были проблемы с этим, и это история (грустная, но правда):

Если имя вашей таблицы имеет нижний регистр, например: учетные записи, которые вы можете использовать: select * from AcCounTs и он будет работать нормально

Если ваше имя таблицы имеет все нижеследующее значение, например: accounts Следующие select * from «AcCounTs» не будут выполнены: select * from «AcCounTs»

Если ваше имя таблицы смешанно, например: Accounts : Accounts : select * from accounts

Если ваше имя таблицы смешанно, например: Accounts Следующие будут работать нормально: select * from «Accounts»

Я не люблю вспоминать бесполезные вещи, как это, но вы должны;)

Запрос процесса Postgres отличается от других RDMS. Поместите имя схемы в двойную кавычку перед именем вашей таблицы, например «SCHEMA_NAME». «SF_Bands»

Поместите параметр dbname в строку подключения. Это работает для меня, пока все остальное не удалось.

Также, когда вы делаете выбор, укажите your_schema . your_table :

У меня была аналогичная проблема с OSX, но я старался играть с двойными и одинарными кавычками. В вашем случае вы можете попробовать что-то вроде этого

Источник

org.postgresql.util.PSQLException: ОШИБКА: отношение «app_user» не существует

У меня есть приложение, в котором я использую spring boot и postgres. Я получаю эту ошибку, когда пытаюсь создать пользователя.

Когда я запускаю этот запрос в своей базе данных, я получаю ту же ошибку:

Но если я изменил это на:

Как мне настроить это приложение для загрузки spring?

зависимости в pom.xml:

Я вызываю это действие из формы:

и это мой контроллер:

Валидатор, который исправляет ошибку:

И репозиторий является интерфейсом CrudRepository и не имеет реализации:

И отлаживая валидатор, я мог бы получить этот стек:

Спасибо за помощь!

3 ответа

PostgreSQL соответствует стандарту SQL и в этом случае означает, что идентификаторы (имена таблиц, имена столбцов и т.д.) принудительно строятся в нижнем регистре, за исключением случаев, когда они цитируются. Поэтому, когда вы создаете таблицу следующим образом:

вы фактически получаете таблицу app_user . Вы, очевидно, сделали:

а затем вы получите таблицу «APP_USER» .

В Spring вы указываете правильную строку для имени таблицы заглавными буквами, но ее объединяют в запрос на сервер PostgreSQL без кавычек. Вы можете проверить это, прочитав файлы журнала PostgreSQL: он должен показать запрос, сгенерированный Spring, за которым следует ошибка в верхней части вашего сообщения.

Поскольку у вас очень мало контроля над тем, как Spring строит запросы от сущностей, вам лучше использовать идентификаторы нижнего регистра стандарта SQL.

Источник

Java SQL «ОШИБКА: отношение» Имя_таблицы «не существует»

Я пытаюсь подключить netbeans к моей базе данных postgresql. Кажется, что соединение сработало, поскольку я не получаю никаких ошибок или исключений при простом подключении, такие методы, как getCatalog (), также возвращают правильные ответы.

Но когда я пытаюсь запустить простой оператор SQL, я получаю сообщение об ошибке «ОШИБКА: отношение« TABLE_NAME »не существует», где TABLE_NAME — это любая из моих таблиц, которые ДЕЙСТВИТЕЛЬНО существуют в базе данных. Вот мой код:

Я думал, что netbeans может не находить таблицы, потому что он не ищет схему по умолчанию (общедоступную), есть ли способ установить схему в java?

РЕДАКТИРОВАТЬ: мой код подключения. Имя базы данных — Cinemax, когда я опускаю код оператора, я не получаю ошибок.

Разве нельзя так переписать sql? SELECT * FROM .clients — CoolBeans

Вы не показываете, как вы подключаетесь к серверу базы данных. Я подозреваю, что @CoolBeans верен выше или очень близко. Ваша таблица находится в другой схеме (что будет исправлено выше) или в другой базе данных, чем та, которую вы указали при подключении. — Brian Roach

Мне это нравится . не могли бы вы показать нам НАСТОЯЩУЮ ошибку? Я не думаю, что база данных говорит «отношение TABLE_NAME . », когда вы выполняете «select * from clients». — Szymon Lipiński

Я пробовал это, но получаю ту же ошибку: «ОШИБКА: отношение« public.clients »не существует» (то же самое для любой другой из моих таблиц). public — моя единственная схема, так что это также схема по умолчанию. Спасибо за помощь. — Matt

Установите для log_min_duration_statement значение 0 в postgresql.conf, перезапустите базу данных, запустите приложение и проверьте в журналах postgresql, какой реальный запрос отправляется в базу данных. И еще кое-что . вы на 100% уверены, что у вас есть стол? Можете ли вы подключиться к этой базе данных с помощью psql / pgadmin и выполнить там запрос? — Szymon Lipiński

4 ответы

Я подозреваю, что вы создали таблицу, используя двойные кавычки, например, «Clients» или какая-либо другая комбинация символов верхнего / нижнего регистра, поэтому имя таблицы теперь чувствительно к регистру.

Что означает заявление

Если возвращаемое имя таблицы не в нижнем регистре, вы должны использовать двойные кавычки при обращении к нему, что-то вроде этого:

ответ дан 24 апр.

Я пытаюсь использовать sequelize ORM, и в своем запросе на создание он использует кавычки в table_name. Спасибо за ответ. — Kiddo

Источник

Понравилась статья? Поделить с друзьями:

Интересное по теме:

  • Ошибка сервера при звонке на городской номер
  • Ошибка сервера сяоми
  • Ошибка сервера на пс3 404
  • Ошибка саут е1001
  • Ошибка сервера попробуйте позже вов сирус

  • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии