Если прочитать методику перевода конфигурации на управляемые блокировки от 1С - можно там найти много всего интересного и пугающего. На самом деле всё просто: В свойствах конфигурации меняете режим блокировки данных - "Управляемый". Всё. Могу вас поздравить - вы только что перешли на управляемые блокировки. На самом деле всё несколько сложнее - но не на много.
Для начала небольшой теоретический экскурс - зачем нужны блокировки: У кого есть доступ конечно можно прочитать здесь: http://kb.1c.ru/articleView.jsp?id=30 1С озаботились написать достаточно доступную статью про блокировки данных. У кого же доступа нет в двух словах опишу для чего нужны блокировки:
Пример 1. Если после включения управляемых блокировок ничего не делать, и при этом начать параллельно проводить 2 документа (один из них ведь всё равно на долю секунды раньше), то получим приблизительно следующую картину:
Транзакция 1
Транзакция 2
Состояние остатков
Начало
|
1 шт
|
Начало
1 шт
|
|
1 шт
Чтение остатков
|
1 шт
|
Чтение остатков
1 шт
|
|
1 шт
Списание с остатков
|
0 шт
|
Списание остатков
-1 шт
Завершение
|
Завершение
Что здесь не так? Контроль остатков дал сбой. 2-ой документ успел прочитать остатки раньше, чем 1-й успел их записать. При этом увидел, что на остатках 1 штука и спокойно списал их вслед за первым. Стоит оговориться, что по факту блокировки здесь всё-таки будут. 2 документа не смогут списать остатки одновременно, это необходимо для логической целостности БД, но для решения прикладной задачи в данном примере вряд ли полезно.
Теперь постараемся исправить ситуацию - в коде проведения документа пропишем установку эксклюзивной управляемой блокировки непосредственно перед чтением остатков:
Транзакция 1
Транзакция 2
Состояние остатков
Начало
|
1 шт
|
Начало
1 шт
Блокировка
|
1 шт
Чтение остатков
|
1 шт
|
Попытка блокировки
1 шт
|
Ожидание на блокировке
1 шт
Списание с остатков
Ожидание на блокировке
0 шт
|
Ожидание на блокировке
0 шт
Завершение
Ожидание на блокировке
0 шт
Блокировка
0 шт
Чтение остатков
0 шт
|
0 шт
Отказ
0 шт
При этом 1-я транзакция блокировку успеет установить, а вторая попытается установить блокировку и будет ждать освобождения ресурса, до тех пор пока не завершится 1-я транзакиця. Стоит отметить, что блокировки действуют только до завршения транзакции, и, естественно, блокировки блокируют ресурс только для изменения из других сессий. Всё логично, но паразительно как много людей об этом не знают.
Ну теперь, когда разобрались зачем блокировки нужны остаётся только установить управляемые блокировки там где это нужно: а именно -только там где производится контроль остатков. Если у вас в базе менеджер имеет право провести документ вне зависимости от того есть товар(деньги) на остатках или нет, зачем вам тогда блокировки? Можете их просто не устанавливать, или прописать и закомментировать до лучших времён. Если же у вас производится контроль остатков то как правило это 3-4 регистра, ну максимум 10-ок. Контроль можно подвесить как в общие процедуры и функции, так и в модули набора записей РН. Код предельно простой, открываем синтаксис помошник - смотрим:
Блокировка = Новый БлокировкаДанных;
ЭлементБлокировки = Блокировка.Добавить("РегистрНакопления.ТоварыНаСкладах");
ЭлементБлокировки.УстановитьЗначение("Качество", Справочники.Качество.НайтиПоКоду("1"));
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
ЭлементБлокировки.ИсточникДанных = ДокументОбъект.ВозвратнаяТара;
ЭлементБлокировки.ИспользоватьИзИсточникаДанных("Номенклатура", "Номенклатура");
ЭлементБлокировки.ИспользоватьИзИсточникаДанных("Склад", "Склад");
Блокировка.Заблокировать();
Собственно всё сразу понятно - блокируем "товары на складх", 1 измерение становим в явном виде, значения 2-х других возьмём из источника данных - ТЧ документа.
Те кто читал книжки по 8.2 наверное помнят о "Новой логике проведения" - когда контроль остатков производится после записи движений документа. Задвались вопросом зачем это? А вот эту же табличку перерисуем так что контоль остатков и блокировка будут после записи движений:
Транзакция 1
Транзакция 2
Состояние остатков
Начало
|
1 шт
|
Начало
1 шт
|
|
1 шт
Списание с остатков
|
0 шт
|
Списание с остатков
-1 шт
Блокировка
|
-1 шт
Чтение остатков
Попытка блокировки
-1 шт
|
Ожидание на блокировке
-1 шт
|
Ожидание на блокировке
-1 шт
Завершение
Ожидание на блокировке
-1 шт
Блокировка
-1 шт
Чтение остатков
-1 шт
|
-1 шт
Отказ
0 шт
Разница с виду не значительная - прирост производительности получаем за счет того что на время списания остатков (запись их в базу, что, собственно занимает время) блокировки ещё нет. Блокировка возникает позже к концу транзакции, куда вынесен контроль отрицательных остатков, бизнес логике приложения это вполне удовлетворяет.
Зная для чего блокировки нужны можно действительно ими управлять исходя из бизнес задач которые вы решаете. СУБД разрабатываются исходя из предположения обеспечения максисальной защиты данных. В случае если вы, к примеру, осуществляете банковские транзакции блокировки должны быть везде и на максимальном уровне. Лучше заблокировать лишние записи, чем допустить противоречивость данных.
В случае же если вы продаёте булочки или шариковые ручки, на вряд ли вам нужно столь много блокировок. Браком и пересортом по человеческой вине вы теряете в сотни раз больше, чем могли бы в случае одновременного проведения двумя пользователеями двух одинаковых докуметов отгрузки.
Для варьирования между такими разными задачами в СУБД придумали уровни изоляции. Устанавливая уровень изоляции транзакций можно сказать СУБД какие блокировки накладывать в разных случаях (при записи и при чтении в транзакции) в разных случаях накладываются S (можно читать нельзя писать) или X (нельзя ни читать ни писать) блокировки.
Так в автоматическом режиме у вас почти всегда будет уровень изоляции SERIALIZABLE, который будет накладывать X блокировки где нужно и где не нужно, что будет существенно портить вам жизнь
А в управляемом у вас будет READ COMMITED, который будет накладывать и тут же снимать S блокировку при чтении, и X только при записи. Самый хитрый уровень. Быстро накладываемая S блокировка как раз позволяет проверить не наложена ли где на эти данные X блокировка, что и обеспечивает чтение только согласованных данных, как принято для данного уровня изоляции, а в случае если вы прочитали и выполнили действя, рекоммендованные в предыдущей статье, то не будет даже S блокировки при чтении, таким образом на уровне СУБД будет блокироваться только запись во время записи - что правильно и необходимо для сограсованности данных.
Как же вы поступите с управляемыми блокировками - только ваше решение. Но я бы рекоммендовал не торопиться их устанавливать. Я встречал компании в которых был автоматический режим блокировки, при этом слово "замучали блокировки" звучало даже из уст генерального директора, и при этом был отключен контроль отрицательных остатков....
Для чего нужны блокировки
26.09.11
Разработка - Механизмы платформы 1С
Многие программисты "борются" с блокировками, но в попытках их "победить" не всегда задумываются "зачем они вообще нужны?" "а может от них совсем отказаться?" удивительно, но факт - от блокировок можно просто отказаться.
См. также
Механизмы платформы 1С Программист Стажер Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)
Эта небольшая статья - некоторого рода шпаргалка по файловым потокам: как и зачем с ними работать, какие преимущества это дает.
23.06.2024 7390 bayselonarrend 19
Механизмы платформы 1С Программист Стажер Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)
Пример использования «Сервисов интеграции» без подключения к Шине и без обменов.
13.03.2024 5930 dsdred 16
Перенос данных 1C Администрирование СУБД Механизмы платформы 1С Системный администратор Программист Стажер Платформа 1С v8.3 Бесплатно (free)
В платформе 8.3.17 появился замечательный механизм «Сервисы интеграции». Многие считают, что это просто коннектор 1С:Шины. Так ли это?
11.03.2024 14254 dsdred 64
Механизмы платформы 1С Программист Стажер Платформа 1С v8.3 Бесплатно (free)
Все мы используем массивы в своем коде. Это один из первых объектов, который дают ученикам при прохождении обучения программированию. Но умеем ли мы ими пользоваться? В этой статье я хочу показать все методы массива, а также некоторые фишки в работе с массивами.
24.01.2024 17588 YA_418728146 26
Перенос данных 1C Механизмы платформы 1С Системный администратор Программист Стажер Платформа 1С v8.3 Бесплатно (free)
Вы все еще регистрируете изменения только на Планах обмена и Регистрах сведений?
11.12.2023 11203 dsdred 44
Механизмы платформы 1С Программист Бесплатно (free)
Язык программирования 1С содержит много нюансов и особенностей, которые могут приводить к неожиданным для разработчика результатам. Сталкиваясь с ними, программист начинает лучше понимать логику платформы, а значит, быстрее выявлять ошибки и видеть потенциальные узкие места своего кода там, где позже можно было бы ещё долго медитировать с отладчиком в поисках источника проблемы. Мы рассмотрим разные примеры поведения кода 1С. Разберём результаты выполнения и ответим на вопросы «Почему?», «Как же так?» и «Зачем нам это знать?».
06.10.2023 23740 SeiOkami 48
Механизмы платформы 1С Системный администратор Платформа 1С v8.3 Бесплатно (free)
Начиная с версии платформы 8.3.22 1С снимает стандартные блокировки БД на уровне страниц. Делаем рабочий скрипт, как раньше.
14.09.2023 18796 human_new 27
WEB-интеграция Универсальные функции Механизмы платформы 1С Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)
При работе с интеграциями рано или поздно придется столкнуться с получением JSON файлов. И, конечно же, жизнь заставит проверять файлы перед тем, как записывать данные в БД.
28.08.2023 14714 YA_418728146 7
Комментарии
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Многие программисты "борются" с блокировками, но в попытках их "победить" не всегда задумываются "зачем они вообще нужны?" "а может от них совсем отказаться?" удивительно, но факт - от блокировок можно просто отказаться.
Вообще источник я :), если есть комментарии и вопросы - спрашивайте. Честно стыренная только картинка, потому как без неё не пропускали статью. Да и очевидно что "в официальных источниках" таки статьи не пропустят... к сожалению немного мы тут расходимся с позицией 1С. Статья родилась после беседы с генеральным директорам не мелкой компании, который говорил "как трудно им бороться с блокировками" из за большого количества ЗАКАЗОВ :). Товар скоропортящийся и его приходится ВЫКИДЫВАТЬ :).
вот за это -
У кого есть доступ конечно можно прочитать здесь: 1С озаботились написать достаточно доступную статью про блокировки данных. У кого же доступа нет в двух словах опишу для чего нужны блокировки:
минус оставил бы без зазрения совести ..
У кого есть доступ конечно можно прочитать здесь: 1С озаботились написать достаточно доступную статью про блокировки данных. У кого же доступа нет в двух словах опишу для чего нужны блокировки:
минус оставил бы без зазрения совести ..
Смысл колонки "Состояние остатков" в том чтобы показать физические остаки в СУБД без учета фиксации транзакций. Как раз чтобы показать как могут получиться "-1" в случае отсутствия блокировки при параллельном проведении, и почему 2-я транзакция откатывается.
В таблице 3 1-я транзакция считала остатки ещё до фиксации изменений 2-ой транзакцией. Соответственно минуса там ещё не было... но по сути списали они уже в "-". И если бы не было блокировки обе транзакции зафиксировались бы и получился бы "-".
В таблице 3 1-я транзакция считала остатки ещё до фиксации изменений 2-ой транзакцией. Соответственно минуса там ещё не было... но по сути списали они уже в "-". И если бы не было блокировки обе транзакции зафиксировались бы и получился бы "-".
(9) echo77, Я уж не знаю как подробнее - попробую так:
Имеем клиент-серверную систему и 2 запущенных клиента, оба подключены отладчиком к одному конфигуратору, в обоих открыт документ реализации всё заполнено, введено. В системе включена "новая логика проведения" и управляемые блокировки - когда остатки контролируются после проведения документа (т.е. сначала мы их пишем, потом уже проверяем на наличие отрицательных). Ставим точку останова перед процедурой наложения управляемой блокировки. Вот когда оба сеанса будут висеть на точке останова перед процедурой блокировки - снимаем остаки - там будет "-1". А потом отпускаем точку останова и смотрим как одна из транзакций "откатится", потому как будет ждать блокировку, а потом откатится, потому как получит "-1" в остатках.
Имеем клиент-серверную систему и 2 запущенных клиента, оба подключены отладчиком к одному конфигуратору, в обоих открыт документ реализации всё заполнено, введено. В системе включена "новая логика проведения" и управляемые блокировки - когда остатки контролируются после проведения документа (т.е. сначала мы их пишем, потом уже проверяем на наличие отрицательных). Ставим точку останова перед процедурой наложения управляемой блокировки. Вот когда оба сеанса будут висеть на точке останова перед процедурой блокировки - снимаем остаки - там будет "-1". А потом отпускаем точку останова и смотрим как одна из транзакций "откатится", потому как будет ждать блокировку, а потом откатится, потому как получит "-1" в остатках.
(0)(6)(7)
Олег.
На мой взгляд, в таблице #3 представлен странный алгоритм. Цель контроля - проверить отрицательные остатки? А если начальное состояние остатков, до начала обеих транзакций, достаточно для списания, то вторая транзакция зафиксируется? И что получится на остатках?
Мне представляется ошибочным посыл, что блокировки требуются "только там где производится контроль остатков"(с) в контексте "контроль отрицательных остатков"(с).
Режим "отключен контроль отрицательных остатков"(с) не означает, что остатки могут списываться произвольным образом. Для этого существует другой режим - "вообще не вести остатки". ;-) Например, у нас включен режим "разрешить отрицательные остатки" для розничного зала. Т.е. существует такой принцип - если продавец держит в руках товар, то он имеет право его продать (пробить чек), даже если в компьютерной базе остатки на нуле. Но эти "минуса", потом, тщательно анализируются складскими работниками и службой безопасности... ;-)
На мой взгляд любое изменение данных в БД состоит из трех этапов:
1) Чтение исходных данных в оперативную память.
2) Изменение исходных данных в оперативной памяти.
3) Запись нового значения в базу данных.
И если до выполнения этой последовательности не выполнить блокировку, то результат обновления базы данных будет искажен в многопользовательском режиме.
Или я ошибаюсь? ;-)
Олег.
На мой взгляд, в таблице #3 представлен странный алгоритм. Цель контроля - проверить отрицательные остатки? А если начальное состояние остатков, до начала обеих транзакций, достаточно для списания, то вторая транзакция зафиксируется? И что получится на остатках?
Мне представляется ошибочным посыл, что блокировки требуются "только там где производится контроль остатков"(с) в контексте "контроль отрицательных остатков"(с).
Режим "отключен контроль отрицательных остатков"(с) не означает, что остатки могут списываться произвольным образом. Для этого существует другой режим - "вообще не вести остатки". ;-) Например, у нас включен режим "разрешить отрицательные остатки" для розничного зала. Т.е. существует такой принцип - если продавец держит в руках товар, то он имеет право его продать (пробить чек), даже если в компьютерной базе остатки на нуле. Но эти "минуса", потом, тщательно анализируются складскими работниками и службой безопасности... ;-)
На мой взгляд любое изменение данных в БД состоит из трех этапов:
1) Чтение исходных данных в оперативную память.
2) Изменение исходных данных в оперативной памяти.
3) Запись нового значения в базу данных.
И если до выполнения этой последовательности не выполнить блокировку, то результат обновления базы данных будет искажен в многопользовательском режиме.
Или я ошибаюсь? ;-)
(8) hogik,
Давайте по порядку, а то чувствую это ещё пару раз спросят :)
И самое интересное:
Дело в том что так и происходит, более того блокировки на уровне СУБД будут, СУБД не даст вам нарушить ссылочную целостность, т.к. используется уровень изоляции READ COMMITED. Т.е. противроречивую информацию записать не получится. Но такие блокировки логичны с точки зрения "житейской логики", что позволило мне назвать статью "убираем блокировки" 90% из них это всё-таки чтение для контроля остатков
Или я ошибаюсь? ;-)
К сожалению именно так - вы ошибаетес, это оочень популярное заблуждение. Иначе я бы не заморачивался и не писал эту статью, чтобы по 10 раз одно и то же не объяснять.
Давайте по порядку, а то чувствую это ещё пару раз спросят :)
Режим "отключен контроль отрицательных остатков"(с) не означает, что остатки могут списываться произвольным образом
К сожалению именно это он и означает - остатки просто спсываются произвольным образом (речь не идёт о партиях)
Но эти "минуса", потом, тщательно анализируются складскими работниками и службой безопасности... ;-)
Вот как раз для вас статья. В рознице, конечно вам блокировки не нужны если у вас файловая версия в этом случае, а если все работают в одной базе то как раз для вас
И самое интересное:
На мой взгляд любое изменение данных в БД состоит из трех этапов:
1) Чтение исходных данных в оперативную память.
2) Изменение исходных данных в оперативной памяти.
3) Запись нового значения в базу данных.
И если до выполнения этой последовательности не выполнить блокировку, то результат обновления базы данных будет искажен в многопользовательском режиме.
1) Чтение исходных данных в оперативную память.
2) Изменение исходных данных в оперативной памяти.
3) Запись нового значения в базу данных.
И если до выполнения этой последовательности не выполнить блокировку, то результат обновления базы данных будет искажен в многопользовательском режиме.
Дело в том что так и происходит, более того блокировки на уровне СУБД будут, СУБД не даст вам нарушить ссылочную целостность, т.к. используется уровень изоляции READ COMMITED. Т.е. противроречивую информацию записать не получится. Но такие блокировки логичны с точки зрения "житейской логики", что позволило мне назвать статью "убираем блокировки" 90% из них это всё-таки чтение для контроля остатков
(10)
Олег.
Чувствую у нас получится перпендикулярный разговор. ;-)
Я "не понимаю" ЭТОГО:
1) "остатки просто спсываются произвольным образом (речь не идёт о партиях)"(с)
Т.е. несколько задач могут прочесть значение остатков в память, изменить их и записать в БД случайным образом? Например, три задачи в начале собственной транзакции считывают из БД значение остатка - 3 шт. Каждая вычитает из остатка по 1 шт. Получает значение 2 шт. И по мере возможности записывает в базу значение 2 шт. А мне казалось, что после выполнения этих трех транзакций на остатках должно образоваться нулевое значение. И какое это отношение имеет к партиям? Чем партии отличаются от "просто общих" остатков на складе по конкретной позиции товара?
2) "В рознице, конечно вам блокировки не нужны если у вас файловая версия в этом случае, а если все работают в одной базе то как раз для вас"(с)
Я не понял ЧТО "как раз для" меня? У меня нет никакой файловой версии. У меня нет даже никакой 1С-ины... :-) Всё, что написано в Вашей публикации применимо к любой ИС на любой СУБД. Точнее - не применимо.
3) "СУБД не даст вам нарушить ссылочную целостность, т.к. используется уровень изоляции READ COMMITED."(с)
Поясните, пожалуйста, какое отношение имеет "ссылочная целостность" к моему примеру из пункта #1.
Олег.
Чувствую у нас получится перпендикулярный разговор. ;-)
Я "не понимаю" ЭТОГО:
1) "остатки просто спсываются произвольным образом (речь не идёт о партиях)"(с)
Т.е. несколько задач могут прочесть значение остатков в память, изменить их и записать в БД случайным образом? Например, три задачи в начале собственной транзакции считывают из БД значение остатка - 3 шт. Каждая вычитает из остатка по 1 шт. Получает значение 2 шт. И по мере возможности записывает в базу значение 2 шт. А мне казалось, что после выполнения этих трех транзакций на остатках должно образоваться нулевое значение. И какое это отношение имеет к партиям? Чем партии отличаются от "просто общих" остатков на складе по конкретной позиции товара?
2) "В рознице, конечно вам блокировки не нужны если у вас файловая версия в этом случае, а если все работают в одной базе то как раз для вас"(с)
Я не понял ЧТО "как раз для" меня? У меня нет никакой файловой версии. У меня нет даже никакой 1С-ины... :-) Всё, что написано в Вашей публикации применимо к любой ИС на любой СУБД. Точнее - не применимо.
3) "СУБД не даст вам нарушить ссылочную целостность, т.к. используется уровень изоляции READ COMMITED."(с)
Поясните, пожалуйста, какое отношение имеет "ссылочная целостность" к моему примеру из пункта #1.
(12) hogik, Я просто думал я с чуть более опытным человеком, общаюсь, сорри.
1) Конечно пишутся не остатки а движения. Мы в итоге знаем сколько мы хотим записать, остатки на движения никак не влияют - это общая логика 1С, вам просто нужно прочитать где-то что есть таблица итогов, есть движения, пересчет итогов и т.п. - тогда поймёте.
2) Вот не всегда... дело в том что учет остатков в 1С - это 2 таблицы остатки и движения. пишем только движения, остатки регламентно пересчитываются. Остатки к примеру, в Dynamics Ax - это индекс на таблице движений там уже могут проблемы начаться при таком отношении...
3) Нуу мне просто в голову не приходила мысль что остатки можно считать а потом записать... в принципе в теории наверное можно, какую-нить свою систему придумать на этом принципе... поэтому я и сделал вывод что вы в целом боитесь только за разрушение данных и вас успокоил :)
1) Конечно пишутся не остатки а движения. Мы в итоге знаем сколько мы хотим записать, остатки на движения никак не влияют - это общая логика 1С, вам просто нужно прочитать где-то что есть таблица итогов, есть движения, пересчет итогов и т.п. - тогда поймёте.
2) Вот не всегда... дело в том что учет остатков в 1С - это 2 таблицы остатки и движения. пишем только движения, остатки регламентно пересчитываются. Остатки к примеру, в Dynamics Ax - это индекс на таблице движений там уже могут проблемы начаться при таком отношении...
3) Нуу мне просто в голову не приходила мысль что остатки можно считать а потом записать... в принципе в теории наверное можно, какую-нить свою систему придумать на этом принципе... поэтому я и сделал вывод что вы в целом боитесь только за разрушение данных и вас успокоил :)
(13)
Олег.
1) "Я просто думал я с чуть более опытным человеком, общаюсь"(с)
Опыт бывает разный и на разных системах полученный... ;-)
2) "пишем только движения, остатки регламентно пересчитываются"(с)
Вот это и есть "опыт 1С". В "нормальных" системах разработчики понимают, что "остатки регламентно" не пересчитываются, а существуют для оперативного использования - в любой момент мгновенное получение. К примеру, почти как в "Dynamics Ax"(с).
3) "Нуу мне просто в голову не приходила мысль что остатки можно считать а потом записать"(с)
А в этом алгоритме делается иначе?
Олег.
1) "Я просто думал я с чуть более опытным человеком, общаюсь"(с)
Опыт бывает разный и на разных системах полученный... ;-)
2) "пишем только движения, остатки регламентно пересчитываются"(с)
Вот это и есть "опыт 1С". В "нормальных" системах разработчики понимают, что "остатки регламентно" не пересчитываются, а существуют для оперативного использования - в любой момент мгновенное получение. К примеру, почти как в "Dynamics Ax"(с).
3) "Нуу мне просто в голову не приходила мысль что остатки можно считать а потом записать"(с)
А в этом алгоритме делается иначе?
3) "Нуу мне просто в голову не приходила мысль что остатки можно считать а потом записать"(с)
А в этом алгоритме делается иначе?
А в этом алгоритме делается иначе?
Не поверите - иначе :)))
В "нормальных" системах разработчики понимают, что "остатки регламентно" не пересчитываются
ммм... они как бы в любой момент доступны естетсвенно. Просто есть таблица остатков - к ней досчитываются обороты. Потом регламентно пересчитываются остатки и дописываются обороты - вполне адекватное решение. Кстати именно в этом моменте я очень подозрительно смотрю именно на Dynamicx Ax. Не было ещё опыта его эксплуатации с большим количеством пользователей, но чувствую там могут быть проблемы... и ещё какие...
(15)
Олег.
Последний к Вам вопрос. ;-)
Т.е. в методе ДобавитьРасход() не выполняется обновление остатков по "принципу" трех действий из (8) сообщения?
P.S. Остатки не могут быть "в любой момент доступны"(с), если "регламентно пересчитываются"(с), т.к. доступность остатков подразумевает их актуальность сразу после воздействия на них "документом" (в терминах 1С). Это не остатки, а жесть... ;-) Раньше это называлось пакетным расчетом (обработкой). Лет, так, 40 назад... :-)
P.P.S. Кстати об "Dynamicx Ax"(с). Рекомендую посмотреть как "ведутся" остатки в других системах. В некоторых, даже, на уровне обновления (интерактивного ввода) отдельной строки "документа". И такой режим, в частности, решает проблему ожидания блокировок. Т.к. в транзакциях выполняется только необходимые действия для отдельной "хозяйственной операции"(ХО), а не для искусственного объединения ХО в документы наделяемые удивительным понятием "провести документ". ;-)
Олег.
Последний к Вам вопрос. ;-)
Т.е. в методе ДобавитьРасход() не выполняется обновление остатков по "принципу" трех действий из (8) сообщения?
P.S. Остатки не могут быть "в любой момент доступны"(с), если "регламентно пересчитываются"(с), т.к. доступность остатков подразумевает их актуальность сразу после воздействия на них "документом" (в терминах 1С). Это не остатки, а жесть... ;-) Раньше это называлось пакетным расчетом (обработкой). Лет, так, 40 назад... :-)
P.P.S. Кстати об "Dynamicx Ax"(с). Рекомендую посмотреть как "ведутся" остатки в других системах. В некоторых, даже, на уровне обновления (интерактивного ввода) отдельной строки "документа". И такой режим, в частности, решает проблему ожидания блокировок. Т.к. в транзакциях выполняется только необходимые действия для отдельной "хозяйственной операции"(ХО), а не для искусственного объединения ХО в документы наделяемые удивительным понятием "провести документ". ;-)
(16) hogik,
методе ДобавитьРасход() не выполняется обновление остатков по "принципу" трех действий из (8) сообщения
- нет - не добавляются.
Остатки не могут быть "в любой момент доступны"(с), если "регламентно пересчитываются"
я просто объясняю "птичьим языком" но по этой теме много что написано... вдаваться в подробности не охота... смысл в том что в 1с остатки это всегда запрос по 2-м таблицам.
Рекомендую посмотреть как "ведутся" остатки в других системах.
эх... я бы с удовольствием... было бы время и доступ... но тут убить надо неделю, а интерес по сути чисто академический. Я пока видел как остатки ведутся в русских "Парус", "фолио".. по сравнению с ними 1с просто супер технологична. Видел подход в Dynamics... он просто другой.. пока ничего не могу сказать про него.
(18)
Олег.
Еще раз повторю.
Изначальный посыл Вашей статьи - ошибочен. И, естественно, дальнейшее обоснование - бессмысленны.
Блокировки нужны не "только там где производится контроль остатков"(с)
Они требуются в процессе, собственно, обновления остатков.
Т.к. во всех системах, для подобных задач, используется "принцип" трех действий из (8) сообщения. И эти блокировки следует "накладывать" даже если установлен режим "разрешить отрицательные остатки". Т.к. и отрицательные остатки должны быть верными, хотя и отрицательными. Выше по теме, я пояснил ВСЕ эти моменты.
Ставлю "минус" на публикацию, как предостережение пользователям от использования подобных методик... :-(
Олег.
Еще раз повторю.
Изначальный посыл Вашей статьи - ошибочен. И, естественно, дальнейшее обоснование - бессмысленны.
Блокировки нужны не "только там где производится контроль остатков"(с)
Они требуются в процессе, собственно, обновления остатков.
Т.к. во всех системах, для подобных задач, используется "принцип" трех действий из (8) сообщения. И эти блокировки следует "накладывать" даже если установлен режим "разрешить отрицательные остатки". Т.к. и отрицательные остатки должны быть верными, хотя и отрицательными. Выше по теме, я пояснил ВСЕ эти моменты.
Ставлю "минус" на публикацию, как предостережение пользователям от использования подобных методик... :-(
(20) hogik, Хорошо, согласен напишите свою конфигурацию, в которой вы будете
1) "Читать все остатки"
2) "МЕНЯЙТЕ ОСТАТКИ В ПАМЯТИ"
2) "ЗАПИСЫВАТЬ ОСТАТКИ"
И выложите на инфостат, а мы дружно на это всё посмотрим.... и откомментим конечно :))))). Сам лично "+" поставлю - чтобы подольше повисело и народ посмотрел.
1) "Читать все остатки"
2) "МЕНЯЙТЕ ОСТАТКИ В ПАМЯТИ"
2) "ЗАПИСЫВАТЬ ОСТАТКИ"
И выложите на инфостат, а мы дружно на это всё посмотрим.... и откомментим конечно :))))). Сам лично "+" поставлю - чтобы подольше повисело и народ посмотрел.
(31)
Олег.
Я не вижу никакой связи между моими сообщениями в данной теме и Вашим (31) сообщением. Алгоритмы изменения "остатков" ВСЕГДА и ВЕЗДЕ делаются так, как я написал в (8) сообщении. А для уменьшения времени блокировок не следует "Читать все остатки"(с) в одной транзакции с блокировками на всё время "проведения документа". Хотя я не уверен в Вашем понимании слова - "все". Это для всех строк документа? Если так - то по этому поводу я уже написал в данной теме... Ну, естественно, если в алгоритме производится "отдельное" чтение, с блокировкой, всех остатков по строкам документа для контроля "отрицательности", а потом выполняется реальное обновление БД, - то это не продуктивно. Но, для решения подобных задач, думаю, не следует уходить в сторону "раздолбайства" в части содержания БД. А Ваша статья к этому и призывает... :-(
Еще раз. Я привел пример того, что будет с остатками при использовании Вашей методы в (12) сообщении. Это так?
Олег.
Я не вижу никакой связи между моими сообщениями в данной теме и Вашим (31) сообщением. Алгоритмы изменения "остатков" ВСЕГДА и ВЕЗДЕ делаются так, как я написал в (8) сообщении. А для уменьшения времени блокировок не следует "Читать все остатки"(с) в одной транзакции с блокировками на всё время "проведения документа". Хотя я не уверен в Вашем понимании слова - "все". Это для всех строк документа? Если так - то по этому поводу я уже написал в данной теме... Ну, естественно, если в алгоритме производится "отдельное" чтение, с блокировкой, всех остатков по строкам документа для контроля "отрицательности", а потом выполняется реальное обновление БД, - то это не продуктивно. Но, для решения подобных задач, думаю, не следует уходить в сторону "раздолбайства" в части содержания БД. А Ваша статья к этому и призывает... :-(
Еще раз. Я привел пример того, что будет с остатками при использовании Вашей методы в (12) сообщении. Это так?
(36)READ COMMITTED не даст даже считать данные пока не завершится транзакция. Так, что не получится в 12 пункт 1, что и должно быть. А про то, что он говорит больше похоже на READ_COMMITTED_SNAPSHOT - пишущие транзакции не блокируют читающих, и читающие транзакции не блокируют пишущих.
(37)
Ну, тогда, я ничего не понимаюв колбасных обрезках в СУБД. ;-)
"Read committed: ...в процессе работы одной транзакции другая может быть успешно завершена и сделанные ею изменения зафиксированы. В итоге первая транзакция будет работать с другим набором данных..."(с). Т.е., в моём примере из (12) сообщения три задачи прочли начальное значение остатков равное тройке, пока не произошло изменение этого количества из другой транзакции. И поехали вычислять остатки относительно этого количества. Для этого и требуется блокировка при чтении начальных остатков. Так?
Ну, тогда, я ничего не понимаю
"Read committed: ...в процессе работы одной транзакции другая может быть успешно завершена и сделанные ею изменения зафиксированы. В итоге первая транзакция будет работать с другим набором данных..."(с). Т.е., в моём примере из (12) сообщения три задачи прочли начальное значение остатков равное тройке, пока не произошло изменение этого количества из другой транзакции. И поехали вычислять остатки относительно этого количества. Для этого и требуется блокировка при чтении начальных остатков. Так?
(39)(40)
Олег.
В процессе общения люди задают вопросы друг-другу по двум причинам:
1) Хотят понять суть обсуждения.
2) Хотят понять понимание сути собеседником.
Я Вам задаю вопросы по второй причине... ;-)
И это не "флуд", а нормальный, учтивый (уважительный) диалог с собеседником. Конечно, можно было написать, как написано в (3) сообщении и влепить "минус" на публикацию. И я не делаю подобного по отношению к Вашей "другая статья"(с), т.к. там и говорить (комментировать) нечего. :-(
А, если говорить по этой статье и Вашим пояснениям в комментариях, то - это полная пурга. Ну, например, прочтите собственную фразу: "о "Новой логике проведения" - когда контроль остатков производится после записи движений документа. "(с) и сопоставьте с Вашей трактовкой этого алгоритма таблицей #3. А какое, вообще, имеет отношение контроль остатков, если, по Вашим утверждениям: "Остатки считываются, но не меняются "(с). Т.е., по Вашему мнению, всегда просматривается всё движение каждый раз для выяснения значения остатков? А вторая таблица существует для проформы. ;-) Ну, или она существует для "регламентного" пересчета. Но тогда зачем, вообще, говорить о самом понятии "остатки" в алгоритмах "проведения документов". И не важно - отключена проверка отрицательности или она включена. Остатки, то всегда не актуальные, пока их не пересчитают "регламентной" обработкой.
Ох. И т.д. ...
А по поводу: "принято "раздолбайство" с отрицательными остатками, а в ИТ идёт "борьба с блокировками" то для нормальных людей это как-то не логично :)"(с), то, думаю, имеет смысл уточнить - кого Вы, в данном случае, называете нормальными людьми... :-)
P.S. Олег. Послушайте совет старого человека. Перечитайте, пожалуйста, свою статью и наше с Вами обсуждения. И попробуйте, изложить мою "позицию". Есть такой прием, когда собеседники не понимают друг-друга из-за того, что разговаривают о разных "вещах". Частенько это помогает избежать "мордобития"...
Олег.
В процессе общения люди задают вопросы друг-другу по двум причинам:
1) Хотят понять суть обсуждения.
2) Хотят понять понимание сути собеседником.
Я Вам задаю вопросы по второй причине... ;-)
И это не "флуд", а нормальный, учтивый (уважительный) диалог с собеседником. Конечно, можно было написать, как написано в (3) сообщении и влепить "минус" на публикацию. И я не делаю подобного по отношению к Вашей "другая статья"(с), т.к. там и говорить (комментировать) нечего. :-(
А, если говорить по этой статье и Вашим пояснениям в комментариях, то - это полная пурга. Ну, например, прочтите собственную фразу: "о "Новой логике проведения" - когда контроль остатков производится после записи движений документа. "(с) и сопоставьте с Вашей трактовкой этого алгоритма таблицей #3. А какое, вообще, имеет отношение контроль остатков, если, по Вашим утверждениям: "Остатки считываются, но не меняются "(с). Т.е., по Вашему мнению, всегда просматривается всё движение каждый раз для выяснения значения остатков? А вторая таблица существует для проформы. ;-) Ну, или она существует для "регламентного" пересчета. Но тогда зачем, вообще, говорить о самом понятии "остатки" в алгоритмах "проведения документов". И не важно - отключена проверка отрицательности или она включена. Остатки, то всегда не актуальные, пока их не пересчитают "регламентной" обработкой.
Ох. И т.д. ...
А по поводу: "принято "раздолбайство" с отрицательными остатками, а в ИТ идёт "борьба с блокировками" то для нормальных людей это как-то не логично :)"(с), то, думаю, имеет смысл уточнить - кого Вы, в данном случае, называете нормальными людьми... :-)
P.S. Олег. Послушайте совет старого человека. Перечитайте, пожалуйста, свою статью и наше с Вами обсуждения. И попробуйте, изложить мою "позицию". Есть такой прием, когда собеседники не понимают друг-друга из-за того, что разговаривают о разных "вещах". Частенько это помогает избежать "мордобития"...
(41) hogik,
Вы узко мыслите, вы так и не можете понять что происходит внутри 1с. В комментариях к моей другой статье человек достаточно чётко написал как на практике происходит - если вам лень читать теорию прочитайте хотя бы что он пишет. Сама таблица остатков не меняется в 1с. Меняется таблица движений, собственно моя таблица 3 абсолютно корректна.
Послушайте совет старого человека
Вы узко мыслите, вы так и не можете понять что происходит внутри 1с. В комментариях к моей другой статье человек достаточно чётко написал как на практике происходит - если вам лень читать теорию прочитайте хотя бы что он пишет. Сама таблица остатков не меняется в 1с. Меняется таблица движений, собственно моя таблица 3 абсолютно корректна.
(42)
Олег.
Считаю Ваше (42) сообщение хамским. Мы, вроде, обсуждаем 1С и СУБД, а не узость мышления и понятливости собеседника.
Но, переходя на личности. Увы... :-(
Ваша фраза: "Сама таблица остатков не меняется в 1с."(с) - полный бред.
"Регистр накопления остатков состоит из двух таблиц: таблицы движения и таблицы итогов. В таблице движений хранятся записи, которые либо вводятся пользователем вручную, либо генерируются в процессе проведения документа или исполнения обработки. Таблица движений имеет следующую структуру: 1. Период 2. Регистратор 3. Номер строки 4. Вид движения 5. <Измерения> 6. <Ресурсы> 7. <Реквизиты> В таблице итогов хранятся остатки в разрезе всех измерений с периодичностью месяц, на начало месяца. Временной интервал, за который хранятся остатки, ограничивается установкой периода рассчитанных итогов. Период рассчитанных итогов указывается как последний день месяца, по который рассчитаны итоги. То есть если период рассчитанных итогов равен 31.07.2004, то итоги будут рассчитаны по 01.08.2004 включительно. Кроме того, в таблице итогов отдельно хранятся актуальные итоги. Таблица итогов имеет следующую структуру: 1. Период 2. <Измерения> 3. <Ресурсы> Если период рассчитанных итогов равен 31.07.2004, а самое раннее движение было сделано 02.05.2004, то итоги будут хранится за следующие периоды: 01.06.2004, 01.07.2004, 01.08.2004 и актуальные итоги."
Олег.
Считаю Ваше (42) сообщение хамским. Мы, вроде, обсуждаем 1С и СУБД, а не узость мышления и понятливости собеседника.
Но, переходя на личности. Увы... :-(
Ваша фраза: "Сама таблица остатков не меняется в 1с."(с) - полный бред.
"Регистр накопления остатков состоит из двух таблиц: таблицы движения и таблицы итогов. В таблице движений хранятся записи, которые либо вводятся пользователем вручную, либо генерируются в процессе проведения документа или исполнения обработки. Таблица движений имеет следующую структуру: 1. Период 2. Регистратор 3. Номер строки 4. Вид движения 5. <Измерения> 6. <Ресурсы> 7. <Реквизиты> В таблице итогов хранятся остатки в разрезе всех измерений с периодичностью месяц, на начало месяца. Временной интервал, за который хранятся остатки, ограничивается установкой периода рассчитанных итогов. Период рассчитанных итогов указывается как последний день месяца, по который рассчитаны итоги. То есть если период рассчитанных итогов равен 31.07.2004, то итоги будут рассчитаны по 01.08.2004 включительно. Кроме того, в таблице итогов отдельно хранятся актуальные итоги. Таблица итогов имеет следующую структуру: 1. Период 2. <Измерения> 3. <Ресурсы> Если период рассчитанных итогов равен 31.07.2004, а самое раннее движение было сделано 02.05.2004, то итоги будут хранится за следующие периоды: 01.06.2004, 01.07.2004, 01.08.2004 и актуальные итоги."
(44) hogik, ладно, закроем вопрос - если из поста выше вы не сделали правильных выводов - всё равно не поймёте. Только не надо больше писать комментариев о том "как же тут сильно я не прав" чтобы людей не смущать теоретическими изысканиями. Я просто проверяю на практике в таких случаях - на практике всё работает именно так как надо и никаких нарушений целостности и конфликтов :)
(36) hogik, Вы так ничего и не поняли :(((( в моей статье НЕ ИДЁТ РЕЧЬ ОБ ИЗМЕНЕНИИ ЛОГИКИ РАБОТЫ С БД об этом у меня другая статья :). В статье идёт речь лишь о соответствии системы логике работы на предприятии. Если принято "раздолбайство" с отрицательными остатками, а в ИТ идёт "борьба с блокировками" то для нормальных людей это как-то не логично :).
P.S.
P.S.
Я привел пример того, что будет с остатками при использовании Вашей методы в (12) сообщении. Это так?
Так не будет! Вместо Флуда в комментариях взяли бы и проверили.
(20)
Относительно 1С:
а)Блокировки данных при записи выполняются на уровне СУБД (+проверяется платформой).
б)Остатки в базе считаются и пишутся на уровне платформы.
Выводы:
а) Записать неверные данные в БД вы не сможете физически, никакие блокировки тут не при чем. Если вы попробуете, например, дважды записать в регистр запись с повторяющимся набором всех измерений, то вывалится ошибка SQL нарушение уникальности индекса и ничего не выйдет. Т.е. кривые данные с точки зрения СУБД (повторяющиеся абсолютно одинаковые строки в таблице и т.п.) вы записать впринципе не сможете. Еще в платформу встроен механизм проверки корректности данных, ведь в файловом варианте она сама является сервером СУБД.
б) Если платформа что-то накосячит с записью остатков (что маловероятно, т.к. алгоритмы максимально протестированы и отптимизированыи и используются еще с 7.7 а то и раньше), то есть регламентная процедура "Пересчет итогов регистров накопления". Блокировки тут устанавливает тоже платформа и от конфигурации и типа блокировок в конфигурации абсолютно ничего не зависит.
Итог: На уровне конфигурации вы можете накладывать блокировки только на чтение данных, т.е. прочитали - заблокировали - начали что-то писать. На целостность данных это никак не влияет. Просто другая транзакция не сможет прочитать те же данные. А так как на уровне конфигурации вы пишете только движения документа, то даже без всяких блокировок остатки будут верными. Просто без блокировки во время чтения данных внутри транзакции СУБД может показать возможно неверный результат запроса, если есть незавершенные транзакции, работающие с этими данными и эти транзакции завершаться успешно. Следовательно если контроль остатков внутри транзакции не нужен, то и блокировки никуда не уперлись.
Относительно 1С:
а)Блокировки данных при записи выполняются на уровне СУБД (+проверяется платформой).
б)Остатки в базе считаются и пишутся на уровне платформы.
Выводы:
а) Записать неверные данные в БД вы не сможете физически, никакие блокировки тут не при чем. Если вы попробуете, например, дважды записать в регистр запись с повторяющимся набором всех измерений, то вывалится ошибка SQL нарушение уникальности индекса и ничего не выйдет. Т.е. кривые данные с точки зрения СУБД (повторяющиеся абсолютно одинаковые строки в таблице и т.п.) вы записать впринципе не сможете. Еще в платформу встроен механизм проверки корректности данных, ведь в файловом варианте она сама является сервером СУБД.
б) Если платформа что-то накосячит с записью остатков (что маловероятно, т.к. алгоритмы максимально протестированы и отптимизированыи и используются еще с 7.7 а то и раньше), то есть регламентная процедура "Пересчет итогов регистров накопления". Блокировки тут устанавливает тоже платформа и от конфигурации и типа блокировок в конфигурации абсолютно ничего не зависит.
Итог: На уровне конфигурации вы можете накладывать блокировки только на чтение данных, т.е. прочитали - заблокировали - начали что-то писать. На целостность данных это никак не влияет. Просто другая транзакция не сможет прочитать те же данные. А так как на уровне конфигурации вы пишете только движения документа, то даже без всяких блокировок остатки будут верными. Просто без блокировки во время чтения данных внутри транзакции СУБД может показать возможно неверный результат запроса, если есть незавершенные транзакции, работающие с этими данными и эти транзакции завершаться успешно. Следовательно если контроль остатков внутри транзакции не нужен, то и блокировки никуда не уперлись.
(79)
Алексей (a-novoselov).
Я с Вашими "Выводы"(с):
а) Согласен.
б) Согласен. Но, с оговоркой. Регламентные процедуры призваны обеспечивать (исправлять) актуальность и достоверность "итоговых" данных для "учетных"/"отчетных" систем. Т.е. когда "итоги" используются значительно позже совершения ХО. Например, в бухгалтерских "учетах", АвтоМехАнизированных по принципу - а потом бухгалтер (специальный оператор) берет в руки бумажный документ и "заводит" его в базу данных. И в таких "системах" не проявляется "проблема" с блокировками и/или монопольным пересчетом итогов.
А с Вашим "Итог"(с) - не могу согласиться. Т.к. если "вы пишете только движения документа"(с), то и темы для разговора не существует. Мне представляется, что разговор идет об чтении записи с целью её изменения (суть самого понятия "итоги") несколькими процессами (сессиями 1С). И в этом случае блокировка (возможно и не средствами СУБД) записи - обязательна, если есть желание получить достоверные и актуальные данные.
(81)
Олег.
Я оказался прав - для Вас "готовые системы" растут на полках магазинов. :-)
И Ваша фраза "Разработка системы это когда 10 экстра профи месяц..."(с) подтверждает мою правоту. Т.к. в "Oracle или Microsoft, ещё в SAP"(с) это делается гораздо дольше. И делается на протяжении всей жизни и развития "проекта". И важным моментом таких "проектов" является возможность расширения функционала, дабы конечному пользователю не приходилось покупать и внедрять, уже, собственную систему каждый раз как только ТЕ разработчик поймут, что они ошиблись в самом начале своего "проекта". А 1С-продуктам на это наплевать... ;-)
Что касается Вашей фразы:
"Покажите им свою разработку - они вас примут разработчиком :)."(с)
Неужели, Вы думаете, что за 38 лет общения с ЭВМ-ами, я занимался только ковырянием в 1С-е...
(84)
(cool.vlad4)
"потому как не понял (72)"(с)
Как!? Чего? Совсем? Всё? :-( :-( :-(
Если хотите, то давайте я попробую пояснить свой текст.
Видимо, я очень плохо изложил свои мыслишки...
Алексей (a-novoselov).
Я с Вашими "Выводы"(с):
а) Согласен.
б) Согласен. Но, с оговоркой. Регламентные процедуры призваны обеспечивать (исправлять) актуальность и достоверность "итоговых" данных для "учетных"/"отчетных" систем. Т.е. когда "итоги" используются значительно позже совершения ХО. Например, в бухгалтерских "учетах", АвтоМехАнизированных по принципу - а потом бухгалтер (специальный оператор) берет в руки бумажный документ и "заводит" его в базу данных. И в таких "системах" не проявляется "проблема" с блокировками и/или монопольным пересчетом итогов.
А с Вашим "Итог"(с) - не могу согласиться. Т.к. если "вы пишете только движения документа"(с), то и темы для разговора не существует. Мне представляется, что разговор идет об чтении записи с целью её изменения (суть самого понятия "итоги") несколькими процессами (сессиями 1С). И в этом случае блокировка (возможно и не средствами СУБД) записи - обязательна, если есть желание получить достоверные и актуальные данные.
(81)
Олег.
Я оказался прав - для Вас "готовые системы" растут на полках магазинов. :-)
И Ваша фраза "Разработка системы это когда 10 экстра профи месяц..."(с) подтверждает мою правоту. Т.к. в "Oracle или Microsoft, ещё в SAP"(с) это делается гораздо дольше. И делается на протяжении всей жизни и развития "проекта". И важным моментом таких "проектов" является возможность расширения функционала, дабы конечному пользователю не приходилось покупать и внедрять, уже, собственную систему каждый раз как только ТЕ разработчик поймут, что они ошиблись в самом начале своего "проекта". А 1С-продуктам на это наплевать... ;-)
Что касается Вашей фразы:
"Покажите им свою разработку - они вас примут разработчиком :)."(с)
Неужели, Вы думаете, что за 38 лет общения с ЭВМ-ами, я занимался только ковырянием в 1С-е...
(84)
(cool.vlad4)
"потому как не понял (72)"(с)
Как!? Чего? Совсем? Всё? :-( :-( :-(
Если хотите, то давайте я попробую пояснить свой текст.
Видимо, я очень плохо изложил свои мыслишки...
(85) hogik, Да, бюджеты и количество народа конечно несравненно больше. Поэтому "русскими энтузиастами" должны бы руководить грамотные менеджеры проектов, а то и получается то что вы написали. Мне нравится то что 1С пытаются сделать... Просто есть понятие "Жизненный цикл" продукта, естественно есть методология, поэтому так сказать как вы "всё неправильно и нужно всё переписать" легко, а вот сделать :)))
Автору + действительно полезная тема, сам сталкивался с таким на производственном предприятии, работаю круглые сутки, блокировки возникали очень часто бухгалтерия и диспетчера ругали 1С 8 кто как мог :) Но ничего все решилось и счастье все довольны, пришлось потрудиться конечно, но результат говорит сам за себя за последние 2 года об блокировках уже давно забыли на предприятии....
я бы тоже наверное минус поставил. На этот раз википедии доверяю больше
Блокировка (англ. lock) в СУБД — это отметка о захвате объекта транзакцией в ограниченный или исключительный доступ с целью предотвращения коллизий и поддержания целостности данных.
(136)
Вполне можно отказаться. При открытии формы документа заменять ее на форму не имеющего основного реквизита ДокументОбъект. Тогда блокировка устанавливаться не будет. Считывать в нее реквизиты объекта. При закрытии кнопкой ОК еще раз считывать изменения из БД и сравнивать изменения, внесенные пользователем с состоянием документа в БД на ммоент записи. Если данные изменения не противоречат друг другу (например один пользователи изменил цену, а второй вписал что-то в поле комментарий), то объединить эти изменения. Примерно так.
comol пишет:
В вашем случае при интерактивном изменении объекта будут объектные блокировки, от них отказаться никак
В вашем случае при интерактивном изменении объекта будут объектные блокировки, от них отказаться никак
Вполне можно отказаться. При открытии формы документа заменять ее на форму не имеющего основного реквизита ДокументОбъект. Тогда блокировка устанавливаться не будет. Считывать в нее реквизиты объекта. При закрытии кнопкой ОК еще раз считывать изменения из БД и сравнивать изменения, внесенные пользователем с состоянием документа в БД на ммоент записи. Если данные изменения не противоречат друг другу (например один пользователи изменил цену, а второй вписал что-то в поле комментарий), то объединить эти изменения. Примерно так.
(138) nafa, а если оба изменили цену, как решать чья останется? "Кто первый встал того и тапки" или "Кто последний тот и прав"? Если содержание реквизита Комментарий зависит от реквизита Цена и с новой ценой новый комментарий приводит к искажению данных?
И зачем при этом обязательно открывать форму без основного реквизита? Открываете с основным, если уж все равно будете создавать в памяти новый экземпляр объекта.
И зачем при этом обязательно открывать форму без основного реквизита? Открываете с основным, если уж все равно будете создавать в памяти новый экземпляр объекта.
(145) red80,
Точно также как делается объединение во всяких SVN, GIT и т.п. Выдавать сообщение о том что вносимые изменения противоречат изменениям другого пользователя. Дальше пусть сам решает что делать (обычно в таких случаях пользователи созваниваются и решают чьи изменения оставить). Если поле Комментарий логически связано с ценой, то соответственно выдавать это сообщение в ситуации когда один меняет цену другой комментарий.
Вы правы в том, что здесь безусловно есть некий риск того что изменения формально не мешают друг другу, а логически не совместимы. Но это решается уже организационными мерами.
Не обязательно, просто возможный вариант решения.
(148) hogik,
Не совсем понятно, о чем речь. Если о 7.7 как платформе то вполне можно. До объема 10 пользователей/100 документов на всех в день вполне тянет в файловом варианте на терминал-сервере. А это объем работы 95% организаций использующих 1С. И всю логику, необходимую организациям ткого размера вполне можно реализовывать, не особенн задумаваясь об ограничениях платформы.
nafa, а если оба изменили цену, как решать чья останется? ...Если содержание реквизита Комментарий зависит от реквизита Цена и с новой ценой новый комментарий приводит к искажению данных?
Точно также как делается объединение во всяких SVN, GIT и т.п. Выдавать сообщение о том что вносимые изменения противоречат изменениям другого пользователя. Дальше пусть сам решает что делать (обычно в таких случаях пользователи созваниваются и решают чьи изменения оставить). Если поле Комментарий логически связано с ценой, то соответственно выдавать это сообщение в ситуации когда один меняет цену другой комментарий.
Вы правы в том, что здесь безусловно есть некий риск того что изменения формально не мешают друг другу, а логически не совместимы. Но это решается уже организационными мерами.
И зачем при этом обязательно открывать форму без основного реквизита?
Не обязательно, просто возможный вариант решения.
(148) hogik,
Или Вы считаете, что на "семерке" (без её доработки) можно иметь нечто большее чем примитивную однопользовательскую учетную систему бумажных документов?
Не совсем понятно, о чем речь. Если о 7.7 как платформе то вполне можно. До объема 10 пользователей/100 документов на всех в день вполне тянет в файловом варианте на терминал-сервере. А это объем работы 95% организаций использующих 1С. И всю логику, необходимую организациям ткого размера вполне можно реализовывать, не особенн задумаваясь об ограничениях платформы.
(150)
Виталий (nafa).
"А это объем работы 95% организаций использующих 1С"(с)
Я работаю в организации, которая попадает в 5%. :-)
"Не совсем понятно, о чем речь ... документов на всех ..."(с)
Речь и о платформе и о "документах". У нас не стояла задачи АвтоМехАнизировать складирование бумажных документов в "бухгалтерские" пачки. ;-)
Виталий (nafa).
"А это объем работы 95% организаций использующих 1С"(с)
Я работаю в организации, которая попадает в 5%. :-)
"Не совсем понятно, о чем речь ... документов на всех ..."(с)
Речь и о платформе и о "документах". У нас не стояла задачи АвтоМехАнизировать складирование бумажных документов в "бухгалтерские" пачки. ;-)
(152) hogik,
В (68) написано
Зачем вы выложили ссылки, если там же указали что это не работает?
А почему Вы сделали такой вывод?
В (68) написано
А т.к. в "центральном" сервере уже работало до 30 человек, и на DBF-ах сильно страдала надежность, то поменяли "движок" на клиент-серверную СУБД.
Зачем вы выложили ссылки, если там же указали что это не работает?
Данный "проект" - закрыт.
(153)
"Зачем вы выложили ссылки, если там же указали что это не работает?"(с)
На первом решении мы работали год. На втором работаем пять лет.
Первое решение "не работает" по моим оценкам и МОЕМУ понятию "работать".
Решение на CodeBase (первое), в части соблюдения ACID, работает точно так же как и решение 1С-а на MS SQL. И я считаю, что в ОБОИХ случаях это неработоспособная система.
В части надежности - это замечание не касается основного режима использования разработки, т.е. клиент-серверного режима. А про режим ПДБД (файл-серверный) написано и в первой версии описания разработки. Про его назначение и условия выполнения. На самом деле, этот режим не требуется при эксплуатации системы.
"В (68) написано"(с)
Ну, теперь мне удалось изложить своё мнение/понимание про термин "клиент-сервер" ? :-)
Вот так: "клиент-серверная СУБД"<>"SQL".
"Зачем вы выложили ссылки, если там же указали что это не работает?"(с)
На первом решении мы работали год. На втором работаем пять лет.
Первое решение "не работает" по моим оценкам и МОЕМУ понятию "работать".
Решение на CodeBase (первое), в части соблюдения ACID, работает точно так же как и решение 1С-а на MS SQL. И я считаю, что в ОБОИХ случаях это неработоспособная система.
В части надежности - это замечание не касается основного режима использования разработки, т.е. клиент-серверного режима. А про режим ПДБД (файл-серверный) написано и в первой версии описания разработки. Про его назначение и условия выполнения. На самом деле, этот режим не требуется при эксплуатации системы.
"В (68) написано"(с)
Ну, теперь мне удалось изложить своё мнение/понимание про термин "клиент-сервер" ? :-)
Вот так: "клиент-серверная СУБД"<>"SQL".
(32) я ту статью увидел второй и собственно их порядок не регламентирован (стоило бы указать тогда часть1, часть2 и ссылка), насчет ноухау, - о данной sql фиче я знал, но по поводу использования в 1С, да пожалуй ноухау.
(33) я и понял потом(после прочтения той статьи) о чем речь, почему и посоветовал выражатся яснее
(33) я и понял потом(после прочтения той статьи) о чем речь, почему и посоветовал выражатся яснее
Вы узко мыслите, вы так и не можете понять что происходит внутри 1с.
Терзают смутные сомнения, что так вы никому ничего не объясните. Стоит написать вводную(но не от слова вода;-)) статью. Тезис, основная мысль, ввести используемые термины и сокращения(что б не прыгать потом с блокировок БД на блокировки 1С), ну и т.д. Вы это знаете получше меня. Всем будет интересно.
Для читателей, которые будут пытаться разобраться в "публикации" и комментариям к ней.
В таблице #3 описана последовательность действий:
Начало
Списание с остатков
Блокировка
Чтение остатков
Завершение
На самом деле рекомендовано так:
"В самом конце транзакции в явном виде записать движения по тем регистрам, которые требуют контроля остатков. Для наборов записей этих регистров следует установить опцию "БлокироватьДляИзменения" в значение ИСТИНА. ... Именно в этот момент времени будет установлена блокировка остатков регистра по данному набору значений измерений. "(с) [ссылка в конце]
Т.е. последовательность действий, примерно, вот такая:
Начало
............ (другие действия)
Блокировка
Списание с остатков
Чтение остатков (если нужен контроль "отрицательности")
Завершение
И она (блокировка) ВСЕГДА должна накладываться, т.к. служит не только для проверки остатков, но и для корректной записи движения по регистрам в части "итоговых" данных.
Повторю своё утверждение: "и отрицательные остатки должны быть верными, хотя и отрицательными"(с) И это никак не связано с тем, что "вы продаёте булочки или шариковые ручки"(с).
P.S. Очень странно, что Гилёв Вячеслав (gilv) дал положительную оценку данной "публикации", написав вот эту статью:
В таблице #3 описана последовательность действий:
Начало
Списание с остатков
Блокировка
Чтение остатков
Завершение
На самом деле рекомендовано так:
"В самом конце транзакции в явном виде записать движения по тем регистрам, которые требуют контроля остатков. Для наборов записей этих регистров следует установить опцию "БлокироватьДляИзменения" в значение ИСТИНА. ... Именно в этот момент времени будет установлена блокировка остатков регистра по данному набору значений измерений. "(с) [ссылка в конце]
Т.е. последовательность действий, примерно, вот такая:
Начало
............ (другие действия)
Блокировка
Списание с остатков
Чтение остатков (если нужен контроль "отрицательности")
Завершение
И она (блокировка) ВСЕГДА должна накладываться, т.к. служит не только для проверки остатков, но и для корректной записи движения по регистрам в части "итоговых" данных.
Повторю своё утверждение: "и отрицательные остатки должны быть верными, хотя и отрицательными"(с) И это никак не связано с тем, что "вы продаёте булочки или шариковые ручки"(с).
P.S. Очень странно, что Гилёв Вячеслав (gilv) дал положительную оценку данной "публикации", написав вот эту статью:
(47) hogik, Вы опять за старое :). Вы не понимаете - управляемая блокировка НЕ ИМЕЕТ НИКАКОГО ОТНОШЕНИЯ к методике записи движений и итогов в 1С. В типовых конфигурациях 1С (в т.ч. в УТ) если посмотрите упрвляемые блокировки есть только на несколько регистров (товары на складах и взаиморасчеты) по остальным их нет. Вы так и не сможете сложить в голове полную картину если будете читать только отдельные посты и статьи.
(49)
Олег.
Вы в своей статье написали:
"...паразительно как много людей об этом не знают."(с)
Представьте себе, что я отношусь к этим МНОГИМ. :-)
Далее, Вы даёте "ценную" рекомендацию:
"установить управляемые блокировки там где это нужно"(с)
В Вашем понимании это:
"только там где производится контроль остатков"(с)
Далее Вы пишете, что:
"Браком и пересортом по человеческой вине вы теряете в сотни раз больше, чем могли бы в случае одновременного проведения двумя пользователеями двух одинаковых докуметов отгрузки."(с)
Из этой фразы, лично я, делаю однозначный вывод: на остатках будут получаться произвольные числа. Пытаюсь, разобраться. Смотрю таблицу #3. Вызывает удивление. Спрашиваю. Получаю от Вас ответ:
"остатки просто спсываются произвольным образом (речь не идёт о партиях)"(с)
Пытаюсь дальше спрашивать. И получаю от Вас информацию:
"Остатки считываются, но не меняются "(с).
Но, тогда, зачем говорить о блокировках, если ничего не меняется.
Дык, может меняется? ;-)
А теперь ВНИМАТЕЛЬНО читаем (53) сообщение...
P.S.
Т.е. Ваша "статья" сводится к одной "мысли":
Если блокировки "мешают" системе работать быстро, то надо убрать ВСЕ лишние блокировки. И оставить только нужные.
Думаю, об этом многие люди догадываются... :-)
Олег.
Вы в своей статье написали:
"...паразительно как много людей об этом не знают."(с)
Представьте себе, что я отношусь к этим МНОГИМ. :-)
Далее, Вы даёте "ценную" рекомендацию:
"установить управляемые блокировки там где это нужно"(с)
В Вашем понимании это:
"только там где производится контроль остатков"(с)
Далее Вы пишете, что:
"Браком и пересортом по человеческой вине вы теряете в сотни раз больше, чем могли бы в случае одновременного проведения двумя пользователеями двух одинаковых докуметов отгрузки."(с)
Из этой фразы, лично я, делаю однозначный вывод: на остатках будут получаться произвольные числа. Пытаюсь, разобраться. Смотрю таблицу #3. Вызывает удивление. Спрашиваю. Получаю от Вас ответ:
"остатки просто спсываются произвольным образом (речь не идёт о партиях)"(с)
Пытаюсь дальше спрашивать. И получаю от Вас информацию:
"Остатки считываются, но не меняются "(с).
Но, тогда, зачем говорить о блокировках, если ничего не меняется.
Дык, может меняется? ;-)
А теперь ВНИМАТЕЛЬНО читаем (53) сообщение...
P.S.
Т.е. Ваша "статья" сводится к одной "мысли":
Если блокировки "мешают" системе работать быстро, то надо убрать ВСЕ лишние блокировки. И оставить только нужные.
Думаю, об этом многие люди догадываются... :-)
(54) hogik,
Да, только моя статья вкладывает больше смысла в понятие нужные.
С тем что технические детали понять достаточно сложно я согласен, попытался объяснить как мог; кто-то всё-таки понял, кто-то попытался разобраться и понял, кто-то попытался разобраться и не понял. Я тоже понял что мне есть над чем работать в плане ясности изложения мыслей.. :)
Т.е. Ваша "статья" сводится к одной "мысли":
Если блокировки "мешают" системе работать быстро, то надо убрать ВСЕ лишние блокировки. И оставить только нужные.
Если блокировки "мешают" системе работать быстро, то надо убрать ВСЕ лишние блокировки. И оставить только нужные.
Да, только моя статья вкладывает больше смысла в понятие нужные.
С тем что технические детали понять достаточно сложно я согласен, попытался объяснить как мог; кто-то всё-таки понял, кто-то попытался разобраться и понял, кто-то попытался разобраться и не понял. Я тоже понял что мне есть над чем работать в плане ясности изложения мыслей.. :)
(56)
"мне есть над чем работать в плане ясности изложения мыслей"(с)
Олег.
Не надо над этим работать. ;-) Вы совершенно ясно (и понятно) излагаете свои мысли. Лично меня, смущает само содержание этих мыслей (не отсутствие!!!). Например, нет такого выбора "оперативность или точность"(с). Думаю, допустим выбор: "оперативность или полнота"... А всё остальное и есть - "раздолбайство" и неуважение к покупателям, складским работникам, пользователям ИС, деньгам владельца и т.д.
Но это, сугубо, моё личное "восприятие" Ваших публикаций...
Всё! Спасибо за содержательную беседу и в этой теме.
Желаю успехов в ... ;-)
"мне есть над чем работать в плане ясности изложения мыслей"(с)
Олег.
Не надо над этим работать. ;-) Вы совершенно ясно (и понятно) излагаете свои мысли. Лично меня, смущает само содержание этих мыслей (не отсутствие!!!). Например, нет такого выбора "оперативность или точность"(с). Думаю, допустим выбор: "оперативность или полнота"... А всё остальное и есть - "раздолбайство" и неуважение к покупателям, складским работникам, пользователям ИС, деньгам владельца и т.д.
Но это, сугубо, моё личное "восприятие" Ваших публикаций...
Всё! Спасибо за содержательную беседу и в этой теме.
Желаю успехов в ... ;-)
(58) hogik,
По-моему заставлять пользователя по 5 раз проводить документ или ждать пару минут пока проведётся - "не уважение к пользователям, покупателям, складским работникам"
А покупка Oracle или ооочень крутого "железа" - "не уважение к деньгам владельца".
К сожалению, большинство ИТ-шников мыслит так же как вы - "ну меня учили, что транзакция и блокировка должна быть" - "в учебнике так написано". И не могут взглянуть на проблему со стороны бизнеса "а что мне дороже - блокировка, или последствия её отсутствия".
По-моему заставлять пользователя по 5 раз проводить документ или ждать пару минут пока проведётся - "не уважение к пользователям, покупателям, складским работникам"
А покупка Oracle или ооочень крутого "железа" - "не уважение к деньгам владельца".
К сожалению, большинство ИТ-шников мыслит так же как вы - "ну меня учили, что транзакция и блокировка должна быть" - "в учебнике так написано". И не могут взглянуть на проблему со стороны бизнеса "а что мне дороже - блокировка, или последствия её отсутствия".
(60)
Олег.
Я с Вами полностью согласен. Перечисленные Вами явления - абсолютное неуважение! А "ИТ-шников" совершенно верно учили, "что транзакция и блокировка должна быть"(с) Но, им, видимо, забыли сказать, что время ИХ выполнения должно быть соответствующее предметной области. И для этого "ИТ-шникам" надо РАБОТАТЬ, а не перекладывать "свои проблемы" на других людей... Но в "1С-ах" работать "ИТ-шникам" придется ООО-чень много, т.к. в архитектуре этих систем наличествует "конфликт" в подходе проектирования ИС "от документа" и "запросным ЯМД". Но это другая тема...;-) И, лично мне, она не интересна, "ввиду отсутствия присутствия" ;-) продуктов 1С-а в моей деятельности. Чего и Вам желаю... :-)
Олег.
Я с Вами полностью согласен. Перечисленные Вами явления - абсолютное неуважение! А "ИТ-шников" совершенно верно учили, "что транзакция и блокировка должна быть"(с) Но, им, видимо, забыли сказать, что время ИХ выполнения должно быть соответствующее предметной области. И для этого "ИТ-шникам" надо РАБОТАТЬ, а не перекладывать "свои проблемы" на других людей... Но в "1С-ах" работать "ИТ-шникам" придется ООО-чень много, т.к. в архитектуре этих систем наличествует "конфликт" в подходе проектирования ИС "от документа" и "запросным ЯМД". Но это другая тема...;-) И, лично мне, она не интересна, "ввиду отсутствия присутствия" ;-) продуктов 1С-а в моей деятельности. Чего и Вам желаю... :-)
(48) photiev, Я думаю её и не получится сделать... Блокировки должны быть привязаны к бизнес логике прикладного решения. Т.е. Если у вас производится контроль остатков и вам важно чтобы в "-" никто не при каких условиях списать не мог - блокировка должна быть. В типовых это обычно РН "товары на складах" и "Взаиморасчеты". Чтобы проверить правильность - просто точку останова посьавьте в одном сеансе в обработке проведения (где-нибудь в конце), а в другом попытайтесь списать то же самое... должно повиснуть на блокировке. Может конечно и получится для этого обработку сделать... но как у меня пока нет идей :(
Статья классная, но вот посылка
[quote]Если у вас в базе менеджер имеет право провести документ вне зависимости от того есть товар(деньги) на остатках или нет, зачем вам тогда блокировки?[/quote]
на мой взгляд нуждается в уточнении
Итак ситуация:
1. Товара на складе "стратегический запас", т.е. столько, что в минус они гарантированно НИКОГДА не уходят в минус.
2. Работают 2 пользователя с полными административными правами (например главбух и финдир)
По логике статьи, блокировки не нужны.
Однако, не стоит забывать, что учет может вестить по фифо/лифо и требуется распределение по партиями. И хотя общий запас товара многократно превышает расход, но остатки по отдельным партиям то могут быть маленькие. Отсутствие блокировки приведет к двойному списанию с одной и той же партии.
А вот если списание идет "по средней" то соглашусь с автором, что вполне реально подумать об отказе от блокировок.
[quote]Если у вас в базе менеджер имеет право провести документ вне зависимости от того есть товар(деньги) на остатках или нет, зачем вам тогда блокировки?[/quote]
на мой взгляд нуждается в уточнении
Итак ситуация:
1. Товара на складе "стратегический запас", т.е. столько, что в минус они гарантированно НИКОГДА не уходят в минус.
2. Работают 2 пользователя с полными административными правами (например главбух и финдир)
По логике статьи, блокировки не нужны.
Однако, не стоит забывать, что учет может вестить по фифо/лифо и требуется распределение по партиями. И хотя общий запас товара многократно превышает расход, но остатки по отдельным партиям то могут быть маленькие. Отсутствие блокировки приведет к двойному списанию с одной и той же партии.
А вот если списание идет "по средней" то соглашусь с автором, что вполне реально подумать об отказе от блокировок.
(52)
Я не говорю, что проблема возникает во всех ситуациях. Я говорю о том, что если нет контроля остатков это не значит что не нужны блокировки.
Относительно отдельного списания партий - да, если такая технология (партии отдельно списывать) применяется, то согласен, описанной мной проблемы нет. Но
1. Ее (раздельное списание) применяют не все, так как она решает проблему производительностив в ущерб качеству отчетов.
2. Касается только оперативного проведения.
3. Конфигурация может вообще не предусматривать отдельного регистра для партий (один регистр остатков и в нем реквизит партия или аналогичный). (Мы же не только типовые рассматриваем)
Я не говорю, что проблема возникает во всех ситуациях. Я говорю о том, что если нет контроля остатков это не значит что не нужны блокировки.
Относительно отдельного списания партий - да, если такая технология (партии отдельно списывать) применяется, то согласен, описанной мной проблемы нет. Но
1. Ее (раздельное списание) применяют не все, так как она решает проблему производительностив в ущерб качеству отчетов.
2. Касается только оперативного проведения.
3. Конфигурация может вообще не предусматривать отдельного регистра для партий (один регистр остатков и в нем реквизит партия или аналогичный). (Мы же не только типовые рассматриваем)
(53) nafa, Нуу в варианте если мы используем РН "товары на складах" с измерением "серия", при этом при оперативном проведении списываем партии, то по хорошему и остатки контролировать нужно бы в разрезе партий... А без блокировки, естественно возможны "минуса" по партиям.. кто же спорит... только вот с блокировкой, да ещё и партии списывать оперативно... это уже по ситуации в бизнесе зависит.. что нам важнее.. оперативность или точность.
(55)
Только не "серия", а "ДокументПоступления".
Разница простая.
"серия" - это то, что определяется свойствами товара конкретной серии (маркировка, дата производства, срок годности и т.п.). Она как раз в типовых имеется. При отгрузке товара в зависимости от технологии работы склада серия либо указывается в заказе и кладется соответствуюшая, либо не указывается, кладется любая, фиксируется в наборном листе, далее вводится в реализаци то что положили. В типовых это измерение как раз есть в остатках.
Данная серия определяется человеком а не компьютером и от блокировок не зависит. Контроль с блокировками нужен на этапе резервирования товара дабы не зарезервировать один и тот же товар дважды. Блокировки на этапе отпуска нужны в том случае, если товар выписывается без резервирования - т.е. сразу реализацию и товар кладовщик собирает по накладной.
"ДокументПоступления" - расчетное понятие для определения себестоимости товара, когда на складе есть товар со всеми одинаковыми характеристиками но разной себестоимостью. Тут остатки не столько контролировать надо, сколько просто правильно определять дабы не списать 2 раза с одного Документа поступления. В УТ вынесено в отдельный регистр.
comol пишет:
Нуу в варианте если мы используем РН "товары на складах" с измерением "серия", при этом при оперативном проведении списываем партии, то по хорошему и остатки контролировать нужно бы в разрезе партий...
Нуу в варианте если мы используем РН "товары на складах" с измерением "серия", при этом при оперативном проведении списываем партии, то по хорошему и остатки контролировать нужно бы в разрезе партий...
Только не "серия", а "ДокументПоступления".
Разница простая.
"серия" - это то, что определяется свойствами товара конкретной серии (маркировка, дата производства, срок годности и т.п.). Она как раз в типовых имеется. При отгрузке товара в зависимости от технологии работы склада серия либо указывается в заказе и кладется соответствуюшая, либо не указывается, кладется любая, фиксируется в наборном листе, далее вводится в реализаци то что положили. В типовых это измерение как раз есть в остатках.
Данная серия определяется человеком а не компьютером и от блокировок не зависит. Контроль с блокировками нужен на этапе резервирования товара дабы не зарезервировать один и тот же товар дважды. Блокировки на этапе отпуска нужны в том случае, если товар выписывается без резервирования - т.е. сразу реализацию и товар кладовщик собирает по накладной.
"ДокументПоступления" - расчетное понятие для определения себестоимости товара, когда на складе есть товар со всеми одинаковыми характеристиками но разной себестоимостью. Тут остатки не столько контролировать надо, сколько просто правильно определять дабы не списать 2 раза с одного Документа поступления. В УТ вынесено в отдельный регистр.
(57) nafa, Я написал "Серия" потому что это наиболее привычный метод организации партионного учет "с явным" указанием партий в типовых конфигурациях. Серии есть в каждом документе... есть кнопка "заполнить по сериям" и т.п. Обычно если решают вашу задачу в типовых - ими пользуются. А "документ поступления" в регистр - это уже существенная доработка... хотя и так люди делают :)
(62)
А где хваленная "масштабируемость" 1С-ов? Или она заключается только в возможности перенести систему на более мощное железо? :-) Вот пример. Разработчики "1С 7.7" рекомендуют переходить с DBF-ной версии на SQL-ную при количестве пользователей около 5 человек. По моему (печальному) опыту общения с 1С-ами - всё это решается и без перехода на SQL-ную версию. И без сверток БД (полный бред!!!). Но для этого пришлось ВСЁ переделать... :-( И система обслуживает 50-75 пользователей, 11 лет, на "сервере" по уровню мощности WS. Проблем и причин для смены системы - не имеется... :-)
А где хваленная "масштабируемость" 1С-ов? Или она заключается только в возможности перенести систему на более мощное железо? :-) Вот пример. Разработчики "1С 7.7" рекомендуют переходить с DBF-ной версии на SQL-ную при количестве пользователей около 5 человек. По моему (печальному) опыту общения с 1С-ами - всё это решается и без перехода на SQL-ную версию. И без сверток БД (полный бред!!!). Но для этого пришлось ВСЁ переделать... :-( И система обслуживает 50-75 пользователей, 11 лет, на "сервере" по уровню мощности WS. Проблем и причин для смены системы - не имеется... :-)
(63) hogik, Да с масштабируемостью то всё в порядке... свёртки это конечно жесть... как раз про них статью дописываю... удивительно как много людей до сих пор их делает.
Проблемы 1С с жуткой нестабильностью работы... неотлаженностью и неотработанностью некоторых механизмов, отчасти это диктуется ориентацией на россиийский бизнес (возможность работы задним числом, возможность работы без контроля остатков).
То что у вас нет 1с заметно, поэтому и просил не писать постов. Некоторые "фичи" или "баги" становятся понятными только после долгой практики с ними борьбы.
Проблемы 1С с жуткой нестабильностью работы... неотлаженностью и неотработанностью некоторых механизмов, отчасти это диктуется ориентацией на россиийский бизнес (возможность работы задним числом, возможность работы без контроля остатков).
То что у вас нет 1с заметно, поэтому и просил не писать постов. Некоторые "фичи" или "баги" становятся понятными только после долгой практики с ними борьбы.
(65)
Олег.
Я писал только об общих вопросах ИС. И подсовывал Вам примеры из 1С-ов... ;-)
Уверяю Вас всяких "фичей и багов" хватает в любых системах. Но, на мой взгляд дилетанта, надо стараться устранять причину, а не следствие ( )
P.S. Вы написали: "Ну хоть кто-то понял о чём я..."(с)
Уверяю Вас, что я с первой буквы Вашей публикации понял о ЧЕМ и ПОЧЕМУ Вы говорите. :-)
Но "понимать" и "соглашаться" - это разные явления. Не надо думать, что если собеседник понял, то сразу и согласился с позицией собеседник.
Олег.
Я писал только об общих вопросах ИС. И подсовывал Вам примеры из 1С-ов... ;-)
Уверяю Вас всяких "фичей и багов" хватает в любых системах. Но, на мой взгляд дилетанта, надо стараться устранять причину, а не следствие ( )
P.S. Вы написали: "Ну хоть кто-то понял о чём я..."(с)
Уверяю Вас, что я с первой буквы Вашей публикации понял о ЧЕМ и ПОЧЕМУ Вы говорите. :-)
Но "понимать" и "соглашаться" - это разные явления. Не надо думать, что если собеседник понял, то сразу и согласился с позицией собеседник.
(63)
А можно поподробнее про базу 7.7 на 75 рыл и без скуля?
hogik пишет:
По моему (печальному) опыту общения с 1С-ами - всё это решается и без перехода на SQL-ную версию. И без сверток БД (полный бред!!!). Но для этого пришлось ВСЁ переделать... :-( И система обслуживает 50-75 пользователей
По моему (печальному) опыту общения с 1С-ами - всё это решается и без перехода на SQL-ную версию. И без сверток БД (полный бред!!!). Но для этого пришлось ВСЁ переделать... :-( И система обслуживает 50-75 пользователей
А можно поподробнее про базу 7.7 на 75 рыл и без скуля?
(66)
"А можно поподробнее про базу 7.7 на 75 рыл и без скуля?"©
Можно. ;-) Всё очень просто.
Началось всё в 2000 году с моим появлением в фирме (оптовая и розничная торговля). Две территории. На одной самопальная система "до уровня" пробивки чеков на ККМ из этой системы. На другой - "1С 7.7" на три пользователя используется для распечатки выходных документов (как текстовый редактор). Поставлена задача - сделать единую ИС. Номенклатура, к тому моменту - 35000 наименований (частично пересекающаяся). Ну, и начал делать. ;-) Увы, на 1С... :-(
Сначала отказались от регистров, "монолитного" документа, понятия проведения документов, оси времени, точки актуальности, хранения итогов НА, монопольных регламентных работ и т.д. Т.е. от 1С осталась только заставка. :-)
Далее система стала расширяться по количеству пользователей. Решили проблему 1 гигабайта на системном уровне. Решили проблему 2 гигабайт на уровне схемы базы данных и методов работы с ней. Сделали собственную распределенную БД (на уровне объектов 1С) для выделения розничного зала на отдельные "сервера" и повышения отказоустойчивости (у нас режим работы 24х7). По мере увеличения участков АвтоМехАнизации появилась тенденция к увеличению количества "серверов". А т.к. в "центральном" сервере уже работало до 30 человек, и на DBF-ах сильно страдала надежность, то поменяли "движок" на клиент-серверную СУБД. Со второй попытки ;-)
Имеем интерфейс к БД 1С-а. Пишем "автономные" задачи на Си.
Ну, вроде, и все рассказал. Последние три года ничего крупного не делаю...
P.S. Попытался рассказать кратко. Именно, в аспекте "без скуля"(с) Т.к. других деталей - масса.
"А можно поподробнее про базу 7.7 на 75 рыл и без скуля?"©
Можно. ;-) Всё очень просто.
Началось всё в 2000 году с моим появлением в фирме (оптовая и розничная торговля). Две территории. На одной самопальная система "до уровня" пробивки чеков на ККМ из этой системы. На другой - "1С 7.7" на три пользователя используется для распечатки выходных документов (как текстовый редактор). Поставлена задача - сделать единую ИС. Номенклатура, к тому моменту - 35000 наименований (частично пересекающаяся). Ну, и начал делать. ;-) Увы, на 1С... :-(
Сначала отказались от регистров, "монолитного" документа, понятия проведения документов, оси времени, точки актуальности, хранения итогов НА, монопольных регламентных работ и т.д. Т.е. от 1С осталась только заставка. :-)
Далее система стала расширяться по количеству пользователей. Решили проблему 1 гигабайта на системном уровне. Решили проблему 2 гигабайт на уровне схемы базы данных и методов работы с ней. Сделали собственную распределенную БД (на уровне объектов 1С) для выделения розничного зала на отдельные "сервера" и повышения отказоустойчивости (у нас режим работы 24х7). По мере увеличения участков АвтоМехАнизации появилась тенденция к увеличению количества "серверов". А т.к. в "центральном" сервере уже работало до 30 человек, и на DBF-ах сильно страдала надежность, то поменяли "движок" на клиент-серверную СУБД. Со второй попытки ;-)
Имеем интерфейс к БД 1С-а. Пишем "автономные" задачи на Си.
Ну, вроде, и все рассказал. Последние три года ничего крупного не делаю...
P.S. Попытался рассказать кратко. Именно, в аспекте "без скуля"(с) Т.к. других деталей - масса.
(69)
"Напиши статью"(с)
А кому это может понадобится? Концептуально, нового мы ничего не сделали. Думаю, более полезным будет изучать КАК и ЧТО делается в ИХНИХ системах. Универсальные решения я "опубликовал" на данном ресурсе. Единственно, что можно было бы написать - это, примерно, о роли реляционных СУБД с запросным ЯМД в "наших" задачах. Т.к. этой темой занимаюсь очень давно. Но, я уже "проверил" интерес сообщества к этой теме, пару лет назад. Получилось угрюмо и печально. ;-) Да и написано на эту тему уже очень много и, гораздо лучше, чем я это сделаю.
"Напиши статью"(с)
А кому это может понадобится? Концептуально, нового мы ничего не сделали. Думаю, более полезным будет изучать КАК и ЧТО делается в ИХНИХ системах. Универсальные решения я "опубликовал" на данном ресурсе. Единственно, что можно было бы написать - это, примерно, о роли реляционных СУБД с запросным ЯМД в "наших" задачах. Т.к. этой темой занимаюсь очень давно. Но, я уже "проверил" интерес сообщества к этой теме, пару лет назад. Получилось угрюмо и печально. ;-) Да и написано на эту тему уже очень много и, гораздо лучше, чем я это сделаю.
(70) Ага. Получилось угрюмо и печально.
Вспоминаю заминусованную тему (-5 !) что-то вроде "как я не понимаю нарастающий итог".
Основная мысль которой - "можно не так".
Кто только не пытал Владимира "Скажи как ?!!".
Ответ был только один : "не так !".
Максимум что удалось вырвать кроме длиннющих размышлизмов :
это простенький код от Владимира (перебор в цикле строк таблицы "аля клиппер 87").
После чего стало всё понятно и скучно.
Вспоминаю заминусованную тему (-5 !) что-то вроде "как я не понимаю нарастающий итог".
Основная мысль которой - "можно не так".
Кто только не пытал Владимира "Скажи как ?!!".
Ответ был только один : "не так !".
Максимум что удалось вырвать кроме длиннющих размышлизмов :
это простенький код от Владимира (перебор в цикле строк таблицы "аля клиппер 87").
После чего стало всё понятно и скучно.
(71)
Игорь.
У Вас есть риск отравиться собственным ядом. ;-)
Неужели не очевидно, что проблема, обсуждаемая в данной теме, "порождается" применением запросов и построение системы "от документа" в реляционной модели?
Для примера, у меня "движение по т.н. регистрам" и проверка "отрицательности остатков" делается вызовом одной функции примерно такого вида: R=F(Измерение1,Измерение2...,Количество,ЕдИзм)
И она выдаёт значение R - информацию об "отрицательности".
Вызывается на каждую строку "документа"(в терминах 1С-а).
И не блокирует ничего, кроме ОДНОЙ строки (хозяйственной операции) только на момент её модификации. А не всего состава "документа", т.к. и документа (как многострочного агрегата) у меня в системе нету. Замечу, как и во многих ИХНИХ системах.
А что касается Вашей фразы "Максимум что удалось вырвать"(с) - замечу, что перед этим "простеньким кодом"(с), я долго пытался повернуть Ваши мозги в "нужном" (для содержательного разговора) направлении. И получал от Вас ответ, типа "Не соглашаюсь". И как можно в таком режиме разговаривать...
P.S. Но, я помню Ваше предложение решать поиск отсутствующих номеров документов запросом, а не циклом. Было очень интересно и смешно. ;-) И все остальное Вы предлагаете делать именно таким образом. Через з...
Игорь.
У Вас есть риск отравиться собственным ядом. ;-)
Неужели не очевидно, что проблема, обсуждаемая в данной теме, "порождается" применением запросов и построение системы "от документа" в реляционной модели?
Для примера, у меня "движение по т.н. регистрам" и проверка "отрицательности остатков" делается вызовом одной функции примерно такого вида: R=F(Измерение1,Измерение2...,Количество,ЕдИзм)
И она выдаёт значение R - информацию об "отрицательности".
Вызывается на каждую строку "документа"(в терминах 1С-а).
И не блокирует ничего, кроме ОДНОЙ строки (хозяйственной операции) только на момент её модификации. А не всего состава "документа", т.к. и документа (как многострочного агрегата) у меня в системе нету. Замечу, как и во многих ИХНИХ системах.
А что касается Вашей фразы "Максимум что удалось вырвать"(с) - замечу, что перед этим "простеньким кодом"(с), я долго пытался повернуть Ваши мозги в "нужном" (для содержательного разговора) направлении. И получал от Вас ответ, типа "Не соглашаюсь". И как можно в таком режиме разговаривать...
P.S. Но, я помню Ваше предложение решать поиск отсутствующих номеров документов запросом, а не циклом. Было очень интересно и смешно. ;-) И все остальное Вы предлагаете делать именно таким образом. Через з...
(72) hogik,
Если бы такое делалось в "ихних" системах... мы бы наверное ещё не шагнули дальше больших ЭВМ System 360 :)
Вызывается на каждую строку "документа"
"1С Специалист" вы бы не сдали :). Очень.. ммм... продуктивное решение, правильно, зачем заморачиваться с группой записей - можно по одной их обработать, ну чуть погоняем данные с клиента на сервер - не беда, сетевые интерфейсы быстрый, "и пусть весь мир подождёт".
Для примера, у меня "движение по т.н. регистрам" и проверка "отрицательности остатков" делается вызовом одной функции примерно такого вида: R=F(Измерение1,Измерение2...,Количество,ЕдИзм)
Если бы такое делалось в "ихних" системах... мы бы наверное ещё не шагнули дальше больших ЭВМ System 360 :)
(74)
Должен высказаться в защиту hogik, так как самому пришлось такое делать (резервирование по факту ввода строки в документ). Причина простая. Ситуация:
Менеджер разговаривает с клиентом по телефону, формирует заказ. Получает от клиента запрос на 100 ед товара, подтверждает, переходит к следующей позиции. Доходит до конца, начинает проводить документ и выясняется, что в это время кто-то другой провел еще заказ и товар зарезервирован другим, т.е. 100 ед нет, есть только 20. Согласитесь, что перед клиентом это выглядит очень некрасиво. Ничего не оставалось делать, как резервировать товар сразу по факту ввода строки в документ. (Можно конечно нажимать "провести" после ввода каждой новой строки, но это еще большая нагрузка на сервер так как потребует пересчета резервирования всех строк документа а не только последней).
comol пишет:
Цитата
Вызывается на каждую строку "документа"
"1С Специалист" вы бы не сдали :). Очень.. ммм... продуктивное решение, правильно, зачем заморачиваться с группой записей - можно по одной их обработать, ну чуть погоняем данные с клиента на сервер - не беда, сетевые интерфейсы быстрый, "и пусть весь мир подождёт".
Цитата
Вызывается на каждую строку "документа"
"1С Специалист" вы бы не сдали :). Очень.. ммм... продуктивное решение, правильно, зачем заморачиваться с группой записей - можно по одной их обработать, ну чуть погоняем данные с клиента на сервер - не беда, сетевые интерфейсы быстрый, "и пусть весь мир подождёт".
Должен высказаться в защиту hogik, так как самому пришлось такое делать (резервирование по факту ввода строки в документ). Причина простая. Ситуация:
Менеджер разговаривает с клиентом по телефону, формирует заказ. Получает от клиента запрос на 100 ед товара, подтверждает, переходит к следующей позиции. Доходит до конца, начинает проводить документ и выясняется, что в это время кто-то другой провел еще заказ и товар зарезервирован другим, т.е. 100 ед нет, есть только 20. Согласитесь, что перед клиентом это выглядит очень некрасиво. Ничего не оставалось делать, как резервировать товар сразу по факту ввода строки в документ. (Можно конечно нажимать "провести" после ввода каждой новой строки, но это еще большая нагрузка на сервер так как потребует пересчета резервирования всех строк документа а не только последней).
(74)
Олег.
1) "1С Специалист" вы бы не сдали :). "(с)
И не собираюсь. :-) Т.к. их представление об ИС (в части назначения СУБД) еще не "докатилось" до IBM/360. Они только-только начали понимать, что такое перфокарта.
2) В (75) сообщении всё написано. Добавлю, только к этому, что пример моей функции не использует запросов. И в нашей системе, сетевая передача информации не является узким местом. В случае использования "запросного" алгоритма при "проведении документа" по сети передаётся больше информации. Примите это на веру. Уж очень лениво заниматься арифметикой. Считали и проверяли это многократно. Есть алгоритмы, где использовать запросы эффективнее, там мы их и используем. А "ввод" данных в БД - это не тот случай...
Олег.
1) "1С Специалист" вы бы не сдали :). "(с)
И не собираюсь. :-) Т.к. их представление об ИС (в части назначения СУБД) еще не "докатилось" до IBM/360. Они только-только начали понимать, что такое перфокарта.
2) В (75) сообщении всё написано. Добавлю, только к этому, что пример моей функции не использует запросов. И в нашей системе, сетевая передача информации не является узким местом. В случае использования "запросного" алгоритма при "проведении документа" по сети передаётся больше информации. Примите это на веру. Уж очень лениво заниматься арифметикой. Считали и проверяли это многократно. Есть алгоритмы, где использовать запросы эффективнее, там мы их и используем. А "ввод" данных в БД - это не тот случай...
(68) hogik, Я конечно всякие, извиняюсь за выражение, извращенства, видел, но такого.... Собственно когда людям не чем заняться бывает и такие явления появляются... бывает на delphi что напишут, бывает сделают Web интерфейс к SQL-ю... на западе тоже такое было.... лет 50 назад :)
(78) hogik, Ну это вам в Oracle или Microsoft, ещё в SAP можно попробывать... Покажите им свою разработку - они вас примут разработчиком :). Разработка системы это когда 10 экстра профи месяц занимаются планированием архитектуры, потом к ним добавляется ещё описание интерфейсов и объектной структуы, потом кодирование ещё несколько десятков человек, потом документирование всего этого... Всё это сопровождается многомиллионными инвестициями, при этом даже близко приблизиться к 1С получится едва ли... не говоря уже о других системах...
(84) cool.vlad4, Я тоже когда-то делал свою систему на Delphi для учета в автомастерской и торговлей автозапчастями :)... эх... были времена... потом на Access... потом часть из них на 1С перевёл.. а часть не знаю... может так и работают :). Но конечно я этим не горжусь как многие... скорее наоборот...
(86)(87)
Олег.
Вы о чем?
Мы, вроде, обсуждаем Вашу идею выбора: "оперативность или точность"(с)
Возникают "смежные" вопросы - рассказываем свой опыт друг-другу, обсуждаем...
Еще раз, спрошу. Приведите, пожалуйста, таблицу последовательности выполнения операций с БД в случае обновления "актуальных итогов" при "проведении документа" с совокупными блокировками 1С+СУБД. Если там будет обеспечена "точность", то я соглашусь с Вашими предложениями из публикации. Ну, а если не будет обеспечена, то разбежимся - каждый со своим мнением на АвтоМехАнизацию. Идет?
Олег.
Вы о чем?
Мы, вроде, обсуждаем Вашу идею выбора: "оперативность или точность"(с)
Возникают "смежные" вопросы - рассказываем свой опыт друг-другу, обсуждаем...
Еще раз, спрошу. Приведите, пожалуйста, таблицу последовательности выполнения операций с БД в случае обновления "актуальных итогов" при "проведении документа" с совокупными блокировками 1С+СУБД. Если там будет обеспечена "точность", то я соглашусь с Вашими предложениями из публикации. Ну, а если не будет обеспечена, то разбежимся - каждый со своим мнением на АвтоМехАнизацию. Идет?
(90)
"...в контексте 1С, и чем данный подход отличается от традиционного."(с)
Во всех 1С-ах считается, что наименьшей единицей "взаимодействия" с ИС является документ. Для документов без табличной части - это похоже на правду. ;-) А для документов с табличной частью - это глобальная ошибка в проектировании системы. Т.к. "хозяйственной операцией" (ХО) является одна строка таких документов. Если в ИС ставится целью учитывать документы, то - этот подход оправдан. Если ставится задача АвтоМехАнизировать деятельность, непосредственно, участников ХО, то он совершает не ХО над документами, а ХО "размером" в одну строчку документа. На мой взгляд, в ИС следует "учитывать" (фиксировать) ХО, а не документы. Способы реализации такого подхода могут быть различными - как в выражении предметной области, так и в "программном" уровне.
Функция R=F(Измерение1,Измерение2...,Количество,ЕдИзм) выполняет фиксацию в БД одной ХО. И блокировка "накладывается" только на этот момент. Реализация функции зависти от модели СУБД. В моем случае:
Логическая блокировка "измерения".
Поиск по ключу и чтение итога (остатка).
Вычисление нового значения итога.
Проверка "отрицательности" (если требуется).
Запись нового значения "движения".
Обновление итоговой записи.
Снятие блокировки.
Т.е. всё очень примитивно с точки зрения общения с СУБД, в части блокировок. ;-)
Интересней логика "управляемых" блокировок в системе в целом.
Типа - иерархическая модель... :-)
"...в контексте 1С, и чем данный подход отличается от традиционного."(с)
Во всех 1С-ах считается, что наименьшей единицей "взаимодействия" с ИС является документ. Для документов без табличной части - это похоже на правду. ;-) А для документов с табличной частью - это глобальная ошибка в проектировании системы. Т.к. "хозяйственной операцией" (ХО) является одна строка таких документов. Если в ИС ставится целью учитывать документы, то - этот подход оправдан. Если ставится задача АвтоМехАнизировать деятельность, непосредственно, участников ХО, то он совершает не ХО над документами, а ХО "размером" в одну строчку документа. На мой взгляд, в ИС следует "учитывать" (фиксировать) ХО, а не документы. Способы реализации такого подхода могут быть различными - как в выражении предметной области, так и в "программном" уровне.
Функция R=F(Измерение1,Измерение2...,Количество,ЕдИзм) выполняет фиксацию в БД одной ХО. И блокировка "накладывается" только на этот момент. Реализация функции зависти от модели СУБД. В моем случае:
Логическая блокировка "измерения".
Поиск по ключу и чтение итога (остатка).
Вычисление нового значения итога.
Проверка "отрицательности" (если требуется).
Запись нового значения "движения".
Обновление итоговой записи.
Снятие блокировки.
Т.е. всё очень примитивно с точки зрения общения с СУБД, в части блокировок. ;-)
Интересней логика "управляемых" блокировок в системе в целом.
Типа - иерархическая модель... :-)
Автор:
Подписаться
Для получения уведомлений о новых публикациях автора подключите телеграм бот: Инфостарт бот
Публикация:
№ 91880
Создание 26.09.11 01:09
Обновление 26.09.11 18:09
Статистика:
Просмотры 66418
Загрузки 0
Рейтинг
175
Комментарии 163
Характеристики:
Код открыт Не указано
Рубрики Механизмы платформы 1С
Кому Программист
Тип файла Нет файла
Платформа Платформа 1С v8.3
Конфигурация Конфигурации 1cv8
Операционная система Не имеет значения
Страна Россия
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)
