Собственно, само упоминание XSQLVAR должно отпугнуть от ответов тех, кто про него не знает. :-)

А вопрос такой.
Допустим, есть IBX, FIBPlus, FireDAC, или любые другие компоненты прямого доступа (это важно), которые сами по себе предоставляют доступ к XSQLDA и XSQLVAR.
Мне надо из TDBGrid, например из события



получить доступ к XSQLVAR конкретного столбца.

Собственно, на первый взгляд столбец (поле) выколупнуть вроде как все просто -
Column.Field
Но тут мы получаем TField, и значит надо или делать приведение типов (но не очень ясно, куда), или ...

Я пока зарылся в код IBX, пытаюсь найти, теряется XSQLVAR/XSQLDA при фетче записей в TField и буфер датасета, или нет. Если теряется, то это пипец.

Если прямо совсем конкретно, то мне нужен доступ к XSQLVAR.sqlind. Как его получить у IBSQL, - понятно. Как это получить у датасета - х.з.

Мимопроходящий, wadman

увы, все это не то. То, что внутри там IBSQL и параметры это XSQLVAR, все замечательно.
Проблема в том, что у IBSQL буфера нет. А мне надо понять, сохраняются XSQLVAR в буфере датасета, или нет. Похоже, что нет.

Собственно,
IBCustomDataSet.pas

TFiedData - данные столбца.
TRecordData - строка со столбцами TFieldData
и ... никаких XSQLVAR...

p.s. TIBCustomDataSet.Current вроде бы то что надо, но увы - он указывает только на последнюю фетченную запись.

Dimitry SibiryakovTField.IsNull не хватит?..

не-а. Embarcadero запихнуло флаги для Change Views в SQLIND. Там битами выставляется признак столбца - изменен, insert, update, delete. Я хотел его вытащить в DBGrid, чтобы показать, какие столбцы изменены при update, какие строки вставлены, удалены, и т.п.
Похоже, не судьба.

В данном случае единственный вариант - заполнять StringGrid (или типа того) из IBSQL. Здесь все прекрасно можно показать.

Мимопроходящийпидарасы, сэр! (с)
с другой стороны, без изменения API, больше почти некуда. :-)

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

Так что всем спасибо. А с компоненто-писателями я еще спишусь, может они что со своей стороны посоветуют.

Dimitry SibiryakovЭто что? Это как???
это новая фича у InterBase XE7.
т.н. "подписки на изменения", или ChangeViews .

В общем выглядит так. Создаешь подписку, перечисляешь таблицы, и те изменения, которые хочешь видеть (ins/upd/del).
Пока подписка не активирована, видишь обычные данные. Как только активируешь подписку - видишь только те изменения, которые были сделаны с момента последнего commit в твоей подписке.

То есть, я вчера сделал апдейт таблицы, сегодня insert, все давно закомичено.
А в тестовой подписке (которую я всегда отменяю по rollback, чтобы не задолбаться с постоянными изменениями таблиц), уже второй день вижу изменения - вчера только upd, а сегодня и update, и insert.

p.s. как это сделано физически, пока не знаю. Вижу только в IBAnalyst, что у этой таблицы только 1 версия, при двух видимых изменениях.

Dimitry Sibiryakov,

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

Dimitry Sibiryakov,

а! все ясно. у них есть rdb$subscribers, и там для подписчика указана последняя rdb$check_out_transaction_id, метка времени, и многое другое.

Симонов ДенисКстати сведения об изменениях там остаётся навсегда
журнала транзакций нет, просто блокируется сборка версий как мусора для тех изменений, которые нужно отслеживать.

изменения (версии) подчищаются после того, как в активной подписке сделать commit.

То есть, чтобы начать отслеживать изменения нужно сделать
set subscription x ... active;
rollback;

в принципе, до rollback можно выдать и inactive, это ничего не поменяет, изменения начнут отслеживаться. Внутри транзакции по active/inactive можно переключать, что видишь - либо актуальные данные, либо только изменения.

Чтобы прекратить отслеживание, делаешь
set subscription x ... active;
commit;
То есть, считается что перед commit ты "забрал" все изменения.

Вся эта фигня работает только в snapshot-транзакциях.
Если кому интересно - будет вебинар с Эмбаркадеро на эту тему 19 марта. 18 февраля будет вебинар по другим фичам ХЕ7.

dimitrsqlind меньше нуля (-1 в частности) это признак нулла, а больше нуля
именно (в т.ч. про рыбу)
http://docwiki.embarcadero.com/InterBase/XE7/en/Change_Views_API_Support

Dimitry Sibiryakov,

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

Dimitry Sibiryakov3) Т3 увидит изменения Т2, а Т4 увидит изменения Т1 И Т2
все вроде штатно. Т4 увидит изменения Т1 И Т2 потому что Т1 и Т2 завершились до старта Т4. Или я чего то не понял?
Почему Т3 не должна увидеть изменений Т2, или Т4 не должна увидеть изменений Т2?

Я бы еще понял вопрос, что будет с изменениями, которые были сделаны и закоммичены во время работы Т3 и Т4. Но и тут есть ответ - при commit подписки сохраняются изменения, сделанные с момента старта транзакции, которая получала подписку.

Dimitry SibiryakovPPS: Какой план даёт чтение изменений я стараюсь не думать.
х.з., не проверял. наверное, ты хотел спросить, какой результат будет при чтении изменений с where? :-)

Dimitry SibiryakovПотому что их уже вычитала Т3 и закоммитилась.
а, понял.

Тогда подписка Т4 увидит только изменения Т1, потому что действительно, изменения в Т2 уже вычитаны подпиской в Т3.

То есть, твой пункт 1.

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

