Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Firebird, InterBase Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 7 [8] 9   вперед  Ctrl      все
 Re: Firebird + fbExpress lock conflict  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32886
GJ
Если не прокатит, и моя "ловушка" окажется пуста, буду логировать все старты и завершения транзакций.
давно надо было, раз уж не хочешь пользоваться трейсом самого сервера.
обрати внимание, при конфликте сервер выдёт тебе номер конфликтующей транзакции - будет на куда посмотреть.
24 ноя 21, 17:48    [22400328]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 11092
GJ
Вывод: чтобы произошла блокировка блокирующая транзакция не должна быть завершена на момент выполнения запроса UPDATE в другой транзакции.


ошибаешься, по крайней мере до 4.0 это не обязательно так. Да и в 4.0 зависит какой именно RC ты стартуешь
24 ноя 21, 18:05    [22400335]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54772

GJ
Вывод: чтобы произошла блокировка блокирующая транзакция не должна быть
завершена на момент выполнения запроса UPDATE в другой транзакции.

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

Posted via ActualForum NNTP Server 1.5

24 ноя 21, 18:52    [22400373]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4926
GJ
YuRock
Так ведь так и есть. При insert блокировки невозможны, при update - возможны.
Делаешь логику на insert - и не паришься вообще о блокировках.

Так оно и есть, если клиент работает непосредственно с таблицами. А если подготовить специальные ХП, то сбоя в работе пользователь получит сообщение, что данный документ правится другим пользователем, и внесение в него изменений невозможно.
Не зна, при чем здесь "работать непосредственно с таблицами" или через процедуру.
Ты, кажется, говорил, что UPDATE'ов этой таблицы - тысячи в разных местах.
Все они обложены такими "спец. процедурами"?
И что в тех "специальных процедурах"? Добавление записей в какую-то таблицу локов?
И как это делается? В одной транзакции, или потом мусор подчищать приходится?
24 ноя 21, 19:01    [22400375]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

Откуда:
Сообщений: 50
Dimitry Sibiryakov

GJ
Вывод: чтобы произошла блокировка блокирующая транзакция не должна быть
завершена на момент выполнения запроса UPDATE в другой транзакции.

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

Доктор, ну вот нафига же так тупить и подставляться?! Я выполнил определенную последовательность действий и получил определенный результат. И все это описал. Даже если я не знаю, что такое "уровни изоляции", то результат говорит сам за себя: существуют такие уровни изоляции, при которых мои утверждения являются истинными. Потом, если потребуется, можно будет посмотреть в моем IBExpert настройки и узнать, что данное поведение имеет место для транзакций READ COMMITTED.
Хотите меня смутить, скажите, что тут раз на раз не приходится: может получится, а может и нет. И вот тогда я вынужден буду заткнуться, потому что данное утверждение я не смогу опровергнуть экспериментально ;)

YuRock
GJ
пропущено...

Так оно и есть, если клиент работает непосредственно с таблицами. А если подготовить специальные ХП, то сбоя в работе пользователь получит сообщение, что данный документ правится другим пользователем, и внесение в него изменений невозможно.
Не зна, при чем здесь "работать непосредственно с таблицами" или через процедуру.
Ты, кажется, говорил, что UPDATE'ов этой таблицы - тысячи в разных местах.

Упустил в моем сообщении еще один кусок текста: "А если разработать специальное клиентское приложение, то там пользователь даже открыть документ на редактирование не сможет, получит то самое сообщение, что документ пока занят".
Приложения нашей системы так устроены, что пользователь просто не сможет открыть документ "на редактирование", если другой пользователь его уже открыл. Поэтому мне главное самому не напортачить с транзакциями, а никто посторонний помешать не сможет.
Конечно же, за исключаем вмешательства грамотного человека с использованием IBExpert-а :) Но против лома нет приема.
24 ноя 21, 19:44    [22400390]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54772

GJ
существуют такие уровни изоляции, при которых мои утверждения являются истинными.

