А вот если у меня на одном конце приложения один сервер, а на другом - совсем другой (а то и вообще не Firebird), то isc_prepare_transaction() таки нужен.

Я правильно понимаю?

зы: про EXTERNAL DATA SOURCE пока не будем.

Даже если серверы разные, но все участники распределённой тр-ции - Firebird, то isc_prepare_transaction() по-прежнему не обязательна.

Если есть не-Firebird участники, то без isc_prepare_transaction() - никак.

PS И ещё там была isc_reconnect_transaction()

Tisc_reconnect_transaction = function(status_vector: PISC_STATUS;
  db_handle: PISC_DB_HANDLE;
  tran_handle: PISC_TR_HANDLE;
  isc_arg4: Short;
  isc_arg5: PChar): ISC_STATUS;
stdcall;

hvlad

Даже если серверы разные, но все участники распределённой тр-ции - Firebird, то isc_prepare_transaction() по-прежнему не обязательна.

круто!
т.е. клиент по DB-хендлам просекает что сервера разные и колдует соответственно?

hvlad

PS И ещё там была isc_reconnect_transaction()

о-па!
в хидере её вижу, а в API Guide описалова нет (и на Дебаркадере в доке к IB-2020 нет).
у меня она задекларирована так:

Tisc_reconnect_transaction = function(status_vector: PISC_STATUS;
  db_handle: PISC_DB_HANDLE;
  tran_handle: PISC_TR_HANDLE;
  isc_arg4: Short;
  isc_arg5: PChar): ISC_STATUS;
stdcall;

что и как она делает?

зы: подозреваю что isc_arg4 и isc_arg5 для записи в RDB$TRANSACTION_DESCRIPTION ?

кстати, обнаружил ещё и fb_disconnect_transaction().
тоже интересно.

МП

кстати, обнаружил ещё и fb_disconnect_transaction().
тоже интересно.

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

МП

.isc_reconnect_transaction()
что и как она делает?

Она позволяет получить клиентский хендл одного участника подготовленной
распределённой тр-ции, чтобы потом перевести его в финальное состояние вызовом commit или rollback.
Есс-но, после анализа состояний остальных участников.
Последняя пара пар-ров указывают на буфер с ID этого участника и размер буфера.

hvlad

МП

.isc_reconnect_transaction()
что и как она делает?

Она позволяет получить клиентский хендл одного участника подготовленной
распределённой тр-ции, чтобы потом перевести его в финальное состояние вызовом commit или rollback.
Есс-но, после анализа состояний остальных участников.
Последняя пара пар-ров указывают на буфер с ID этого участника и размер буфера.

уточни пожалуйста, под ID подразумевается значение RDB$TRANSACTION_ID из таблицы RDB$TRANSACTIONS ?

hvlad

МП

кстати, обнаружил ещё и fb_disconnect_transaction().
тоже интересно.

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

это чтоб при isc_detach_database не получить isc_open_trans?
или зачем?

МП

уточни пожалуйста, под ID подразумевается значение RDB$TRANSACTION_ID из таблицы RDB$TRANSACTIONS ?

ID не обязан быть в RDB$TRANSACTIONS (это зависит от использования prepare/prepare2),
главное чтобы этот номер был в TIP в состоянии limbo.

я правильно понимаю, что если использовался prepare, а не prepare2, то в RDB$TRANSACTIONS никакого ID не будет.

тогда где его взять?

МП

я правильно понимаю, что если использовался prepare, а не prepare2, то в RDB$TRANSACTIONS никакого ID не будет.

Не правильно.

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

hvlad

МП

я правильно понимаю, что если использовался prepare, а не prepare2, то в RDB$TRANSACTIONS никакого ID не будет.

Не правильно.

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

непонимэ.
isc_prepare_transaction() мне нихрена кроме ISC_STATUS не вернёт.

где я возьму ID для isc_reconnect_transaction()?