Остатки на дату.

[ALES]

Цитата:

Сообщение от chel

2. Начинаем формировать отчет на 15.01.06. Делаем запрос к Sum, получаем 10 шт
3. Кто-то в это время формирует проводку +15 шт
4. Делаем запрос к InventTrans, получаем 15 шт

Транзакцию ведь можно и корректно написать

[chel]

Цитата:

Сообщение от ALES

Транзакцию ведь можно и корректно написать

Какую транзакцию? Мы данные получаем в отчете двумя последовательными запросами. Для этого в транзакции, которая выбирает данные, надо установить уровень изоляции "serializable". Разве это можно сделать для одной транзакции в аксапте?

[Recoilme]

Цитата:

Сообщение от chel

Какую транзакцию? Мы данные получаем в отчете двумя последовательными запросами. Для этого в транзакции, которая выбирает данные, надо установить уровень изоляции "serializable". Разве это можно сделать для одной транзакции в аксапте?

Я так понял у Вас MS SQL. =>
Учите мат часть:
1
2
3
4

В аксе используется пессиместическая модель чтения данных, цЫтата из "4":

Цитата:

Пессимистическая стратегия. Основное предположение состоит в том, что T работает параллельно с другими транзакциями, и они ей «мешают». Другими словами, как правило, найдется хотя бы одна транзакция T’, которая изменяет множество чтения и (или) множество записи транзакции T до момента ее фиксации. Все конфликты чтения/записи, ограничения целостности проверяются в процессе работы транзакции T.

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

Особенности этого протокола — быстрая фиксация (проверки ограничений целостности и наличия конфликтов при выполнении операции COMMIT отсутствуют) и медленная работа при выполнении действий над данными в течение работы транзакции (в процессе работы объекты блокируются, проверяются все ограничения).

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

Про версионность пока наверно не стоит заморачиваться

[chel]

Цитата:

Сообщение от Recoilme

Я так понял у Вас MS SQL. =>
Учите мат часть:
1
2
3
4

В аксе используется пессиместическая модель чтения данных, цЫтата из "4":


Про версионность пока наверно не стоит заморачиваться

И чего? К чему эта ссылка и цитата? Мы не можем блокировать InventSum и InventTrans при "пессимистической стратегии", т.к. даже если мы заблокируем изменения, в них легко будут добавляться новые записи (фантомы), от которых уровень изоляции, который применяется в аксапте, не спасет.

Цитата:

Сообщение от Recoilme

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

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

[Recoilme]

Цитата:

Сообщение от chel

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

естественно знаю. И об этом уже сто раз писалось на форуме.

Подходите к менеджерам и объясняете им ЧТО ОСТАТКИ НА ВРЕМЯ - это бред. Т.к. пока они смотрят отчет - остатки меняются. => качаете таблицы в хранилище по ночам и показываете остатки в отчетах из хранилища. Используя ОЛАП или RS. Динамические остатки (на время) - отражаете в формах ввода информации, если это критично им. Например в инвентаризации. На момент разноски/коммита - обновляете. Отчеты такого рода не стоят на "живых базах". Вы просто всё повесите, но никаких некорректностей -не будет. Исключения - для оракл, НО И В ВЕРСИОННОЙ СУБД - вы тоже все повесите. Потому что пока вы будете читать данные - будут плодится версии которые будут тормозить систему. В результате ОРАКЛ/2005 либо отправит вас в сад со своими долгоиграющими запросами, либо Вы снимите Ваш отчет на точку актуальности потратив кучу ресурсов и наплодив кучу мусора. Если конечно у Вас не игрушечная базща данных с миллионом проводок.

[Recoilme]

Цитата:

Сообщение от chel

И чего? К чему эта ссылка и цитата? Мы не можем блокировать InventSum и InventTrans при "пессимистической стратегии", т.к. даже если мы заблокируем изменения, в них легко будут добавляться новые записи (фантомы), от которых уровень изоляции, который применяется в аксапте, не спасет.