Да, существуют. Но в этом топике ты так и не удосужился упомянуть используются
ли в твоём приложении именно они.

Posted via ActualForum NNTP Server 1.5

24 ноя 21, 19:48    [22400393]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

Откуда:
Сообщений: 50
Dimitry Sibiryakov

GJ
существуют такие уровни изоляции, при которых мои утверждения являются истинными.

Да, существуют. Но в этом топике ты так и не удосужился упомянуть используются
ли в твоём приложении именно они.

В приложении используются транзакции только такие, в которых
TTransactionDesc.IsolationLevel = xilREADCOMMITTED

Сообщение было отредактировано: 24 ноя 21, 19:55
24 ноя 21, 19:54    [22400397]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54772

GJ
В приложении используются транзакции только такие, в которых
TTransactionDesc.IsolationLevel = xilREADCOMMITTED

В какие точно флаги Firebird это транслируется внутри драйвера?
Ты трассировал транзакции, ты должен это знать.

Posted via ActualForum NNTP Server 1.5

24 ноя 21, 20:00    [22400399]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Gallemar
Member

Откуда:
Сообщений: 5675
Прошла неделя, мыши продолжают есть кактус. А надо всего лишь запустить трейс.
24 ноя 21, 20:52    [22400405]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
hvlad
Member

Откуда:
Сообщений: 11551
Gallemar
Прошла неделя, мыши продолжают есть кактус. А надо всего лишь запустить трейс.
При пожирании кактусов время летит незаметно ;)
24 ноя 21, 21:18    [22400415]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Vlad F
Member

Откуда:
Сообщений: 1450
Вы просто ещё не поняли с кем связались.
Он здесь любого перенудит влегкую, имхо.))

Сообщение было отредактировано: 24 ноя 21, 22:34
24 ноя 21, 22:28    [22400433]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 63459
Сомневаюсь. Во-первых, занудство плохо измеряемо.
Во-вторых, на каждого зануду у нас есть Дима.

P.S. Простите за занудство.

Posted via ActualForum NNTP Server 1.5

24 ноя 21, 22:40    [22400437]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54772

Gallemar
А надо всего лишь запустить трейс.

Топикстартеры на такое обычно отвечают "запускал, не помогло".

Posted via ActualForum NNTP Server 1.5

24 ноя 21, 23:10    [22400444]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4926
GJ


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

Упустил в моем сообщении еще один кусок текста: "А если разработать специальное клиентское приложение, то там пользователь даже открыть документ на редактирование не сможет, получит то самое сообщение, что документ пока занят".
Приложения нашей системы так устроены, что пользователь просто не сможет открыть документ "на редактирование", если другой пользователь его уже открыл. Поэтому мне главное самому не напортачить с транзакциями, а никто посторонний помешать не сможет.
Конечно же, за исключаем вмешательства грамотного человека с использованием IBExpert-а :) Но против лома нет приема.

Так я и спрашиваю, как же это оно так устроено? Через таблицу локов? С доп. транзакцией, или нет? (Хотя если говорит, каким пользователем занято, то да).
Там и еще были вопросы, но ты всё "упустил".

Сообщение было отредактировано: 24 ноя 21, 23:20
24 ноя 21, 23:19    [22400445]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Старый плюшевый мишка
Member

Откуда:
Сообщений: 1128
Vlad F
Вы просто ещё не поняли с кем связались.
Он здесь любого перенудит влегкую, имхо.))


Лично я уже понял :) Кормить тролля больше не намерен. А порассуждать можно

Во-первых, я не очень понимаю почему FB до сих пор с лёгкой руки Пресвятого Джима любой конфликт величает дедлоком. Ещё меньше я понимаю может ли движок опознать дедлок. И уж совсем не понимаю должен ли он этим заниматься. Мне каатся не его это движково дело.

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

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

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

