Чтение неподтвержденных данных

← →
Сергей Бастрыгин © (2004-11-12 12:58) [0]

Помогите. Как прочитать неподтвержденные данные

← →
Johnmen © (2004-11-12 13:03) [1]

Ставь соответствующий уровень изоляции транзакции.
И готовься к проблемам в будущем...

← →
Romkin © (2004-11-12 13:08) [2]

У FB/IB нет dirty read :)

← →
Johnmen © (2004-11-12 13:16) [3]

>Romkin © (12.11.04 13:08) [2]

Конечно же...:)

← →
Сергей Бастрыгин © (2004-11-12 13:16) [4]

мне надо только достать данные, но не работать в этом режиме, эффект получился - после создания накладной было подтверждение по commit, даже успели ее отпечать, на втором компе в это время появился deadlock, теперь остались только реквизиты накладной а содержимого нет, а она большая, и что самое обидное, распечатанную накладаную отдали и копии у нас нет. По видимому это эффект in limbo

← →
Johnmen © (2004-11-12 13:23) [5]

Видимо тебе нужен уровень RepeatableRead.

← →
msguns © (2004-11-12 13:30) [6]

Небось юзается TIBTransaction с пустым окном в редакторе параметров.

← →
Сергей Бастрыгин © (2004-11-12 13:45) [7]

>msguns © (12.11.04 13:30) [6]
транзакция Read committed

>Johnmen © (12.11.04 13:23) [5]
попробую с RepeatableRead поиграться, а может и gfix -list чем нибудь поможет

← →
msguns © (2004-11-12 13:52) [8]

>Сергей Бастрыгин © (12.11.04 13:45) [7]
>>msguns © (12.11.04 13:30) [6]
>транзакция Read committed

И все ?

← →
Сергей Бастрыгин © (2004-11-12 13:57) [9]

соответсвено параметры read_committed rec_version nowait

← →
msguns © (2004-11-12 14:10) [10]

Вроде все правильно ...

← →
msguns © (2004-11-12 14:11) [11]

А пробовал как Johnmen © (12.11.04 13:23) [5] ?

← →
Сергей Бастрыгин © (2004-11-12 14:32) [12]

поставил в транзакции SNAPSHOT и не помогло

← →
Johnmen © (2004-11-12 14:36) [13]

>Сергей Бастрыгин © (12.11.04 13:16) [4]

Поподробней, кто, что делал, в какой последовательности, к чему приводило/привело. Какие тр-ии для чего используются.

← →
msguns © (2004-11-12 15:02) [14]

Кстати, ты указал параметры какой транзакции - пишущей или читающей. Я-то имел в виду прежде всего "конкурентов", т.е. кто обновляет то, чего не "видит" читающая. Так вот из конкурентов надо снапшот убрать !

← →
Сергей Бастрыгин © (2004-11-12 15:30) [15]

Хорошо начнем с общей истории
У меня задача - складской учет. Территориально раскиданы мы по квартирам, всего 8 точек, в каждой своя база данных, у каждого все проводимые изменения записываются через тригер в отдельный журнал, т.е. имя пользователя, время, ключ записи и имя таблицы. когда надо передать, пробегаемся по этим записям, сбрасывая эти изменения в текстовый файл и отправляем по почте на администраторский пункт, там принимается и в обратной последовательности записывается в базу данных, также все фиксируется в журнале, потом идет рассылка этих данных остальным шести пунктам, в результате по заложенной идее получается у всех копия БД.
Но не все так хорошо, почемуто только на одной базе часто выпадает сообщение "lock conflict on no wait transaction deadlock update conflicts with concurrent update" эту проблему еще не решил, но по видимому после этой ошибки проходит задержка записи. Например Реквизиты накладной записываются в журнал после того как создана вся накладная, это две транзакции закрытые Commit, сначала записывается вторая потом первая. Соответсвенно отправка сначала состава накладной без ее реквизитов, а потом реквизиты, это ошибка.
Вчера пропал состав накладной которая была вчера создана и распечатана, а сегодня опять появилась.
Осталось таких четыре пустых накладных от 28.10 по ним надо вытащить состав, а не получается.
Теперь по транзакциям
Набивается накладная на первом компьютере под транзакцией со свойствами Read committed, на втором идет отправка по почте и прием, ошибка вылетает уже здесь во время получения данных под другой транзакцией, тоже Read committed, вот после этого пропадают созданные данные с первого компьютера
Такая во сказка получилась. Принимаю любые версии как достать данные которые были ранее созданы

