iBase.ru Forum

Вопрос, наверное, кому-то уже набивший оскомину.
Но тем не менее.
Понятно, что можно вытащить так так понимаю, как в mssql, глобальной переменной(поля) нет?

RoloTomasi писал(а):Вопрос, наверное, кому-то уже набивший оскомину.
Но тем не менее.

Оскомину - это слишком мягко сказано. У хранителей святыни палец пляшет на курке (С). Так что бегом на www.ibase.ru и читать статью про генераторы. В перевую очередь про то, почему ТАК ДЕЛАТЬ НЕ НАДО! Если чего непонятно - читать ещё раз.

Не совсем понял почему так делать не надо?
Мне надо получить значение identity(в понимании фб - тригер + генератор) поля в таблице после вставки записи Т.е. у таблицы есть тригер(bi) и генератор обеспечивающие "последовательные" значения для "identity" поля, надо узнать его значение после вставки.
Статья прочитана много раз.
Кроме того, по моему в ней приводиться этот пример для получения текущего значения генератора.
Мне интересно, возможно вытаскивать это значение как с @@identity, без указания имени генератора?
Вроде где-то слышал про такое но насколько помню с птицей это не проходит?

RoloTomasi писал(а):Не совсем понял почему так делать не надо?

Сейчас проснётся kdv и засветит в лоб бейсбольной битой. Патамушта не то сегодня не то вчера он это в 34678-й раз на этом форуме разжёвывал. А про rdb$db_key если ты только "где-то слышал", то его тебе точно лучше не трогать.

Не согласен, если я просто хочу получить текущее значение генератора, после вставки записи, это вполне нормальный случай.

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

А насчет DB_KEY потому и спрашиваю если кто в курсе.

RoloTomasi писал(а):Не согласен, если я просто хочу получить текущее значение генератора, после вставки записи, это вполне нормальный случай.

Мляяя... Ну, напросился. Да плевать мне, что ты несогласен. И мирозданию в целом тоже. Цитирую упомянутую статью через клипборд:
___________________
При работе в многопользовательских средах будьте внимательны - в то время как вы получили "текущее" значение генератора, другое приложение может его изменить, и таким образом "текущее" значение окажется устаревшим.
___________________

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

RoloTomasi писал(а): А насчет DB_KEY потому и спрашиваю если кто в курсе.

Детям спички не игрушка. Особенно таким.

Ну хамить не надо я тоже могу,
прочитай внимательно название моего топика "Аналог @@identity".
Если ты не в курсе то эта глобальная переменая тоже меняется при работе в многопользовательском режиме.
Кроме того мне именно и надо это текущее "устаревшее" значение вставленной записи, а не последнее значение генератора.
Если не всосал помолчи, а то отвечу "мягко", а не охота в баню .
Спокойствие, только спокойствие.
Специально объяснил что мне надо.

Merlin писал(а):А чуть выше написано, что значение генератора надо получать с клиента ДО вставки записи и написано КАК.

И приводится именно тот select.
Ещё раз подчеркну, мне не надо растолковывать о правильности, понимаю не хуже уж тебя точно, мне интересна возможность вытащить это значение без указания имени генератора. И все, учить будешь кошака своего.

Нет, это просто звездец.

Значение генератора было 0.

Insert into Table (Attributes).

ID - опущено, знач ставит триггер. Посредством Gen_ID(Generator_ID,1)
Значение генератора 1.

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

Теперь до первого соединения дошла благая весть о том, что инсёрт прошёл и оно делает

select gen_id(Generator,0) from rdb$database

и получает ессно 2. И это вовсе не ID вставленной ей записи, а совсем другой. И потому и говорят, что если значение понадобится на клиенте, то его надо сначала захватить, чтоб никому оно больше не досталось, а потом вставлять уже с ним, твёрдо зная, что оно может относиться только к этой записи. И никак не наоборот. Как с любым другим конкурентным ресурсом. Сначала захватить, потом пользовать, в том числе читать-смотреть, а не наоборот. А значение генератора в любой момент говорит только о том, сколько раз к нему неважно кто и когда, только что или год назад, обращался.

И всё это там написано. Ей-богу мой кошак понятливее будет.

RoloTomasi писал(а):

Merlin писал(а):А чуть выше написано, что значение генератора надо получать с клиента ДО вставки записи и написано КАК.

И приводится именно тот select.

Да ни хрена не тот.

RoloTomasi писал(а): Ещё раз подчеркну, мне не надо растолковывать о правильности, понимаю не хуже уж тебя точно,

Кто б сомневался.

RoloTomasi писал(а): мне интересна возможность вытащить это значение без указания имени генератора. И все, учить будешь кошака своего.

select count(*) from rdb$generators

COUNT
===========

298

И которого из них без указания имени барин состояния желает?

Слушай че ты такой сложный?
Не надо мне объяснять, что как и почему, ёщё раз повторю.
НЕ НАДО, Я НЕ ПРОШУ!!! Настойчивый вы наш!