Есть ещё категория неизбежного зла. Приехал на склад вагон о 60 тоннах груза, например, дизайнерской полосато-волосатой бумаги из слонячьего говна, которую, в смысле каждую отдельную разновидность которой, сиречь номенклатурную позицию, оптовик берёт по две-три пачки на месяц. Весом по 2-3 кило пачка. Сколько там позиций в вагоне, считайте сами Грузчики носятся, кладовщик регистрирует состав складской операции приёмки, трали-вали-пассатижи. И вот наступает момент регистрации завершения операции. Тоиссь, пометки транспортной партии как неживой, увеличения складского запаса по всей этой туевой хуче номенклатурных позиций, отстрела в ценовые группы номенклатурных позиций количеств и цен для информирования коммерческого директора и прочих мыслящих группами, а не отдельными позициями, усреднения себестоимости по группам, изменения резервов на складе, в смысле под кого из потребителей что и сколько везли, снятие оных из транспортной партии и ещё чорта в ступе. Короче, текст ХП в максимальный размер блоба в системной таблице не влезает, приходится дробить. Дык оно ж минут 10 будет выполняться. На железе образца 5-го году. Не пугайтесь, не тыща девятьсот пятого. И за эти 10 минут чтоб другой кладовщик попытался зарегистрировать отгрузку одной пачки пусть даже не из присутствовавших в вагоне номенклатурных позиций, но входящих с ними в одну ценовую группу - да нефиг делать. И будет ему облом-с. В смысле Железный Майк раз 5 рестартует транзакцию и потыкается, а потом скажет - знаешь дорогой, занято. Пойди покури или там соточку накати и ущипни соседку-кладовщицу за жопу. А вот если он начал свою регистрацию отгрузки, в смысле транзакцию стартовал, раньше старта транзакции завершения приёмки, то это хуже, 10 минут превращаются в 20 если случилось сие на последней принимаемой позиции. Но деваться некуда. Умный человек это всё в приращениях делает, а не пишет в базу посчитанные за щекой новые значения, можно было бы и пропустить, но сервер не умеет оценивать IQ программиста и подходит к вопросу пессимистически. И правильно делает. Ситуация возникает нечасто, но необратимо, с этим надо примириться и обслуживать её.

Чёта я раззвезделся на ночь глядя...
25 ноя 21, 00:41    [22400449]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Старый плюшевый мишка
Member

Откуда:
Сообщений: 1128
YuRock

Так я и спрашиваю, как же это оно так устроено? Через таблицу локов? С доп. транзакцией, или нет? (Хотя если говорит, каким пользователем занято, то да).


Если с мудрствованиями лукавыми, то http://www.ibase.ru/pslock/

По-армейски коротко и ясно http://www.ibase.ru/plocks/
25 ноя 21, 00:52    [22400452]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4926
Старый плюшевый мишка
YuRock

Так я и спрашиваю, как же это оно так устроено? Через таблицу локов? С доп. транзакцией, или нет? (Хотя если говорит, каким пользователем занято, то да).


Если с мудрствованиями лукавыми, то http://www.ibase.ru/pslock/
Спасибо, я знаю разные способы, но хотел узнать, как реализовано у топикстартера.
Кстати, по этой ссылке его способов нет, ибо у него сообщеается, каким пользователем заблокировано. SELECT FOR UPDATE для этого не поможет.

Старый плюшевый мишка
По-армейски коротко и ясно http://www.ibase.ru/plocks/

А вот тут якобы есть (вариант 2), но написано странно, сырой материал какой-то:
1. Не сказано, что после успешного Lock надо транзакцию закоммитить (иначе ошибка будет как минимум не такой красивой, а просто обычный lock conflict);
2. Не сказано, что если запустить других клиентов под тем же пользователем, то этот способ не поможет, а будет вообще кошмар - последовательные неосознанные изменеия одного и того же, с еще бОльшей вероятностью нарваться на lock conflict-ы, ведь транзакций нужно 2 и 3 апдейта (или insert/update/delete, если через доп. таблицу).
3. Все проблемы пункта 2 с успехом повторятся, если запустить какое-нибудь (например, авто-) редактирование документа второй раз в этом же клиенте примерно параллельно.

