Ошибка синтаксиса примерное положение create

2 / 2 / 1

Регистрация: 06.10.2021

Сообщений: 58

Выполняю некоторое задание по вузу, в ERBuilder создаются таблицы, связи между ними задаются, добавляются последовательности(или триггеры), чтоб первичный ключ постоянно назначался сам при добавлении записи, и добавляются функции на удаление, добавление или обновление записей в таблице. При попытке переноса готовой БД из ERBuilder в pgadmin4 (PostgreSQL 13) выдаёт такую ошибку. При этом, таблицы со всеми колонками и ключами создаются в БД, но перенос ломается либо на стадии создания функций вставки, удаления и обновления, либо на стадии создания последовательности. Не понимаю, как устранить ошибку, пробовал по-разному писать данное выражение, пробовал добавлять название в скобки, добавлял начальное значение, от которого стартует отсчёт последовательности( «START 0» ввёл после названия) .Ниже будут некоторые скрипты, которые относятся к проблеме
Скрипт создания таблицы

1
2
3
4
5
6
7

CREATE TABLE "Postavshik" ( 
  "id_postavshik"           INTEGER NOT NULL,
  "nomer_car"               CHAR(40),
  "adres_postavshika"       CHAR(40),
CONSTRAINT "PK_6" PRIMARY KEY ("id_postavshik")
) 
;

Скрипт триггера для таблицы Postavshik

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

/*============================================================================*/
/*                                  TRIGGERS                                  */
/*============================================================================*/
CREATE SEQUENCE id_postavshik_gen;
CREATE OR REPLACE FUNCTION Postavshik_GEN_ID()
RETURNS TRIGGER AS
$Postavshik_GEN_ID$                      
BEGIN
    NEW.id_postavshik =
        NEXTVAL(‘id_postavshik_gen’::regclass);
    RETURN NEW;
END;
$Postavshik_GEN_ID$
LANGUAGE plpgsql;
CREATE TRIGGER Postavshik_TRIG_ID
BEFORE INSERT ON Postavshik
FOR EACH ROW EXECUTE PROCEDURE Postavshik_GEN_ID();

После первых же строк данного триггера мне выдаёт ошибку, дословно:
«CREATE SEQUENCE id_postavshik_gen
ошибка синтаксиса (примерное положение: ‘CREATE’)»

Добавлено через 16 минут
ШТОШ, проблема в том, что нет «;» после кжадй процедуры, из-за этого CREATE он не понимал

Syntax errors are quite common while coding.

But, things go for a toss when it results in website errors.

PostgreSQL error 42601 also occurs due to syntax errors in the database queries.

At Bobcares, we often get requests from PostgreSQL users to fix errors as part of our Server Management Services.

Today, let’s check PostgreSQL error in detail and see how our Support Engineers fix it for the customers.

What causes error 42601 in PostgreSQL?

PostgreSQL is an advanced database engine. It is popular for its extensive features and ability to handle complex database situations.

Applications like Instagram, Facebook, Apple, etc rely on the PostgreSQL database.

But what causes error 42601?

PostgreSQL error codes consist of five characters. The first two characters denote the class of errors. And the remaining three characters indicate a specific condition within that class.

Here, 42 in 42601 represent the class “Syntax Error or Access Rule Violation“.

In short, this error mainly occurs due to the syntax errors in the queries executed. A typical error shows up as:

Here, the syntax error has occurred in position 119 near the value “parents” in the query.

How we fix the error?

Now let’s see how our PostgreSQL engineers resolve this error efficiently.

Recently, one of our customers contacted us with this error. He tried to execute the following code,

CREATE OR REPLACE FUNCTION prc_tst_bulk(sql text)
RETURNS TABLE (name text, rowcount integer) AS
$$
BEGIN
WITH m_ty_person AS (return query execute sql)
select name, count(*) from m_ty_person where name like '%a%' group by name
union
select name, count(*) from m_ty_person where gender = 1 group by name;
END
$$ LANGUAGE plpgsql;

But, this ended up in PostgreSQL error 42601. And he got the following error message,

