Russian Qt Forum

выполняю примерно такой запрос INSERT INTO `table` (`name`) VALUES('No name')
как мне получить id который был присвоен только что вставленной записи?
например phpMyAdmin после записи пишет что то вроде:Inserted row id: 14
база MySql

SELECT LAST_INSERT_ID();

а тоесть id сам не возвращается, прост о не хотел делать дополнительных запросов, спс

C++ (Qt)
...
QSqlQuery query(db);
...
if query.exec("INSERT INTO `table` (`name`) VALUES('No name')"){
       qDebug()<<"last inserted id:"<<query.lastInsertId().toString();
};
 

Фактически, запрос всё равно делается. Вот в Оракле для этого не нужно делать дополнительного запроса :)

Для данных целей в FB использовал такой метод

1) сам дергал генератор для получения ID
2) использовал это полученное ID для вставляемой строки, тем самым уже зная его

Все это в связи с тем что в пределах выполняемой транзакции нельзя было увидеть ID вставленной строки до подтверждения или отмены ее.

Может быть еще как то returning может помочь (сам не использовал - была дискуссия в теме про альтернативный драйвер Qt FB).

В SQLLite есть полезная системныя таблица для этих целей.

Как рад, что пользуюсь Postgres. Все ваши БД отстают по удобству использования.


В очень мною ненавидимом оракле 10 приходиться делать связывание OUT переменных, что как оказалось чревато сегфолтом, если под данную переменную не выделить память, хотя бы вот так QVariant(QString(' ', 10)). Первичный ключ текстовый в данном случае.
В целом оракл оставляет желать лучшего в плане удоства программирования. Взять хотя бы невозможность навески одного триггера на несколько таблиц. Или невозможность модификации сиквенса. Кто там из менеджеров/инженеров вообще додумался до такой хрени, а?

В Firebird 2.1 такой запрос вполне корректно работает и возвращает значение вставленного ID
Уверен и во многих других БД это рабоатет, вопрос был в том что returning не поддерживался стандартным драйвером Qt для Interbase/Firebird.

Сомнительное решение

Зачем это нужно? Триггеры для отработки эконом. логики все равно для каждой таблицы свои, поля то в таблицах разные. А триггеры формирования пустых ROW_ID или подобные настолько просты, что нет проблем их иметь кадждый на свою таблицу.

ROW_ID в данном случае псевдо-колонка? Если да, это костыль. Если это имя столбца, то API firebird client библиотеки возможно непродумано. В постгри клиенте есть одна большая PGresult* PQexec(SQL_STRING); Соответственно Кутешники поняли, что какой бы SQL пользователь не выполнил ему всегда надо отдать QSqlResult пусть даже пустой.

Не спорю. Но даже на int64(простите не знаю имя типа oracle), нужно сделать как минимум QVariant(QVariant::qlonglong) для OUT переменной и только после сделать addBindValue.

Есть такая занимательная игра у менеджеров, называется "больше велосипедов, хороших и красивых". Задача: самодельная репликация для оракла. Если бы у меня была возможность навесить один большой триггер на все таблицы, я бы в нем используя хм... "интроспекцию" делал insert|update|delete в прилинкованную базу.
Итого: репликация отключается/включается одним большим триггером, который потом для скорости переписывается на сях. У вас тоже можно писать модули на сях?
Ан нет я сейчас буду лепить триггера, много хороших и красивых.

Вы имеете ввиду автогенерацию значений для первичных и не обязательно ключей?
Сравните

Который разворачивается в
И вот уже никаких триггеров не нужно для такой задачи.


Кстати как-то увидел:

это не псевдо колонка, а обычная колонка, кстати по сути конкретно от FB в Postgre модификатор RETURNING мало чем отличается.
FB поддерживает UDF как и многи сервера БД

да
И что это круто?
А такое типа не круто:

Я вот например не уверен на 100% что спецописания полей лучше использовать для автогенерации значений, чем триггеры - как минимум одинаково. Преимущество триггеров в их модульности, возможности навесить несколько триггеров и упорядочить их, для спец логики нельзя же вводить новые спец описания на таблицу - например если нельзя удалять запись с ID=1, или со списком ID хранящихся в другой таблице.

Это скорее игры умников программистов старающихся выпендриться, перед менеджерами стоят как правило типовые задачи учета и анализа.
Вообще задача триггера для таблицы сработать и выполнить код в момент событий вставки, удаления, обновления записи. Непонятно как для разных таблиц можно использовать в таком случае один код. Но уж если сильно хочется можно написать Хранимую Процедуру, части которой переписаны на Сях и вызывать ее из триггеров заглушек расставленных по таблицам.

А вообще задача кажется весьма надуманной и неконкретной - скорее для писькомерства Postgre с другими БД.

Дело вкуса. Предпочитаю лениться. Моя крутизна в том, что у меня одна строка делает одну функцию (автоинкремент). Мне не нужна мощность/расширяемость.

В том числе. Но речь таки не об этом. Речь действительно о пипиське. У postgre самая большая из открытых программ. И далеко не самая маленькая среди коммерческих баз данных.

Я предпочитаю лениться, а не выпендриваться, соответственно, писать все 78 триггеров на таблицы мне не улыбается никак. А готовая репликация для оракла стоит денег, которых соответственно нет.

Если Вам не сложно, дайте задачу реалистичнее и мы с Вами будем меряться.

Мне нет никакого интереса меряться, более того я не уверен что postgre не самая крутая БД. Может и самая. Но это не важно. Будет интерессная прибыльная задача с которой не справится FB или по Т.З. нельзя будет его использовать, я буду изучать что-то другое, пока мне это не нужно.