Насчет без имени, я поэтому и спрашиваю, есть или нет.
То, что генераторов куча и т.д. и т.п. понятно,
но в моем случае мне надо именно то, что мне надо, а не тебе.
Использование @@identity тоже считается дурным тоном, и много ещё чего не стоит делать, но каждый выбирает компромис исходя из того, что ему надо, есть и может получиться.
Ты мне три поста "обяснял" что не надо юзать DB_KEY, я не собирался его использовать, это была как новодка какой приблизительно функционал из ИБ мне нужен.
Надо мне будет именно до вставки я сделаю это, надо после сделаю так, я спрашивал не об этом.
Я не спрашивал что будет и почему!!!!
Можно просто и коротко ответить - нет, без имени нет возможности.
Или дать совет по ТЕМЕ.
Я рад что у тебя такой умный кошак, ёханый бабай.

Ещё раз спокойно объясню.
В mssql есть такая глобальная переменная @@identity.
После каждой вставки в таблицу с полем IDENTITY(в каждой таблице может быть только одно такое поле) ей присваивается значение этого поля(после вставки). В базе может быть куча таблиц и если после вставки записи в интересующую нас таблицу вставили запись в другую таблицу с IDENTITY мы получим именно её значение(последнего инсерта), а не то, что нас интересует. Порой учитывая обстоятельства,(особенности реализации) при нимают и работают с ней и все нормально. Почему причин может быть много.
Когда надо юзают IDENT_CURRENT('table_name'), иногда SCOPE_IDENTITY( )
и т.д. и т.п.
Меня, вполне устраивает именно вариант с @@identity. Я прекрасно понимаю что и почем.
Кроме того, там тоже куча полей с IDENTITY(как и генераторов в ФБ).
Прекрасно понимаю, что это не одно и тоже и кроме того, можно реализовать запись последнего значения последнего взведенного генератора куда-то, и это не совсем "правильно", тем не менее спросил, есть подобное в ФБ.

Кроме того, может у меня база embedded(а именно так и есть).
Короче, надеюсь ты усвоил сабж и успокоился
Миру мир.
Скажем ты не понял меня, а я тебя, о'кей.
Доброта спасет мир

RoloTomasi писал(а):Не согласен, если я просто хочу получить текущее значение генератора, после вставки записи, это вполне нормальный случай.

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

RoloTomasi писал(а):Это криминально когда пытаются использовать значения генератора не "запуская" сам генератор, для тех же целей identity при вставки записи.

IDENTITY - самое идиотическое 'решение' проблемы генерации значений, какое только можно придумать. В FB его не было, нет и не будет. Сейчас есть единственный способ - сгенерировать значение до вставки и использовать его. В FB2 есть INSERT ... RETURNING

RoloTomasi писал(а):А насчет DB_KEY потому и спрашиваю если кто в курсе.

DB_KEY тут абсолютно не в кассу. Его ещё можно было бы применить при UPDATE, но никак не при INSERT

Если очеш гемороя, то сделай себе external table, по тригеру заполняй там свое знаечние переменной. Эта таблица будет лежать вне контекста транзации. И будет иметь только одной последнее значение.

А. Так тут выездная сессия конгресса практической проктологии. Виноват, сразу не сообразил. Обычно уклоняюсь от участия.

hvlad писал(а): IDENTITY - самое идиотическое 'решение' проблемы генерации значений, какое только можно придумать. В FB его не было, нет и не будет. Сейчас есть единственный способ - сгенерировать значение до вставки и использовать его. В FB2 есть INSERT ... RETURNING
DB_KEY тут абсолютно не в кассу. Его ещё можно было бы применить при UPDATE, но никак не при INSERT

Насчет идиотического решения согласен, ,
но дело в том, что оно устраивает.

Приложение работало с mssql, к нему подцепили ещё возможность работы с ФБ(т.е. можно работать с любым из двух движков).
Все вопросы совместимости решены кроме этого @@identity в одном месте.

Использовать "лишние" процедуры и триггеры(кроме для полей автоинкремента) крайне нежелательно, потому как ещё есть синхронизатор, который отслеживает структуру базы и в случае её изменения корректирует её. Т.е. структура должна быть простой.

Подчеркну ещё раз, что все "особенности" как @@identity так и получения текущего значения генератора после инсерта известны и они устраивают. И приложение предназначено только для работы в однопользовательском режиме.

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

eugeney писал(а):Если очеш гемороя, то сделай себе external table, по тригеру заполняй там свое знаечние переменной. Эта таблица будет лежать вне контекста транзации. И будет иметь только одной последнее значение.

Была такая мысль. В тех же тригерах(BI) что автоинкрементят реализовать.
Но надо ещё подумать.

Merlin писал(а):А. Так тут выездная сессия конгресса практической проктологии. Виноват, сразу не сообразил. Обычно уклоняюсь от участия.

А зря как раз к 12-му числу успеем дойти до update rdb$pages ...

Merlin писал(а):А. Так тут выездная сессия конгресса практической проктологии. Виноват, сразу не сообразил. Обычно уклоняюсь от участия.

Ты прав, основная тема -
"Коланоскопия - эфективнейший метод улучшения всасывания информации отдельных сапиенсов"