Сообщение было отредактировано: 25 ноя 21, 06:10
25 ноя 21, 06:06    [22400466]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 63459
СПМ> Во-первых, я не очень понимаю почему FB
СПМ> до сих пор любой конфликт величает дедлоком.

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

С третьей стороны, непонятно, нафига оно нужно...

Posted via ActualForum NNTP Server 1.5

25 ноя 21, 11:17    [22400573]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

Откуда:
Сообщений: 50
Dimitry Sibiryakov

GJ
В приложении используются транзакции только такие, в которых
TTransactionDesc.IsolationLevel = xilREADCOMMITTED

В какие точно флаги Firebird это транслируется внутри драйвера?

Пардон за шаблонный ответ, но с какой целью интересуетесь? Это имеет какое-то отношение к теме, или просто поговорить? Так меня и так обвиняют в тоннах флуда. Если интересно, сооруди тестовую программу и посмотри.

Gallemar
Прошла неделя, мыши продолжают есть кактус. А надо всего лишь запустить трейс.

Ну, наверное мышкам просто нравится здесь флудить общаться, потому что я открытым тестом уже давно сказал, что вопросов по теме больше не имею.
Про сложности трейса в данном случае я уже упоминал. Десять баз, по 15 моих приложений на каждой. Плюс куча других приложений, работающих с той же базой. И прошла неделя, а ошибка еще не появилась. То есть всю эту неделю надо было с утра запускать трассировку на каждой БД. По уму, надо бы аудит настроить на серверах, но без админов заказчика этого не сделать.

Vlad F
Вы просто ещё не поняли с кем связались.
Он здесь любого перенудит влегкую, имхо.))

Ты мне льстишь :) Судя по обсуждению, как минимум парочка участников мне ничуть не уступает.
Или ты под занудством понимаешь спокойное ведение беседы, игнорируя многочисленные подъё... подколки и троллинг? :)

Dimitry Sibiryakov

Топикстартеры на такое обычно отвечают "запускал, не помогло".

Уже обсуждалось, уже ответили. Мне посоветовали выполнить трассировку на локальной БД на своем компе, на что я ехидно ехидно ответил, что не помогло. А как оно могло помочь, если проблемы возникают только на базах заказчика. Причем, только одного заказчика?!

YuRock
Так я и спрашиваю, как же это оно так устроено? Через таблицу локов? С доп. транзакцией, или нет? (Хотя если говорит, каким пользователем занято, то да).
Там и еще были вопросы, но ты всё "упустил".

Если кратко, то принадлежность документа БД и таблица локов. Детальное же обсуждение будет здесь оффтопом. Если реально интересно, конечно, могу подготовиться и рассказать. Если для прикола, то лучше не надо. Толку все равно не будет, а времени жалко.

К данному обсуждению это все равно относится слабо, потому что приложение создает свой документ и проводит его до конца. С чужими документами не работает.

Старый плюшевый мишка

Лично я уже понял :) Кормить тролля больше не намерен.

Написал человек и разродился огроменным постом по поводу блокировок при многопользовательской работе в теме, касающейся поиску ошибок в приложении, приводящих к возникновению блокировок при однопользовательской работе.
Кажется, я перестаю понимать, что такое троллинг :)
25 ноя 21, 23:10    [22400976]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54772

GJ
Пардон за шаблонный ответ, но с какой целью интересуетесь? Это имеет какое-то
отношение к теме, или просто поговорить?

Ещё раз, медленно: сабжевая ошибка может возникать в нескольких ситуациях:
1) update одной записи при всех уровнях изоляции.
2) select изменённой записи при уровне изоляции read committed no record version.
3) select for update.

Во втором случае ты хоть затрассируйся update - ничего не найдёшь.