Блин... писал писал и не сохранилось. 2 раз ниасилю, поэтому пишу кратко.
0. Выходит я тупой.. потому,что:
1. В одной транзакции читаете с форапдейтом и никаких фантомов у вас не будет.
2. Этот механизм применяется в Аксе повсеместно например при чтении остатков
3. Если бы были какие-то коллизии у вас были бы отрицательные остатки при запрещенном отрицательном складе и т.п. БРЕД у Вас в базе бы был
4. Если у Вас они и есть - это из-за ошибок в алгоритмах, скорее всего Ваших Ошибок В Ваших Алгоритмах, а не фантомов.

[chel]

Цитата:

Сообщение от Recoilme

Блин... писал писал и не сохранилось. 2 раз ниасилю, поэтому пишу кратко.
0. Выходит я тупой.. потому,что:
1. В одной транзакции читаете с форапдейтом и никаких фантомов у вас не будет.
2. Этот механизм применяется в Аксе повсеместно например при чтении остатков
3. Если бы были какие-то коллизии у вас были бы отрицательные остатки при запрещенном отрицательном складе и т.п. БРЕД у Вас в базе бы был
4. Если у Вас они и есть - это из-за ошибок в алгоритмах, скорее всего Ваших Ошибок В Ваших Алгоритмах, а не фантомов.

В аксе повсеместно применяется только получение остатков на текущий момент. InventTrans не запрашивается

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

По поводу повторной шпильки в мой адрес: еще раз говорю - напишите Ваш Корректный Алгоритм, который корректно отработает эту ситуацию. Мне он не очевиден пока.

[MironovI]

Цитата:

Сообщение от chel

В том подходе, который здесь озвучили (вычитание оборотов с даты получения остатков до текущего момента) нужно сначала запросить InventSum - а потом через некоторое (продолжительное) время InventTrans, в который в момент выполнения запроса к InventSum кто-то третий добавляет записи...

Я к тому что беспокоится о том, что в моент построения отчета по транзакционной базе кто-то изменит данные и они не будут 100% верны не стоит, особенно при чтении (nolock) как это везде в отчтах - надо просто понимать что это так. Точные данные которые можно предоставить в виде отчетности партнерам или государству в Аксапте вооще можно получить только по закрытым периодам имхо..

[Recoilme]

Цитата:

Сообщение от chel

По поводу повторной шпильки в мой адрес: еще раз говорю - напишите Ваш Корректный Алгоритм, который корректно отработает эту ситуацию. Мне он не очевиден пока.

В одной транзакции читаете с форапдейтом и никаких фантомов у вас не будет.

[Recoilme]

Цитата:

Сообщение от chel

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

По поводу повторной шпильки в мой адрес: еще раз говорю - напишите Ваш Корректный Алгоритм, который корректно отработает эту ситуацию. Мне он не очевиден пока.

Остатки на 01 января

PHP код:

ТЫТЫСЫБЕГИН

SELECT  [I]ФОРАПДЭЙТ [/I] TOP 100 dbo.INVENTSUM.ITEMID AS ITEMID, SUM(dbo.INVENTSUM.POSTEDQTY) - SUM(dbo.INVENTTRANS.QTY) AS QTY, 
                      dbo.INVENTSUM.INVENTDIMID
FROM         dbo.INVENTSUM LEFT OUTER JOIN
                      dbo.INVENTTRANS ON dbo.INVENTSUM.INVENTDIMID = dbo.INVENTTRANS.INVENTDIMID AND 
                      dbo.INVENTSUM.ITEMID = dbo.INVENTTRANS.ITEMID
WHERE     (dbo.INVENTTRANS.DATEPHYSICAL >= CONVERT(DATETIME, '2006-01-01 00:00:00', 102)) AND 
        ((dbo.INVENTTRANS.STATUSRECEIPT = 1) OR
                      (dbo.INVENTTRANS.STATUSISSUE = 1) OR
                      (dbo.INVENTTRANS.STATUSRECEIPT = 2) OR
                      (dbo.INVENTTRANS.STATUSISSUE = 2) OR
                      (dbo.INVENTTRANS.STATUSRECEIPT = 3) OR
                      (dbo.INVENTTRANS.STATUSISSUE = 3))
GROUP BY dbo.INVENTSUM.ITEMID, dbo.INVENTSUM.INVENTDIMID

ТЫТЫСЫКОММИТ 


Люди, не обращайте внимания на этот код, так делать на реляционной базе не стоит!
Это просты мы с chel пиписьками меряемся..