← →
msguns © (2004-11-12 15:47) [16]

Что-то я не понял про квартиры и компьютеры.
То что понял:
1. Есть несколько офисов и Гл.офис, не связанные между собой локальной сетью
2. С каждого такого офиса могут выписываться расходные накладные
3. Периодически информация о выписанных в офисе за день (к примеру) накладных сваливается в текстовый файл, который передаются модемом в Гл.офис.
4. В Гл.офисе данные из принятого текстовика конвертятся и заливаются в Базу Данных Предприятия (БДП)
5. Ночью (предположительно) складские остатки и прайс сливаются в текстовик и модемом передаются в офисы, откуда утром замещают устаревшую инфу в БД.

Что не так ?

← →
Сергей Бастрыгин © (2004-11-12 16:03) [17]

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

Тогда есть вопросы:
Если тел.связь более-менее, почему не использовать трехзвенку или хотя бы клиентские НД ?
Если связь не в дугу, то в офисе должен работать оочень тонкий "клиент", который только и может, что выписывать накладные и пополнять справочник партнеров (банков и т.д.). А если так, то осн.приложение должно данные из "буферов" апплицировать, а не тупо доливать в базу. Уже сведенные (апплицированные) данные заливаются, при этом никаких конфликтов быть не должно, т.к. транзакция не может иметь никаких конкурентов. Проблема замены номеров накладных (офис не знает, какой № будет иметь документ в базе) легко решается путем создания суррогатных составных номеров типа <№ офиса>-<Дата>-<Пор.№>

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

С номерами накладных мы проблему сразу решили, чуть в другом виде, но не повторяются.

расшифруй что значит
"осн.приложение должно данные из "буферов" апплицировать, а не тупо доливать в базу"

Это значит, что если в буфеоре есть, к примеру, новый (без ID) партнер, то, прежде чем его добавлять в справочник, надо поискать в нем напрмер по наименование или лучше по ИК, ОКПО и т.д. Чтобы не плодились двойники-тройники и т.д. То же самое и накладные. Перед записью из текстовика в БД они должны сверяться с имеющимися в БД на предмет повтора. Это уже ближе к репликации, но очень упрощенной. Где-то в литературе я встретил слово "аппликация" (буквально "семантическое", т.е. смысловое) данных. Не ручаюсь за правомерность термина, но в данном контексте считаю его достаточно удачным

Я тебя понял, в данной схеме такое исключено, с дублями мы хорошо продумали, по людям распределены обязанности кто что делает, а в программе чтобы не было дублей ID, я им присваиваю не повторяющиеся значения для первого пункта 1, 11, 21, для второго соответсвенно 2, 12, 22 т.е через десяток с окончанием номера пункта, сразу видно кто создал документ

но у меня вопрос остался подвешенным, выяснил я что по видимому транзакция из-за сбоя попала в состояние in limbo, поэтому через определенный период она получала подтверждение, но никак не найду как добраться до некоторых данных которые еще не подтвердились, и уже большой период начиная с 28.10

Самое интересеое, что я так и не понял ГДЕ у тебя дохлая транзакция: в офиге или Гл.офисе и на какой операции ;)

проблема на конечном пункте, на складе
По транзакциям,
1. создается реквизиты накладной, номер, дата от кого кому, ID
запись сразу комитится
2. Набирается в дбф список пособий.
3. из дбф копирую в GDB и комитю вторую транзакцию
4. распечатали и отдали накладную, себе кстати не оставили никаких документов.
5. забыли про нее
6. выясняется что в главный офис пришел только пункт 1, в журнале пометки о удалении нет, нет и о создании, а тут начинает появляться вчерашняя пропажа, а старой нет

по времени точно- ревизиты созданы в 14:36 а в 15:00 была ближайшая ошибка, вот 24 минуты работы потеряны

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

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

Чтение неподтвержденных данных Найти похожие ветки