GJ
Мне посоветовали выполнить трассировку на локальной БД на своем компе, на что я
ехидно ехидно ответил, что не помогло. А как оно могло помочь, если проблемы
возникают только на базах заказчика. Причем, только одного заказчика?!

Эта трассировка должна была выявить реальную последовательность работы
приложения с БД и предоставить полный список изменяемых таблиц на которых
способен происходить конфликт. Но не помогло так не помогло. Значит, не судьба.

Posted via ActualForum NNTP Server 1.5

25 ноя 21, 23:20    [22400979]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4926
GJ
Если кратко, то принадлежность документа БД и таблица локов. Детальное же обсуждение будет здесь оффтопом. Если реально интересно, конечно, могу подготовиться и рассказать. Если для прикола, то лучше не надо. Толку все равно не будет, а времени жалко.

К данному обсуждению это все равно относится слабо
Очень вероятно, что этот механизм имеет прямое отношение к проблеме. Возможно, и создаёт её. Потому и спрашивал.
Тут тебе и лишние транзакции, которые можно забыть не открыть или закрыть, тут всё.
Но если тебе не интересно - ок. Мне - тем более. Я заранее знаю, как оно у тебя устроено, просто тебя хотел на мысль навести, где проблему возможную искать.
25 ноя 21, 23:40    [22400983]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Gallemar
Member

Откуда:
Сообщений: 5675
GJ
Ну, наверное мышкам просто нравится здесь флудить общаться, потому что я открытым тестом уже давно сказал, что вопросов по теме больше не имею.

Тогда имеет смысл прибить автора тему и разойтись
26 ноя 21, 09:00    [22401074]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Vlad F
Member

Откуда:
Сообщений: 1450
Gallemar,

Погодите прибивать, можно просто ослабить давление.
Он же должен в конце концов сообщить, чем там кончится дело.))
26 ноя 21, 10:44    [22401118]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

Откуда:
Сообщений: 50
Dimitry Sibiryakov

Эта трассировка должна была выявить реальную последовательность работы
приложения с БД и предоставить полный список изменяемых таблиц на которых
способен происходить конфликт.

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

YuRock
GJ
Если кратко, то принадлежность документа БД и таблица локов. Детальное же обсуждение будет здесь оффтопом. Если реально интересно, конечно, могу подготовиться и рассказать. Если для прикола, то лучше не надо. Толку все равно не будет, а времени жалко.

К данному обсуждению это все равно относится слабо
Очень вероятно, что этот механизм имеет прямое отношение к проблеме. Возможно, и создаёт её. Потому и спрашивал.
Тут тебе и лишние транзакции, которые можно забыть не открыть или закрыть, тут всё.

Либо я не понял тебя, либо ты не понял меня.
В БД существует специальная таблица, в которую заносится информация о том, что такой-то пользователь "открыл на редактирование такой-то документ" (в кавычках, потому что это условно-упрощенно, чтобы не вдаваться в детали). Соответственно, другое приложение не позволит открыть документ на редактирование, если он уже кем-то открыт. Таблица с содержательными данными при этом не блокируется, поэтому и говорю, что к обсуждаемому вопросу это отношения не имеет.

Gallemar

Тогда имеет смысл прибить автора тему и разойтись

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

Vlad F
Gallemar,
Погодите прибивать, можно просто ослабить давление.
Он же должен в конце концов сообщить, чем там кончится дело.))

Ждать, скорее всего, придется долго. Я где-то через недельку выпадаю из общения (по медицинским аспектам) до нового года. Так что тема заглохнет сама собой и уползет вниз.
26 ноя 21, 11:40    [22401151]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Gallemar
Member

Откуда:
Сообщений: 5675
GJ
Так что тема заглохнет сама собой и уползет вниз.

Придешь и апнешь :) и всё снова как завертится...
26 ноя 21, 11:45    [22401158]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 7 [8] 9   вперед  Ctrl      все
Все форумы / Firebird, InterBase Ответить