Dimitry Sibiryakovспособ которым они такого эффекта достигают.
эээ, ну ведь известны номера транзакций, и т.д.

тут еще вот в чем фокус. чтобы подписка вообще "началась", ее нужно активировать. Поэтому, собственно, в твоем сценарии, если подписка N, упоминаемая в Т3, ни разу до этого не активировалась, то никаких изменений она не увидит. Потому что она началась только в Т3.
Извиняюсь, если ввел в заблуждение. изменения отслеживаются только с момента первой активации подписки

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

Dimitry Sibiryakov,

ну тогда подписка в Т3 увидит изменения в Т2. А подписка в Т4 увидит изменения с момента начала транзакции Т3.

Dimitry Sibiryakov,

В ХЕ7 не так.
Подписка - это что-то типа view, в котором прописано какие таблицы надо отслеживать, какие столбцы, и какие действия.
пользователю выдаются права на конкретную подписку
Далее пользователь может активировать подписку, причем обязательно указывая некое имя (типа "устройство"), откуда он получает изменения по этой подписке.
Так что у одного юзера может быть несколько подписок - на мобиле, в офисе, дома и т.п.

Что касается видимости, то
- юзер получает изменения, произошедшие с момента активации подписки. Получает он их в транзакции snapshot. commit в этой транзакции сигнализирует о том, что юзер получил все изменения, которые произошли ДО СТАРТА этой snapshot-транзакции.
А чтобы активировать подписку и сидеть ждать изменений, нужно сделать
subscription active
тут можно даже inactive сделать
rollback

то есть, активация-деактивация подписки вместе с commit/rollback определяет, что будет дальше с этой подпиской - активна или нет, получаем изменения или смотрим реальные данные. Выключается подписка только по inactive+commit;

Dimitry SibiryakovТо есть изменения, полученные для одного устройства будут уже не видны для этого же
устройства, но для других устройств они будут всё ещё видны?
идентификатором подписчика является Имя_пользователя[+имя_устройства].



указание at - необязательное.

NikolayV81с какого момента начинается логирование наличия изменений?
Со старта транзакции в которой :
set SUBSCRIPTION <subscription_name> AT <destination> ACTIVE
COMMIT;
вроде как невозможно, т.к. журнала нет и придётся привентивно все изменения с момента старта любой транзакии помнить

ыыыы...
set subscription active включает отслеживание изменений, которые были с момента старта транзакции, в которой было вот это active.
при этом commit сигнализирует о том, что изменения, которые были до старта этой транзакции, уже получены.
Чтобы отслеживать изменения дальше, и после завершения транзакции, надо сделать rollback.
active
rollback

я выше об этом писал 2 раза. в rdb$subscribers запоминаются параметры транзакции, с которой нужно отслеживать изменения. Они меняются на текущую транзакцию по commit. чтобы их не менять, т.е. оставить стартом исходную транзакцию с первым active, нужно сделать rollback.

далее, active/inactive меняют вывод операторов. После inactive выводятся все существующие данные. после active - только измененные с момента начала отслеживания подписки.

Еще более популярно.

1. коннект
2. стартуем снапшот
3. получаем обычные данные
4. set subs active
5. получаем изменения, с момента первого active/rollback или последнего active/commit

теперь, допустим, делаем
6. rollback (подписка остается активной, даже если сделать inactive, т.к. изменения мы не получили)
7. disconnect
8. connect
9. старт транзакции
10. тут мы получаем ОБЫЧНЫЕ данные. Потому что сервер в этот момент не имеет понятия, что мы - это мы, и у нас активна подписка. Вернее, он может догадаться, что мы - это мы, но это ему не нужно.
11. set subs active
12. ура, видим те же изменения, что получали в пункте 5.
13. нам надоели изменения, делаем inactive
14.1. теперь, если тут сделать rollback, то все можно повторить с пункта 7, и мы в пункте 12 увидим те же изменения
14.2. если тут сделать commit, подписка прекратит отслеживать изменения. если же не было пункта 13, то подписка останется активной, но в следующий раз мы будем видеть только те изменения, которые произошли с момента пункта 9.

Dimitry SibiryakovЯ так и думал, что они кусок TIP-а в блоб загоняют...
там и tip, и еще туча сохраненных маркеров, причем, часть из них вроде как на будущее, или я пока не понял, зачем.

NikolayV81а как определяется что запись удалена (она же физически отсутсвует)?
удаление записи в версионнике - это создание новой версии. Версия просто содержит признак удаления, а не измененные столбцы, как при update.
В snapshot ты же видишь удаленные другими транзакциями записи во время этого снапшота? Потому что продолжают существовать удаленная "версия/запись" и версия с признаком удаления.

Я ведь писал, что активация подписки замораживает сборку мусора. А модифицированный движок сервера дает возможность увидеть не только что было модифицировано или добавлено, но и что было удалено.
То есть, активная подписка превращается в нечто вроде долгоживущего снапшота, со всеми вытекающими последствиями в виде накопления версий, правда, только для тех объектов и действий, которые указаны в подписке, а не для всех таблиц БД.

NikolayV81,

проще всего пример с insert. Если активация подписки произошла в транзакции 1000, значит для вытаскивания изменений с момента активации такой подписки достаточно выбрать все версии, у которых transaction id >=1000.
Для update - то же самое. Для delete - ищем версии с delete stub >=1000, показываем предыдущую версию.

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

NikolayV81Но нет гарантии что не затёрты
ты подзабыл версионность.
если с утра стартануть (просто стартануть, и все) транзакцию snapshot, и продержать ее до вечера, то к вечеру ни одна созданная версия, никакая, не будет "затерта".
Change views - это имитация долгоживущих снапшотов, с определенными изменениями движка. 17249727