ERROR: syntax error at or near "return"
LINE 5: WITH m_ty_person AS (return query execute sql)

Our PostgreSQL Engineers checked the issue and found out the syntax error. The statement in Line 5 was a mix of plain and dynamic SQL. In general, the PostgreSQL query should be either fully dynamic or plain. Therefore, we changed the code as,

RETURN QUERY EXECUTE '
WITH m_ty_person AS (' || sql || $x$)
SELECT name, count(*)::int FROM m_ty_person WHERE name LIKE '%a%' GROUP BY name
UNION
SELECT name, count(*)::int FROM m_ty_person WHERE gender = 1 GROUP BY name$x$;

This resolved the error 42601, and the code worked fine.

[Need more assistance to solve PostgreSQL error 42601?- We’ll help you.]

Conclusion

In short, PostgreSQL error 42601 occurs due to the syntax errors in the code. Today, in this write-up, we have discussed how our Support Engineers fixed this error for our customers.

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;

CREATE TABLE screens_items (
	screenitemid             bigint                                    NOT NULL,
	screenid                 bigint                                    NOT NULL,
	resourcetype             integer         DEFAULT '0'               NOT NULL,
	resourceid               bigint          DEFAULT '0'               NOT NULL,
	width                    integer         DEFAULT '320'             NOT NULL,
	height                   integer         DEFAULT '200'             NOT NULL,
	x                        integer         DEFAULT '0'               NOT NULL,
	y                        integer         DEFAULT '0'               NOT NULL,
	colspan                  integer         DEFAULT '0'               NOT NULL,
	rowspan                  integer         DEFAULT '0'               NOT NULL,
	elements                 integer         DEFAULT '25'              NOT NULL,
	valign                   integer         DEFAULT '0'               NOT NULL,
	halign                   integer         DEFAULT '0'               NOT NULL,
	style                    integer         DEFAULT '0'               NOT NULL,
	url                      varchar(255)    DEFAULT ''                NOT NULL,
	dynamic                  integer         DEFAULT '0'               NOT NULL,
	sort_triggers            integer         DEFAULT '0'               NOT NULL,
	application              varchar(255)    DEFAULT ''                NOT NULL,
	PRIMARY KEY (screenitemid)
);

psql --version
psql (PostgreSQL) 9.4.9 

А БДЕ — (СКуэЛь експлорер) — все прекрасно работает

Работает, потому что в LocalSQL есть такой тип поля.

> CREATE TABLE PLUCASH … ARTICUL …
;о) супермаг dos. ;о)

просто
MESPRESISI NUMERIC
и все без всяких (16,6). поддерживается только емулируемый тип (под double) с размерностью 20,5 который и будет создан по умолчанию. без указаний.

но это тебе конечно не поможет. -> супермаг… %о)

> в каком хлп-файле нарыть типы полей поддерживаемых АДО…
Jet — JETSQL40.CHM. а АДО поддерживает все что поддерживает подключаемый драйвер/провайдер. кроме разных мелких досадных недоразумений. (бигинт…)

Но ведь не может быть такого, чтобы в ADO не было аналогичного типа….

Почему не может? Может. Зависит от завихрений автора используемого провайдера. Кроме того, этот типа там может просто называться по другому.

Блин, как бы мне этого не хотелось — а пришлось делать через «ж..у»:

  dbMag.ConnectionString:=
  "Provider=MSDASQL.1;Persist Security Info=False;"+
  "Extended Properties="DSN=Òàáëèöû Visual FoxPro;UID=;"+
  "SourceDB="+PathMag+";SourceType=DBF;Exclusive=No;"+
  "BackgroundFetch=Yes;Collate=Machine;Null=Yes;"+
  "Deleted=Yes;"";
  dbIK.ConnectionString:=
  "Provider=Microsoft.Jet.OLEDB.4.0;Data Source="+PathIK+
  ";Extended Properties=dBase IV;Persist Security Info=False";

т.е. для разных запросов — разные типы полключения:
для таблиц FoxPro — MSDASQL,
а для dBase — Microsoft.Jet.OLEDB

Утешает, что в предыдущих версиях был еще БДЕ, а тут его не будет…