Головна сторінка
Top.Mail.Ru Яндекс.Метрика
Форум: "Бази";
Поточний архів: 2004.12.12;
Завантажити: [xml.tar.bz2];

Вниз

Читання непідтверджених даних Знайти схожі гілки


Сергей Бастрыгин ©   (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]

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



msguns ©   (2004-11-12 16:25) [18]

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



Сергей Бастрыгин ©   (2004-11-12 16:48) [19]

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

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

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



msguns ©   (2004-11-12 17:13) [20]

Це означає, що якщо в буфеоре є, наприклад, новий (без ID) партнер, то, перш ніж його додавати в довідник, треба пошукати в ньому напрмер по найменування або краще по ІК, ОКПО і т.д. Щоб не плодилися двійники-трійники і т.д. Те ж саме і накладні. Перед записом з текстовика в БД вони повинні звірятися з наявними в БД на предмет повтору. Це вже ближче до реплікації, але дуже спрощеною. Десь в літературі я зустрів слово "аплікація" (буквально "семантичне", тобто смислове) даних. Чи не ручаюсь за правомірність терміна, але в даному контексті вважаю його досить вдалим



Сергей Бастрыгин ©   (2004-11-12 17:25) [21]

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

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



msguns ©   (2004-11-12 17:48) [22]

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



Сергей Бастрыгин ©   (2004-11-12 18:05) [23]

проблема на кінцевому пункті, на складі
За транзакціями,
1. створюється реквізити накладної, номер, дата від кого кому, ID
запис відразу Коміто
2. Набирається в ДБФ список посібників.
3. з ДБФ копіюю в GDB і Коміто другу транзакцію
4. роздрукували і віддали накладну, собі речі не залишили ніяких документів.
5. забули про неї
6. з'ясовується що в головний офіс прийшов тільки пункт 1, в журналі позначки про видалення немає, немає і про створення, а тут починає з'являтися вчорашня пропажа, а старої немає

за часом точно-реквізіти створені в 14: 36 а в 15: 00 була найближча помилка, ось 24 хвилини роботи втрачені



Alex_Bredin ©   (2004-11-12 20:10) [24]

Здається, суть проблеми в тому, що заголовки і зміст накладних пишуться в різних транзакції (незрозуміло чому), а треба б в одній.



Сергей Бастрыгин ©   (2004-11-12 21:07) [25]

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



сторінки: 1 вся гілка

Форум: "Бази";
Поточний архів: 2004.12.12;
Завантажити: [xml.tar.bz2];

наверх









Пам'ять: 0.67 MB
Час: 0.117 c
14-1100984088
DeMoN-777
2004-11-20 23:54
2004.12.12
У кого вдома більш 1-ого працюючого ПК


3-1100590318
denis24
2004-11-16 10:31
2004.12.12
Видалення картинки в поле blob


6-1091808188
2те10м
2004-08-06 20:03
2004.12.12
трафік


1-1101692605
що
2004-11-29 04:43
2004.12.12
Створення декількох текстових файлів


1-1101636741
Bobby Digital
2004-11-28 13:12
2004.12.12
ItemIndex





африкаанс албанський арабська вірменин азербайджанець баскський білоруський болгарська каталонський Китайська (спрощене письмо) Китайський традиційний) хорватський чеська данську мову нідерландський Ukranian естонець Філіппінська фінську мову французький
галісійська грузинський німецький грецький гаїтянський креольський давньоєврейську хінді угорський ісландський індонезієць ірландський італійський японський корейський латиська литовець македонець малайський мальтійський норвежець
перс полірування португальська румунський російська сербський словацький словенський іспанська суахілі шведську мову тайський турецька український урду в&#39;єтнамський валлійський ідиш бенгальський боснійський
кебуано есперанто гуджараті хауса хмонг ігбо яванський каннада кхмерская Лао латинь маорі маратхі монгольський непальська панджабі сомалійський тамільська телугу йоруба
зулуський
Англійська Французький Німецький Італійський Португальська Русский Іспанська