[решено] Отсутствует ID, SQLQuery как сохранять?

[vitaly_l]

смелые вы ребята - полагаетесь на интеллект (или наоборот тупорылость) весьма примитивного SQL-парсера SQLDB

debi12345, а как парсер определяет самостоятельно уникальный ли ID ??? Согласно запросу к базе, он(парсер) запроса позволяющего определить ключ это или не ключ - не делает. Однако уникальность праймари определяет на все 100% безошибочно. Как он(парсер) это делает?


.

[debi12345]

Как он(парсер) это делает?

Он по результатам парсинга определяет с какой таблицей работать (надежность этого вообще никакая - я категорически на это не закладываюсь в случае запросов к 2+ таблицам), а затем средствами драйвера запрашивает (через БД-API) у БД структуру этой таблицы - в том числе ее первичный ключ. Проблема тут в том, что таблица может иметь первичный ключ в виде уникального индекса, но не указанный явно как первичный ключ (CONSTRAINT <name> PRIMARY KEY (id)), также табличные результаты могут возвращаться SET-функциями, а не таблицами.

[vitaly_l]

а затем средствами драйвера запрашивает (через БД-API) у БД структуру этой таблицы - в том числе ее первичный ключ.

А в лог он этого не пишет. Поэтому я и не увидел. Ваш метод с помощью WireShark, ещё не пробовал изучаю "акулу".

Проблема тут в том, что таблица может иметь первичный ключ в виде уникального индекса, но не указанный явно как первичный ключ (CONSTRAINT <name> PRIMARY KEY (id)), также табличные результаты могут возвращаться SET-функциями, а не таблицами.

Ну здесь, я с трудом понимаю. Но понимаю, что там нужно уже реально знать, явно больше, того, что я знаю.

А вот ещё вопрос. Например у меня таблица в которой индекс сразу по 5 полям. типа такого:

Код: Выделить всё

CREATE UNIQUE INDEX im_index ON table(a,b,c,d,e);

Вот такой индекс, парсер, почему-то не определяет (согласно логу).
Парсер, лазаруса, в принципе умеет такие индексы определять своими SET-функциями ? (не знаю что такое SET-функции)



.

[debi12345]

Вот такой индекс, парсер, почему-то не определяет (согласно логу).

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

Добавлено спустя 7 минут 28 секунд:

не знаю что такое SET-функции

SQL-функции F_ * и FV_* в следующих БД-структурах:

Код: Выделить всё

CREATE TABLE ref_suppl_index (
   id SERIAL4 NOT NULL,
   code INTEGER NOT NULL,
   name INTEGER NOT NULL, /*индекс*/
   company_code INTEGER NOT NULL,
   catalog_code INTEGER NOT NULL,
   indexes_ss INTEGER[],
   indexes_retail INTEGER[],
   date_input DATE,
   date_activ DATE,
   date_deactiv DATE,
   oper_code INTEGER,
   rec_state INTEGER
);
----------------------------
CREATE OR REPLACE VIEW "v_suppl_index" AS SELECT
   id,
   code,
   name, /*индекс*/
   company_code,
   catalog_code,
   indexes_ss,
   indexes_retail
FROM ref_suppl_index;
----------------------------
CREATE OR REPLACE FUNCTION "f_suppl_index"(date_activ date) RETURNS SETOF "int4" AS $BODY$
select
   max(a.id)
from
   ref_suppl_index a
inner join (
select
   max(date_activ) as date_activ,
   code
from
   ref_suppl_index
where
  ($1 >= date_activ)
and
  (($1 < date_deactiv) or date_deactiv is null)
group by code
) b
using
   (code,date_activ)
group by
   a.code;
$BODY$ LANGUAGE 'sql' VOLATILE COST 100 ROWS 1000;
----------------------
CREATE OR REPLACE FUNCTION "fv_suppl_index"(date_activ date) RETURNS SETOF "v_suppl_index" AS $BODY$
select
   id,
   code,
   name, /*индекс*/
   company_code,
   catalog_code,
   indexes_ss,
   indexes_retail
from
   ref_suppl_index a1 inner join f_suppl_index($1) a2 on a1.id=a2
$BODY$ LANGUAGE 'sql' VOLATILE COST 100 ROWS 1000;


вызывается :

Код: Выделить всё

SELECT * FROM FV_SUPPL_INDEX('01.04.2015'::DATE)

возвращает причесанный набор данных в формате таблицы REF_SUPPL_INDEX.

[Alex2013]

Кстати, как запросы с LIMIT работают? ( там как я понимаю вообще просто порядковый номер записи )... SELECT rowid, * FROM TAB_1 LIMIT 0,5;

Может и на запись/изменение есть подобный фокус ?

Если нет придется делать вначале SELECT rowid FROM TAB_1 LIMIT My_Index ,1;
А потом например UPDATE TAB_1 SET NAME="5555 " WHERE ROWID=My_Rowid ;

А ещё AUTO_INCREMENT(он же rowid?) странно ведет себя при удалении произвольной записи (в тех записях что ниже rowid не меняется ....и даже вроде может дублироваться при вставке новой строки )...