По теме из базы знаний
- МиниКейс "Закрытие месяца в УПП без остановки работы системы (Партионный учёт)"
- Рабочее место программиста на Linux. Серия лабораторных работ. Работа 1
- Подборка полезных советов по работе с программой 1С:Бухгалтерия 3.0
- Скальпель, зажим, … пластырь, валерьянка. Мы закончили..: инструменты работы бизнес-аналитика
- Как искусственный интеллект помогает в работе с требованиями
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
Сергей.
Я еще забыл сказать - от чего еще надо отказаться.
От самого понятия провести/де-провести документ в реализации этого понятия 1С-овцами. ;-)
Если мне не изменяет память, при проведении документа сначала происходит удаление всего движения данного документа. Т.е. документ становиться всегда новым документом. Образно, говоря документ вытаскивается из нескольких "пачек" движений. Это хороший, универсальный алгоритм. На самом деле, думаю, надо сначала "сравнивать" старое движение с новым, "вычислить" разницу и в базе данных отражать только различия. Такое сравнение реально сделать универсальным, если ВСЕ документы привести к одинаковой простейшей форме в части хранения и обработки их движения. Выше по теме я привел эту простую форму для ТиС (в моём понимании). Допускаю, что в других задачах, для которых создана подсистема "Оперативный учет" это невозможно...
Сергей.
Я еще забыл сказать - от чего еще надо отказаться.
От самого понятия провести/де-провести документ в реализации этого понятия 1С-овцами. ;-)
Если мне не изменяет память, при проведении документа сначала происходит удаление всего движения данного документа. Т.е. документ становиться всегда новым документом. Образно, говоря документ вытаскивается из нескольких "пачек" движений. Это хороший, универсальный алгоритм. На самом деле, думаю, надо сначала "сравнивать" старое движение с новым, "вычислить" разницу и в базе данных отражать только различия. Такое сравнение реально сделать универсальным, если ВСЕ документы привести к одинаковой простейшей форме в части хранения и обработки их движения. Выше по теме я привел эту простую форму для ТиС (в моём понимании). Допускаю, что в других задачах, для которых создана подсистема "Оперативный учет" это невозможно...
при проведении документа сначала происходит удаление всего движения данного документа. Т.е. документ становиться всегда новым документом. Образно, говоря документ вытаскивается из нескольких "пачек" движений. Это хороший, универсальный алгоритм. На самом деле, думаю, надо сначала "сравнивать" старое движение с новым, "вычислить" разницу и в базе данных отражать только различия.
- а можно услышать более развернутые соображения по этому поводу???
мну, например, гложут сомнения в целесообразности таких вычислительных затрат...
ли моего "предложения" из (302) - "..."вычислить" разницу..."?
- вот это...
.
и еще: я так понял, что у вас документ = 1строчныйдокумент, то есть табличной части нет, все регистрируется в "шапке"? а сам документ при необходимости "визуализируется" отчетом/запросом...?
(305)
Сергей.
У нас совершенно нормальные документы - строки, шапки.
Документы выглядят и сделаны в "штатной концепции" 1С 7.7.
И никаких запросов ;-)
Основное отличие реализации - другая организация регистров, исходя из положений, сформулированных в (88).
Попробую пояснить (302) в терминах 1Са. Не судите строго последующий текст. Т.к. я уже ДЕВЯТЬ лет не "сталкиваюсь" с этими терминами.
Инструмент последовательностей документов позволяет отследить перемещение документов на оси времен по собственной дате документа. Взаимосвязь документов не отслеживается. Она только декларируется при описании последовательности документов. Перемещение документа по оси времени не всегда порождает противоречие в "жестких" связях документов. И именно это, как мне показалось, Вы хотите отследить. Т.е. инструмент последовательностей должен отслеживать не перемещение документов на оси времени по дате, а по содержанию его движения установившего "жесткую" связь документов. Это я и назвал в (302) "пачками" движений. Почему - "пачка". Можно представить, что регистры это укладывания документов (его частей) в "пачки". Т.е. документ одновременно должен находится в разных "пачках" (последовательностях).
Отследить все последовательность по содержанию до проведения документа, думаю, сложновато (накладно, долго и т.д) будет. А отследить (выяснить) состав изменяющихся реквизитов и их принадлежности (влияния) на "пачки" движений - проще. Т.е. сравнить старое состояние документа и новое. И уже на основании этой информации "накапливать" данные о необходимости пере-проводить те или иные документы. Но этот алгоритм, думаю, будет тоже сложным при написании его на "штатном" языке 1С. Точнее не на языке, а на "штатных" инструментах - регистры, последовательности, итоги и т.д. Т.е. такой алгоритм можно упростить по сути и скорости выполнения приведя работу (анализ) структуры ВСЕХ документов и составления под-схемы базы данных (документа) только из тех реквизитов, которые влияют на "жесткую" связь документов.
Так? Или не - так?
Я сумел ответить Вам на вопрос из (303-304) сообщений?
Сергей.
У нас совершенно нормальные документы - строки, шапки.
Документы выглядят и сделаны в "штатной концепции" 1С 7.7.
И никаких запросов ;-)
Основное отличие реализации - другая организация регистров, исходя из положений, сформулированных в (88).
Попробую пояснить (302) в терминах 1Са. Не судите строго последующий текст. Т.к. я уже ДЕВЯТЬ лет не "сталкиваюсь" с этими терминами.
Инструмент последовательностей документов позволяет отследить перемещение документов на оси времен по собственной дате документа. Взаимосвязь документов не отслеживается. Она только декларируется при описании последовательности документов. Перемещение документа по оси времени не всегда порождает противоречие в "жестких" связях документов. И именно это, как мне показалось, Вы хотите отследить. Т.е. инструмент последовательностей должен отслеживать не перемещение документов на оси времени по дате, а по содержанию его движения установившего "жесткую" связь документов. Это я и назвал в (302) "пачками" движений. Почему - "пачка". Можно представить, что регистры это укладывания документов (его частей) в "пачки". Т.е. документ одновременно должен находится в разных "пачках" (последовательностях).
Отследить все последовательность по содержанию до проведения документа, думаю, сложновато (накладно, долго и т.д) будет. А отследить (выяснить) состав изменяющихся реквизитов и их принадлежности (влияния) на "пачки" движений - проще. Т.е. сравнить старое состояние документа и новое. И уже на основании этой информации "накапливать" данные о необходимости пере-проводить те или иные документы. Но этот алгоритм, думаю, будет тоже сложным при написании его на "штатном" языке 1С. Точнее не на языке, а на "штатных" инструментах - регистры, последовательности, итоги и т.д. Т.е. такой алгоритм можно упростить по сути и скорости выполнения приведя работу (анализ) структуры ВСЕХ документов и составления под-схемы базы данных (документа) только из тех реквизитов, которые влияют на "жесткую" связь документов.
Так? Или не - так?
Я сумел ответить Вам на вопрос из (303-304) сообщений?
(307)
Сергей.
Я перечитал свои сообщения (302) (306) и понял, что я смешал два подхода - свое представление регистров и штатное. Думаю, у меня это получилось плохо. Посмотрите, пожалуйста, вот эту статью:
В ней суть, в части штатных регистров, изложена лучше чем у меня ;-)
Сергей.
Я перечитал свои сообщения (302) (306) и понял, что я смешал два подхода - свое представление регистров и штатное. Думаю, у меня это получилось плохо. Посмотрите, пожалуйста, вот эту статью:
В ней суть, в части штатных регистров, изложена лучше чем у меня ;-)
ОФФ.
Я извиняюсь перед автором темы и участниками дискуссии.
Сам поиск в обозначенном направлении любопытен , но ,на мой взгляд,
соображения высказанные в теме вызывают предельный скепсис.
Наиболее полно, опять же по-моему, методы решения проблемы "исправлений задним числом" только для 77 изложены в статье (308).
Мне кажется , что для "восьмерочных" конфигураций , имеющих
1. механизм последовательностей с измерениями,
2. фоновое перепроведение документов только по регистру партий
- всё вышепрочитаное малоактуально.
C Новым Годом !
Я извиняюсь перед автором темы и участниками дискуссии.
Сам поиск в обозначенном направлении любопытен , но ,на мой взгляд,
соображения высказанные в теме вызывают предельный скепсис.
Наиболее полно, опять же по-моему, методы решения проблемы "исправлений задним числом" только для 77 изложены в статье (308).
Мне кажется , что для "восьмерочных" конфигураций , имеющих
1. механизм последовательностей с измерениями,
2. фоновое перепроведение документов только по регистру партий
- всё вышепрочитаное малоактуально.
C Новым Годом !
(311) "проблема лишь завуалирована... "
1с в "восьмерочных" конфигурациях пошло по пути не отрицания , а развития механизма последовательностей и механизма переповедения.
Что для универсальных решений - совершенно логично.
Полагаю , что конфигурация , которую ты сейчас пишешь , гораздо разумнее реализовывать в "8" , а не в "7". ( Впрочем, даже превосходно написанная твоя конф-ия всё равно останется кустарной и уникальной, что , конечно, не есть хорошо)
Пример показывающий преимущества "8" перед "7" - процедура перепроведения документов по регистру партий в типовых конф-иях.
1. При перепроведении можно создавать движения документа только по одному регистру , не затрагивая движения по другим регистрам.
2. Перед началом перепроведения регистр партий на ДатуНачала выгружается в ТаблицуЗначений (кэшируется). При перепроведении кажого документа для получения тек.остатков обращение происходит не к регистру ,а созданной ТЗ.
3. В оперативной работе можно вообще отказаться от оперативного проведения по регистру партий , а проведение по регистру партий производить в фоновом режиме в удобное время.
1с в "восьмерочных" конфигурациях пошло по пути не отрицания , а развития механизма последовательностей и механизма переповедения.
Что для универсальных решений - совершенно логично.
Полагаю , что конфигурация , которую ты сейчас пишешь , гораздо разумнее реализовывать в "8" , а не в "7". ( Впрочем, даже превосходно написанная твоя конф-ия всё равно останется кустарной и уникальной, что , конечно, не есть хорошо)
Пример показывающий преимущества "8" перед "7" - процедура перепроведения документов по регистру партий в типовых конф-иях.
1. При перепроведении можно создавать движения документа только по одному регистру , не затрагивая движения по другим регистрам.
2. Перед началом перепроведения регистр партий на ДатуНачала выгружается в ТаблицуЗначений (кэшируется). При перепроведении кажого документа для получения тек.остатков обращение происходит не к регистру ,а созданной ТЗ.
3. В оперативной работе можно вообще отказаться от оперативного проведения по регистру партий , а проведение по регистру партий производить в фоновом режиме в удобное время.
2. Перед началом перепроведения регистр партий на ДатуНачала выгружается в ТаблицуЗначений (кэшируется). При перепроведении кажого документа для получения тек.остатков обращение происходит не к регистру ,а созданной ТЗ.
Нет, не так. Таблица товаров передается в таблицу движений регистра сведений СписанныеТовары, записывается, потом считываются остатки из регистра партий - в запросе внутр.соединение этих регистров, затем из запроса выборка строит дерево и передается через структуру параметров в проведение по партиям.
При перепроведении тоже сравнивается строка документа с записью этого регистра сведений СписанныеТовары, чтобы определить необходимость замещения записи регистра партий.
(314) Лариса, только для Вас .
(или прости меня , Фиксин )
В новом релизе конфигурации "Управление производственным предприятием 1.2" фирмы 1С применяется кэширование движений по партиям:
"В данной конфигурации реализована новая модель проведения документов по партионному учету (реализовано частично, только для документов "Поступление товаров и услуг" и "Реализация товаров и услуг"). Основное ее отличие от ранее существовавшей - это отказ от многократного получения остатков партий из регистра накопления на каждый проводимый документ. Теперь однажды полученный остаток сохраняется в таблице значений, и в последующем берется уже из таблицы значений.
(или прости меня , Фиксин )
В новом релизе конфигурации "Управление производственным предприятием 1.2" фирмы 1С применяется кэширование движений по партиям:
"В данной конфигурации реализована новая модель проведения документов по партионному учету (реализовано частично, только для документов "Поступление товаров и услуг" и "Реализация товаров и услуг"). Основное ее отличие от ранее существовавшей - это отказ от многократного получения остатков партий из регистра накопления на каждый проводимый документ. Теперь однажды полученный остаток сохраняется в таблице значений, и в последующем берется уже из таблицы значений.
Собственно схема напоминает списание по партиям в торговле 77 с ее справочником партий.
Регистр сведений имеет периодичность "по позиции регистратора" в целях сдвига последовательности на документ.
И соответственно:
никак не верно. А УПП посмотрю, но сомневаюсь что то в выводах Фиксина.
Регистр сведений имеет периодичность "по позиции регистратора" в целях сдвига последовательности на документ.
И соответственно:
Пример показывающий преимущества "8" перед "7" - процедура перепроведения документов по регистру партий в типовых конф-иях.
никак не верно. А УПП посмотрю, но сомневаюсь что то в выводах Фиксина.
(319) Чувствую.
Поэтому долбежки по постам (302),(304) не планируется .
Лишь плавный переход в конструктивное русло от "отрицания" последовательностей к осмыслению их развития в типовых конфигурациях.
на "8"
Действительно , прежде чем мечтать о жизни без последовательностей в "7" нужно разобраться с тем "что есть" , "куда движется", "как развивается". Только уже в "8".
Этот этап как правило многие пропускают. Вот я и захотел остановиться на скучном для изобретателей анализе : какие методы и способы применяются для борьбы "с задним числом" в настоящий момент.
Поэтому долбежки по постам (302),(304) не планируется .
Лишь плавный переход в конструктивное русло от "отрицания" последовательностей к осмыслению их развития в типовых конфигурациях.
на "8"
Действительно , прежде чем мечтать о жизни без последовательностей в "7" нужно разобраться с тем "что есть" , "куда движется", "как развивается". Только уже в "8".
Этот этап как правило многие пропускают. Вот я и захотел остановиться на скучном для изобретателей анализе : какие методы и способы применяются для борьбы "с задним числом" в настоящий момент.
(318) Не понял, поясню. Прежде чем приводить примеры из типовых, надо бы их изучить не по статьям Фиксина, а самостоятельно читая код.
Так что, не верно твое утверждение о проведении по партиям в типовых 8.
(320)
Я как раз об этом.
И об этом:
Так что, не верно твое утверждение о проведении по партиям в типовых 8.
(320)
Этот этап как правило многие пропускают.
Я как раз об этом.
И об этом:
Вот я и захотел остановиться на скучном для изобретателей анализе
(315) (318) Посмотрела списание по партиям в УПП.
Если речь шла о восстановлении последовательностей обработкой ПроведениеПоПартиям в неоперативном режиме, то из нее вызывается процедура ВыполнитьВосстановлениеНаСервере(), далее ВыполнитьВосстановление в общем модуле УправлениеЗапасами, которая, в свою очередь, вызывает процедуру УправлениеЗапасамиПартионныйУчет.ДвижениеПартийТоваров (...
и далее примерно по описанной мной схеме в УТ, использует структуру параметров, в которую передаются запросы и т.д.
Ссылка на статью Фиксина - полный бред, написана еще в 2006 году, видимо еще в 8.0, процедуры, им описанной, в УПП 1.2.24.2 - нет, искать ее где-то в старье, желания нет, так что, говорить о:
тоже бред.
Перед тем, как ссылаться на подобную информацию, неплохо бы проверить ее на актуальность и соответствие действительности, а потом уж писать черным специально для меня. :)
Игорь, ничего личного, но справедливость требует... ;)
Если речь шла о восстановлении последовательностей обработкой ПроведениеПоПартиям в неоперативном режиме, то из нее вызывается процедура ВыполнитьВосстановлениеНаСервере(), далее ВыполнитьВосстановление в общем модуле УправлениеЗапасами, которая, в свою очередь, вызывает процедуру УправлениеЗапасамиПартионныйУчет.ДвижениеПартийТоваров (...
и далее примерно по описанной мной схеме в УТ, использует структуру параметров, в которую передаются запросы и т.д.
Ссылка на статью Фиксина - полный бред, написана еще в 2006 году, видимо еще в 8.0, процедуры, им описанной, в УПП 1.2.24.2 - нет, искать ее где-то в старье, желания нет, так что, говорить о:
Теперь однажды полученный остаток сохраняется в таблице значений, и в последующем берется уже из таблицы значений.
тоже бред.
Перед тем, как ссылаться на подобную информацию, неплохо бы проверить ее на актуальность и соответствие действительности, а потом уж писать черным специально для меня. :)
Игорь, ничего личного, но справедливость требует... ;)
И еще добавлю, процедура ДвижениеПартийТоваров используется во всех доках, связанных с товарами и при оперативном проведнии тоже, и, конечно, используется регистр сведений СписанныеТовары.
В УПП, УТП и УТ схема примерно одна.
В БП есть процедура с таким же названием, строится примерно также - передаются в структуру параметров запросы, но уже к РегистрБухгалтерии.Хозрасчетный.Остатки и там не используется регистр СписанныеТовары и нет последовательности по докам, как в УТ и пр.
В УПП, УТП и УТ схема примерно одна.
В БП есть процедура с таким же названием, строится примерно также - передаются в структуру параметров запросы, но уже к РегистрБухгалтерии.Хозрасчетный.Остатки и там не используется регистр СписанныеТовары и нет последовательности по докам, как в УТ и пр.
(324) Я так понял.
1. Подтвердить или опровергнуть правильность приведенной Фиксиным цитаты из описания конфигурации УПП 1.2 Вы НЕ МОЖЕТЕ.
2. В настоящих актуальных конфигурациях , как Вы утверждаете , кэширование регистра партий , при котором остатки берутся не из регистра, а из таблицы значений , Не применяется , а потому есть полный бред.
Придется проверять.
Лариса , доложу по исполнении.
1. Подтвердить или опровергнуть правильность приведенной Фиксиным цитаты из описания конфигурации УПП 1.2 Вы НЕ МОЖЕТЕ.
2. В настоящих актуальных конфигурациях , как Вы утверждаете , кэширование регистра партий , при котором остатки берутся не из регистра, а из таблицы значений , Не применяется , а потому есть полный бред.
Придется проверять.
Лариса , доложу по исполнении.
в 8-ке, наскольо я себе представляю из=за присутсвия в теме - ничего нового не сделали. "вписали" в типовые конфиги кучу решений, опробованных и обкатанных на куче семерочных решений: и перепроведение по обдному регистру, и кеширование в ТЗ и прочее всякое...
"с точки зрения прикладных решений - подвижки не очень существенные... "
Даже если ты меня разыгрываешь, отвечу серьезно.
Если рассмотреть историю развития СУБД то появление 77 , оправданное с точки зрения развития бизнеса фирмы 1с - есть прикол, отражающий уровень тогдашних разработчиков 1с.
Переход от 77 к 8 - есть не развитие , а возвращение на столбовую дорогу развития СУБД.
Только один пример.
В 77 запись в базу сопровождается блокировкой всей (!) базы.
В 8 пользователи могут писать параллельно , не мешая друг другу,
а) в разные таблицы (блокировка на уровне таблиц)
б) в одну таблицу в разные записи (блокировка на уровне записей).
Это существенная подвижка или нет ?
Если 7-8 менеджеров на крупной оптовой фирме, использующей 77 , одновременно оформляют большие накладные клиентам , то они и остальные 20-30 пользователей , несвязанных с торговлей, прекрасно знают , что такое блокировка и какие бывают тормоза.
Знаешь это и ты.
Почему ты пишешь , что не видишь существенных подвижек ?
Даже если ты меня разыгрываешь, отвечу серьезно.
Если рассмотреть историю развития СУБД то появление 77 , оправданное с точки зрения развития бизнеса фирмы 1с - есть прикол, отражающий уровень тогдашних разработчиков 1с.
Переход от 77 к 8 - есть не развитие , а возвращение на столбовую дорогу развития СУБД.
Только один пример.
В 77 запись в базу сопровождается блокировкой всей (!) базы.
В 8 пользователи могут писать параллельно , не мешая друг другу,
а) в разные таблицы (блокировка на уровне таблиц)
б) в одну таблицу в разные записи (блокировка на уровне записей).
Это существенная подвижка или нет ?
Если 7-8 менеджеров на крупной оптовой фирме, использующей 77 , одновременно оформляют большие накладные клиентам , то они и остальные 20-30 пользователей , несвязанных с торговлей, прекрасно знают , что такое блокировка и какие бывают тормоза.
Знаешь это и ты.
Почему ты пишешь , что не видишь существенных подвижек ?
> В 77 запись в базу сопровождается блокировкой всей (!) базы.
- точно??? а то я очень сомневаюсь...
в 7-ке я тоже могу писать в разные таблицы. и даже в одну таблицу, в разные записи...
- или я не прав?
.
это - несущественная подвижка. может для __СУБД__ - и подвижка. Для юзеров - нет, им подвижки в СУБД - пофиг... До сих пор нет модульной структуры требуемого для "меня" учета... (или есть?)
.
> Если 7-8 менеджеров на крупной оптовой фирме, использующей 77 , одновременно оформляют большие накладные клиентам , то они и остальные 20-30 пользователей
- это недостатки конкретного прикладного решения и неверная техническая организация учетной схемы/технологии... Плата за универсальность решения и низкий порог вхождения.
.
на тех же 8-ках типовые решения тянут до 50-юзеров, дальше - те же самые проблемы с блокировками...
- точно??? а то я очень сомневаюсь...
в 7-ке я тоже могу писать в разные таблицы. и даже в одну таблицу, в разные записи...
- или я не прав?
.
это - несущественная подвижка. может для __СУБД__ - и подвижка. Для юзеров - нет, им подвижки в СУБД - пофиг... До сих пор нет модульной структуры требуемого для "меня" учета... (или есть?)
.
> Если 7-8 менеджеров на крупной оптовой фирме, использующей 77 , одновременно оформляют большие накладные клиентам , то они и остальные 20-30 пользователей
- это недостатки конкретного прикладного решения и неверная техническая организация учетной схемы/технологии... Плата за универсальность решения и низкий порог вхождения.
.
на тех же 8-ках типовые решения тянут до 50-юзеров, дальше - те же самые проблемы с блокировками...
Давай разбираться.
Рискну возразить.
В 7-ке если ты проводишь документ только по по одному регистру , то в этот момент по другому регистру запись невозможна, невозможно даже записать новый элемент какого-нибудь справочника.
Блокировка всей базы.
Не случайно в 77 даже нет понятия такого "управление блокировками". А незачем ! Пока одна транзация не закончится , другая не начнется.
В 2003 г. , насколько помню, было так .
Если меня доказательно поправят - буду рад.
Возможность параллельной работы пользователей - Это несущественная подвижка ?
Это прежде всего ограничение платформы 1сv77 .
Невозможность одновременной записи в разные таблицы (то бишь параллельной работы пользователей)- не устранить никакими хитростями прикладного решения.
Платформа 8 создает возможности для устранения проблемы блокировок , но это не означает автоматического их решения. Конкретные прикладные задачи в разной степени успешно решают проблему блокировок.
Давай обнажим "естество и плоть" проблемы и проведем эксперимент.
В 7-ке SQL создадим справочник с 100 000 эл., сод . реквизит Параметр(число).
Напишем простую обработку :
заполнение для назначенного диапазона элементов реквизита Параметр значением 200(допустим).
Пусть 10 человек одновременно запустят 1с Предприятие 77 SQL и нашу обработку.
Пусть каждый пользователь выберет свой диапазон кодов , так чтобы
1 пользователь установил диапазон кодов 1-10 000
2 пользователь установил диапазон кодов 10 001-20 000 и т.д.
По твоему хлопку все десять пользователей нажимают "ОК" в форме твоей обработки. (Каждый пользователь заполняет свой диапазон кодов для реквизита Парметр значением 200)
Потом то же самое повторить в 8-ке SQL.
Возможно, после эксперимента многие вопросы будут сняты.
в 7-ке я тоже могу писать в разные таблицы. и даже в одну таблицу, в разные записи...
- или я не прав?
- или я не прав?
Рискну возразить.
В 7-ке если ты проводишь документ только по по одному регистру , то в этот момент по другому регистру запись невозможна, невозможно даже записать новый элемент какого-нибудь справочника.
Блокировка всей базы.
Не случайно в 77 даже нет понятия такого "управление блокировками". А незачем ! Пока одна транзация не закончится , другая не начнется.
В 2003 г. , насколько помню, было так .
Если меня доказательно поправят - буду рад.
Возможность параллельной работы пользователей - Это несущественная подвижка ?
- это недостатки конкретного прикладного решения и неверная техническая организация учетной схемы/технологии... Плата за универсальность решения и низкий порог вхождения.
Это прежде всего ограничение платформы 1сv77 .
Невозможность одновременной записи в разные таблицы (то бишь параллельной работы пользователей)- не устранить никакими хитростями прикладного решения.
Платформа 8 создает возможности для устранения проблемы блокировок , но это не означает автоматического их решения. Конкретные прикладные задачи в разной степени успешно решают проблему блокировок.
Давай обнажим "естество и плоть" проблемы и проведем эксперимент.
В 7-ке SQL создадим справочник с 100 000 эл., сод . реквизит Параметр(число).
Напишем простую обработку :
заполнение для назначенного диапазона элементов реквизита Параметр значением 200(допустим).
Пусть 10 человек одновременно запустят 1с Предприятие 77 SQL и нашу обработку.
Пусть каждый пользователь выберет свой диапазон кодов , так чтобы
1 пользователь установил диапазон кодов 1-10 000
2 пользователь установил диапазон кодов 10 001-20 000 и т.д.
По твоему хлопку все десять пользователей нажимают "ОК" в форме твоей обработки. (Каждый пользователь заполняет свой диапазон кодов для реквизита Парметр значением 200)
Потом то же самое повторить в 8-ке SQL.
Возможно, после эксперимента многие вопросы будут сняты.
(343)
"или я не прав?"
Для DBFной версии "1С 7.7" примерно так:
1) Чтение/запись любой записи таблицы в транзакции блокирует всю таблицу по записи до завершения транзакции.
2) Все операции записи данных (для одиночных записей) в БД выполняются в транзакции, даже если не делается явный вызов НачатьТранзакцию().
3) Если делается явный вызов НачатьТранзакцию(), то обращение к первой таблице внутри транзакции используется для синхронизации транзакций путем её блокирования и предоставления имени для сообщения пользователю об ожидании начала транзакции.
4) При проведении документа делается неявный вызов функции НачатьТранзакцию() в методе Провести(). Далее вступает в силу алгоритм из пункта #3, а первая таблица - 1SJOURN.
"или я не прав?"
Для DBFной версии "1С 7.7" примерно так:
1) Чтение/запись любой записи таблицы в транзакции блокирует всю таблицу по записи до завершения транзакции.
2) Все операции записи данных (для одиночных записей) в БД выполняются в транзакции, даже если не делается явный вызов НачатьТранзакцию().
3) Если делается явный вызов НачатьТранзакцию(), то обращение к первой таблице внутри транзакции используется для синхронизации транзакций путем её блокирования и предоставления имени для сообщения пользователю об ожидании начала транзакции.
4) При проведении документа делается неявный вызов функции НачатьТранзакцию() в методе Провести(). Далее вступает в силу алгоритм из пункта #3, а первая таблица - 1SJOURN.
(346) Владимир. Не путайте нас.
Скажите лучше. Верно ли утверждение :
В 77 любая запись в базу сопровождантся блокировкой всех таблиц базы ? ( во время проведения документа по регистрам невозможно записать изменения в любой справочник базы)
Или во время проведения одного документа невозможно просто сохранить любой другой документ
Скажите лучше. Верно ли утверждение :
В 77 любая запись в базу сопровождантся блокировкой всех таблиц базы ? ( во время проведения документа по регистрам невозможно записать изменения в любой справочник базы)
Или во время проведения одного документа невозможно просто сохранить любой другой документ
(347)
Я с регистрами не работаю. Но общий алгоритм блокировок описан в (345). Вся база никогда не блокируется. Но если в модуле проведения документа (читай - транзакции) производится чтение/запись справочника, то запись в данный справочник у другого пользователя закончится аварийно (см. пункт #1 сообщения #345).
В момент проведения документа невозможно сохранить другой документ у другого пользователя (см. пункт #2 сообщения #345). Т.к. существуют общие таблицы для этих действий.
Я с Вами согласен. В "1С 7.7" вопросы СУБД (в частности - блокировки) сделаны очень плохо и не гибко. И я не хотел Вас путать в этом вопросе. Т.к. после подмены родного движка для "1С 7.7" многие проблемы успешно решаются. Хотя это и не типовое решение... ;-)
Я с регистрами не работаю. Но общий алгоритм блокировок описан в (345). Вся база никогда не блокируется. Но если в модуле проведения документа (читай - транзакции) производится чтение/запись справочника, то запись в данный справочник у другого пользователя закончится аварийно (см. пункт #1 сообщения #345).
В момент проведения документа невозможно сохранить другой документ у другого пользователя (см. пункт #2 сообщения #345). Т.к. существуют общие таблицы для этих действий.
Я с Вами согласен. В "1С 7.7" вопросы СУБД (в частности - блокировки) сделаны очень плохо и не гибко. И я не хотел Вас путать в этом вопросе. Т.к. после подмены родного движка для "1С 7.7" многие проблемы успешно решаются. Хотя это и не типовое решение... ;-)
(347)
Игорь.
Но возвращаясь к теме "без последовательностей" в части блокировок ;-), думаю, имеет смысл поговорить о времени (длительности) блокировки. Да хоть и всей базы! Если обновление данных происходит быстро, то способ (метод, алгоритм и т.д.) блокировки не имеет значение. А обновление данных будет выполняться быстро, если в момент, например, проведения документа не будут выполняться лишние действия. А к таким лишним действиям я отношу всё, что обозначено в названии данной темы... ;-)
Игорь.
Но возвращаясь к теме "без последовательностей" в части блокировок ;-), думаю, имеет смысл поговорить о времени (длительности) блокировки. Да хоть и всей базы! Если обновление данных происходит быстро, то способ (метод, алгоритм и т.д.) блокировки не имеет значение. А обновление данных будет выполняться быстро, если в момент, например, проведения документа не будут выполняться лишние действия. А к таким лишним действиям я отношу всё, что обозначено в названии данной темы... ;-)
(348) Ага . Как обычно , договариваю за Вас :
1. Утверждение:
Неверно.
Блокируются только те таблицы, к записям которых происходит обращение внутри транзакции. Т.е. если к таблице справочника не происходит обращение внутри транзакции , то элемент этого справочника может быть успешно создан и записан.
2. Утверждение
Верно. Т.к. блокируется таблица 1SJOURN
Так ?
1. Утверждение:
В 77 любая запись в базу сопровождантся блокировкой всех таблиц базы
Неверно.
Блокируются только те таблицы, к записям которых происходит обращение внутри транзакции. Т.е. если к таблице справочника не происходит обращение внутри транзакции , то элемент этого справочника может быть успешно создан и записан.
2. Утверждение
Или во время проведения одного документа невозможно просто сохранить любой другой документ
Верно. Т.к. блокируется таблица 1SJOURN
Так ?
(349)
"Если обновление данных происходит быстро, то способ (метод, алгоритм и т.д.) блокировки не имеет значение."
Спорно и неточно. Лучше так :
"При небольшом количестве пользователей и простых алгоритмах обновления - блокировки чаще всего не имеют значения."
Тогда согласен. Но такая ситуация меня мало волнует. Что тут обсуждать ?
Меня волнует ситуация когда 100 пользователей одновременно пишут в базу размером 100 Гб. В этом случае Ваша цитата повисает.
Каждого из нас интересует что-то своё.
"Если обновление данных происходит быстро, то способ (метод, алгоритм и т.д.) блокировки не имеет значение."
Спорно и неточно. Лучше так :
"При небольшом количестве пользователей и простых алгоритмах обновления - блокировки чаще всего не имеют значения."
Тогда согласен. Но такая ситуация меня мало волнует. Что тут обсуждать ?
Меня волнует ситуация когда 100 пользователей одновременно пишут в базу размером 100 Гб. В этом случае Ваша цитата повисает.
Каждого из нас интересует что-то своё.
(351)
Согласен, что каждого из нас интересует что-то своё. И измеряем производительность системы все мы разным способом. Мне, например, не понятно как влияет на производительность системы размер базы данных при одновременной записи данных 100 пользователями. Например, у нас средняя запись (проведение) документа происходит меньше, чем за одну секунду. Это время не зависит от "заднее/переднее" число. В системе работает около 50 человек. База очень маленькая - 9 лет работы торговой компании с номенклатурой около 50000 наименований. Это быстро или медленно? ;-)
Согласен, что каждого из нас интересует что-то своё. И измеряем производительность системы все мы разным способом. Мне, например, не понятно как влияет на производительность системы размер базы данных при одновременной записи данных 100 пользователями. Например, у нас средняя запись (проведение) документа происходит меньше, чем за одну секунду. Это время не зависит от "заднее/переднее" число. В системе работает около 50 человек. База очень маленькая - 9 лет работы торговой компании с номенклатурой около 50000 наименований. Это быстро или медленно? ;-)
(351) > Меня волнует ситуация когда 100 пользователей одновременно...
- ну так я склонен доверять знающим людям, которые говорят, что типовые на 8-ке тянут в среднем 50 пользователей. Дальше - проблемы с блокировками. Так что в 8-ке - теже самые проблемы что и в 7-ке.. только для их решения требуется больше затрат.
.
вдогонку: ну и как обсуждали - в модуле проведения блокировка соотв.таблиц производится после первого обращения к ним...
.
вдогонку: у меня работает 9 складских терминалов, которые достаточно активно пишут данные в один и тот же справочник, но только - добавление новых записей - и никто никому не мешает, в базе активно работает с 10 пользователей - тормоза только при проведении больших документов - ибо тупо написал алгоритм (дописка к типовой УТ), сейчас также тупо "соптимизировал" алгоритм - прогноз: проблемы с транзакциями вообще нивелируются... да, база небольшая, DBFная, все это крутится на единственном "недосервере" (типа старого пня 2.4 с 2ГБ РАМ) и все работают в терминале...
.
и все это я к чему?: универсальные решения хороши до определенного порога/условий - дальше хорошо строить немного по-другому... и в8-ке (лично мне) хотелось бы видеть не попытки решения проблем универсальных решений (по типу фонового проведения по партиям, гибких блокировок - это тоже хорошо!) - а некий конструктор, позволяющий собирать из НУЖНЫХ мне КУБИКОВ свое специализированное решение... - вот это было бы в духе 1Ски... но, видимо, это требует достаточно выской квалификации разработчиков прикладных решений...
- ну так я склонен доверять знающим людям, которые говорят, что типовые на 8-ке тянут в среднем 50 пользователей. Дальше - проблемы с блокировками. Так что в 8-ке - теже самые проблемы что и в 7-ке.. только для их решения требуется больше затрат.
.
вдогонку: ну и как обсуждали - в модуле проведения блокировка соотв.таблиц производится после первого обращения к ним...
.
вдогонку: у меня работает 9 складских терминалов, которые достаточно активно пишут данные в один и тот же справочник, но только - добавление новых записей - и никто никому не мешает, в базе активно работает с 10 пользователей - тормоза только при проведении больших документов - ибо тупо написал алгоритм (дописка к типовой УТ), сейчас также тупо "соптимизировал" алгоритм - прогноз: проблемы с транзакциями вообще нивелируются... да, база небольшая, DBFная, все это крутится на единственном "недосервере" (типа старого пня 2.4 с 2ГБ РАМ) и все работают в терминале...
.
и все это я к чему?: универсальные решения хороши до определенного порога/условий - дальше хорошо строить немного по-другому... и в8-ке (лично мне) хотелось бы видеть не попытки решения проблем универсальных решений (по типу фонового проведения по партиям, гибких блокировок - это тоже хорошо!) - а некий конструктор, позволяющий собирать из НУЖНЫХ мне КУБИКОВ свое специализированное решение... - вот это было бы в духе 1Ски... но, видимо, это требует достаточно выской квалификации разработчиков прикладных решений...
"ну так я склонен доверять знающим людям, которые говорят, что типовые на 8-ке тянут в среднем 50 пользователей. Дальше - проблемы с блокировками. Так что в 8-ке - теже самые проблемы что и в 7-ке.. только для их решения требуется больше затрат. "
Знающих людей много и говорят они разное.
Фраза "на 8-ке тянут в среднем 50 пользователей" стала штампом .
Мне кажется, здесь иммется ввиду прежде всего недостаточная производительность платформы.
Но лучше всё-таки уточнить какие конфигурации имеются ввиду.
"Так что в 8-ке - теже самые проблемы что и в 7-ке.. " - Принципиальную неверность этой фразы я старался доказать в предыдущих постах . Если в 8 -ке удачное прикладное решение может частично снять проблему блокировок, то в 77 ограничение заложено на уровне платформы.
А вот и ты и сам потвердил :
"вдогонку: у меня работает 9 складских терминалов, которые достаточно активно пишут данные в один и тот же справочник, но только - добавление новых записей - и никто никому не мешает, в базе активно работает с 10 пользователей - тормоза только при проведении больших документов " (УТ - это ведь "8").
В 77 десять человек не смогли бы писать одновременно в один справочник. Значит выбор 8-ки в этом случае - разумное решение.
... и высочайшего уровня разработчиков платформы 8.
Знающих людей много и говорят они разное.
Фраза "на 8-ке тянут в среднем 50 пользователей" стала штампом .
Мне кажется, здесь иммется ввиду прежде всего недостаточная производительность платформы.
Но лучше всё-таки уточнить какие конфигурации имеются ввиду.
"Так что в 8-ке - теже самые проблемы что и в 7-ке.. " - Принципиальную неверность этой фразы я старался доказать в предыдущих постах . Если в 8 -ке удачное прикладное решение может частично снять проблему блокировок, то в 77 ограничение заложено на уровне платформы.
А вот и ты и сам потвердил :
"вдогонку: у меня работает 9 складских терминалов, которые достаточно активно пишут данные в один и тот же справочник, но только - добавление новых записей - и никто никому не мешает, в базе активно работает с 10 пользователей - тормоза только при проведении больших документов " (УТ - это ведь "8").
В 77 десять человек не смогли бы писать одновременно в один справочник. Значит выбор 8-ки в этом случае - разумное решение.
но, видимо, это требует достаточно выской квалификации разработчиков прикладных решений
... и высочайшего уровня разработчиков платформы 8.
В сторону.
Ты, я гляжу, сторонник уникальных решений. Почти фикси.
Но ,с точки зрения предприятия, луше не зависеть от конкретного исполнителя и применять по максимуму типовые конфигурации .
И если применять нетиповые решения ,то по очень веским основаниям и по определенным правилам, предупрждая упр.персонал о последствиях.
Больше всего я боюсь умников, пишущих уникальные программы.
Предпочтение отдаю простым и туповатым решениям. Так надежнее.
В Москве легче с квалифицированными кадрами - в провинции тяжелее.
И что делать после ухода такого умника - непонятно.
Ты, я гляжу, сторонник уникальных решений. Почти фикси.
Но ,с точки зрения предприятия, луше не зависеть от конкретного исполнителя и применять по максимуму типовые конфигурации .
И если применять нетиповые решения ,то по очень веским основаниям и по определенным правилам, предупрждая упр.персонал о последствиях.
Больше всего я боюсь умников, пишущих уникальные программы.
Предпочтение отдаю простым и туповатым решениям. Так надежнее.
В Москве легче с квалифицированными кадрами - в провинции тяжелее.
И что делать после ухода такого умника - непонятно.
(355)
"В 77 десять человек не смогли бы писать одновременно в один справочник."
- Ошибаетесь. ;-)
Не десять человек не смогут писать одновременно, а ДВА человека (задачи) не смогут.
Мало того, не только писать не смогут, но и читать одновременно не смогут. И это во всех СУБДах! В том числе и в используемых в 8-ке.
"Значит выбор 8-ки в этом случае - разумное решение"
- Выбор 8-ки, действительно, разумное решение. Но не в этом случае и не из-за "проблемы" с блокировками. Думаю у Сергея "работает 9 складских терминалов" не из-за низкой производительности "1С 7.7", а из-за того, что больше терминалов не требуется... ;-)
(356)
В сторону.
А слово "умник" уже стало ругательным? ;-)
Думаю в контору на работу берут "фикси" именно для реализации "уникальных" решений. И отсутствие в штате "фикси" не означает отсутствие потребности в "уникальных" решениях. Эти задачи и потребность в их решении существует всегда и везде. А попытки решать "уникальные" задачи универсальными средствами приводит к бОльшим затратам и плохим результатам для пользователя (заказчика). Хотя в силу "простоты и туповатости" таких решений они легче "подхватываются" другим разработчиком (программистом). Но продолжают оставаться "универсальным" и не решающими задач (потребностей) заказчика...
"В 77 десять человек не смогли бы писать одновременно в один справочник."
- Ошибаетесь. ;-)
Не десять человек не смогут писать одновременно, а ДВА человека (задачи) не смогут.
Мало того, не только писать не смогут, но и читать одновременно не смогут. И это во всех СУБДах! В том числе и в используемых в 8-ке.
"Значит выбор 8-ки в этом случае - разумное решение"
- Выбор 8-ки, действительно, разумное решение. Но не в этом случае и не из-за "проблемы" с блокировками. Думаю у Сергея "работает 9 складских терминалов" не из-за низкой производительности "1С 7.7", а из-за того, что больше терминалов не требуется... ;-)
(356)
В сторону.
А слово "умник" уже стало ругательным? ;-)
Думаю в контору на работу берут "фикси" именно для реализации "уникальных" решений. И отсутствие в штате "фикси" не означает отсутствие потребности в "уникальных" решениях. Эти задачи и потребность в их решении существует всегда и везде. А попытки решать "уникальные" задачи универсальными средствами приводит к бОльшим затратам и плохим результатам для пользователя (заказчика). Хотя в силу "простоты и туповатости" таких решений они легче "подхватываются" другим разработчиком (программистом). Но продолжают оставаться "универсальным" и не решающими задач (потребностей) заказчика...
1.(355)
Можно начать беседу совсем уж издалека.
И раскрыть вопрос : почему при модификации таблицы содержащей объектные данные (каждая запись - объект со своей уникальной ссылкой) возможно одновременное изменение(чтение) нескольких записей разными пользователями и почему при этом отсутствуют тормозящие(мешающме друг другу) блокировки ?
Но зачем нам с Вами очередное тягучее выяснение простого вопроса ?
Лучше провести уже описанный эксперимент "по хлопку" для 8-ки и Вам всё станет ясно.
2. (356) Слово "умник" было употреблено без кавычек. Да я их боюсь.
С тех пор как наш общий отец заявил : "Программирование - это не искусство , а технология " - взгляд на умников-программистов должен измениться.
Но истина всегда конкретна . Поэтому самоцитата :
"И если применять нетиповые решения ,то по очень веским основаниям и по определенным правилам, предупрждая упр.персонал о последствиях. "
Можно начать беседу совсем уж издалека.
И раскрыть вопрос : почему при модификации таблицы содержащей объектные данные (каждая запись - объект со своей уникальной ссылкой) возможно одновременное изменение(чтение) нескольких записей разными пользователями и почему при этом отсутствуют тормозящие(мешающме друг другу) блокировки ?
Но зачем нам с Вами очередное тягучее выяснение простого вопроса ?
Лучше провести уже описанный эксперимент "по хлопку" для 8-ки и Вам всё станет ясно.
2. (356) Слово "умник" было употреблено без кавычек. Да я их боюсь.
С тех пор как наш общий отец заявил : "Программирование - это не искусство , а технология " - взгляд на умников-программистов должен измениться.
Но истина всегда конкретна . Поэтому самоцитата :
"И если применять нетиповые решения ,то по очень веским основаниям и по определенным правилам, предупрждая упр.персонал о последствиях. "
(358)
1) "начать беседу совсем уж издалека"
Мы не можем начать такую беседу, т.к. у нас с Вами разные точки начала "издалека".
Ваше "издалека" это - "таблицы содержащей объектные данные". А моё "издалека" это технологические блокировки при обращении к индексному множеству. Эти блокировки делаются для всего индексного множества, а не отдельных записей. Они делаются и при чтении и при модификации отдельной записи таблиц в любой СУБД. Т.е. при внешнем видение работы и блокировки отдельной записи происходит блокировка всей таблицы. И в этом смысле Ваше "по хлопку" будет выполняться в 7.7 и 8.х одинаково. Т.е. в момент записи будет блокироваться вся таблица, а после записи - сниматься блокировка со все таблицы. И для выяснения этого не надо проводить никаких экспериментов - это очевидно и так.
Другое дело - это как долго будет выполняться сам процесс записи. Т.е. сколько времени таблица будет находится в заблокированном состоянии одной задачей и мешать другой задаче выполнить аналогичную запись. Но это время больше зависит от самой СУБД и железа, а не версии 1Са.
Еще имеет смысл учитывать наличие ошибки в "1С 7.7" в последовательности выполнения методов Новый() и Записать() для справочников с "Автоматическая нумерация". Т.к. в этой последовательности методов выполняется еще и обращение к таблице уникальности кодов, то возникает банальный клинч при одновременном создании нового элемента справочника в разных сеансах. Поэтом создается впечатление, что одна сессия ждет выполнения чего-то "бОльшого" из-за другой сессии. Типа, заблокирована вся таблица. Надеюсь, что в "1С 8.х" нет таких ошибок с клинчем. Они уже научились программировать СУБДшные задачи ;-)
2) "наш общий отец"
У нас с Вами разные отцы. ;-)
Да и по возрасту ОНО мне в отцы не годится.
А по времени начала программирования, скорее, ОНО мне в сыновья годится.
1) "начать беседу совсем уж издалека"
Мы не можем начать такую беседу, т.к. у нас с Вами разные точки начала "издалека".
Ваше "издалека" это - "таблицы содержащей объектные данные". А моё "издалека" это технологические блокировки при обращении к индексному множеству. Эти блокировки делаются для всего индексного множества, а не отдельных записей. Они делаются и при чтении и при модификации отдельной записи таблиц в любой СУБД. Т.е. при внешнем видение работы и блокировки отдельной записи происходит блокировка всей таблицы. И в этом смысле Ваше "по хлопку" будет выполняться в 7.7 и 8.х одинаково. Т.е. в момент записи будет блокироваться вся таблица, а после записи - сниматься блокировка со все таблицы. И для выяснения этого не надо проводить никаких экспериментов - это очевидно и так.
Другое дело - это как долго будет выполняться сам процесс записи. Т.е. сколько времени таблица будет находится в заблокированном состоянии одной задачей и мешать другой задаче выполнить аналогичную запись. Но это время больше зависит от самой СУБД и железа, а не версии 1Са.
Еще имеет смысл учитывать наличие ошибки в "1С 7.7" в последовательности выполнения методов Новый() и Записать() для справочников с "Автоматическая нумерация". Т.к. в этой последовательности методов выполняется еще и обращение к таблице уникальности кодов, то возникает банальный клинч при одновременном создании нового элемента справочника в разных сеансах. Поэтом создается впечатление, что одна сессия ждет выполнения чего-то "бОльшого" из-за другой сессии. Типа, заблокирована вся таблица. Надеюсь, что в "1С 8.х" нет таких ошибок с клинчем. Они уже научились программировать СУБДшные задачи ;-)
2) "наш общий отец"
У нас с Вами разные отцы. ;-)
Да и по возрасту ОНО мне в отцы не годится.
А по времени начала программирования, скорее, ОНО мне в сыновья годится.
при внешнем видение работы и блокировки отдельной записи происходит блокировка всей таблицы. И в этом смысле Ваше "по хлопку" будет выполняться в 7.7 и 8.х одинаково.
Попросите какого - нибудь авторитета для Вас провести эксперимент "по хлопку" на 7-ке SQL и 8-ке SQL , описанный (344).
Ну , хотя бы из любопытства .
Тем и хорош эксперимент , что всё расставляет по местам.
(360)
Игорь.
А какого результата (поведения) Вы ожидаете от проведения эксперимента из (344) сообщения? Что в 8-ке это будет быстрей? Что в 7-ке задачи будут выполняться последовательно? Еще раз повторю. Для предложенной проверки никакой разницы не будет, кроме прикола с клинчем в 7-ке. Да и клинча может не быть, если реализовать Ваше предложение буквально - каждая сессия пишет свой диапазон кодов, т.е. обновлять справочник без "Автоматическая нумерация". Это не показательный тест для демонстрации преимущества алгоритмов блокировки в 8-ке.
Да и не стоит вопроса сравнения этих версий 1С-ов. Очевидно, что 8-ка по всем средствам программирования лучше чем 7-ка. Включая и алгоритмы блокировки.
А тема обсуждения - другая. См. сообщения (319) и (334).
P.S. Про "общего отца" без смайликов ничего не понимаю. У нас с Вами и фамилии разные... ;-)
Игорь.
А какого результата (поведения) Вы ожидаете от проведения эксперимента из (344) сообщения? Что в 8-ке это будет быстрей? Что в 7-ке задачи будут выполняться последовательно? Еще раз повторю. Для предложенной проверки никакой разницы не будет, кроме прикола с клинчем в 7-ке. Да и клинча может не быть, если реализовать Ваше предложение буквально - каждая сессия пишет свой диапазон кодов, т.е. обновлять справочник без "Автоматическая нумерация". Это не показательный тест для демонстрации преимущества алгоритмов блокировки в 8-ке.
Да и не стоит вопроса сравнения этих версий 1С-ов. Очевидно, что 8-ка по всем средствам программирования лучше чем 7-ка. Включая и алгоритмы блокировки.
А тема обсуждения - другая. См. сообщения (319) и (334).
P.S. Про "общего отца" без смайликов ничего не понимаю. У нас с Вами и фамилии разные... ;-)
(362) Не-а. На второй круг не пойдем. Выяснять вопросы :
1. Что такое блокировка , какие виды блокировок бывают.
2. Что такое объектные данные и что такое необъектные данные.
- мы не будем. Чебур обидится за флуд.
Проведите эксперимент и сделайте выводы самостоятельно.
(На всякий случай. См. еще раз (344)
Коды в эксперименте не изменяются).
Про "общего отца" понимать не нужно. Это шутка (смайлик).
1. Что такое блокировка , какие виды блокировок бывают.
2. Что такое объектные данные и что такое необъектные данные.
- мы не будем. Чебур обидится за флуд.
Проведите эксперимент и сделайте выводы самостоятельно.
(На всякий случай. См. еще раз (344)
Коды в эксперименте не изменяются).
Про "общего отца" понимать не нужно. Это шутка (смайлик).
(360)
Рискну возразить. База блокируется НЕ ВСЯ. Блокируются только задейстованные в транзакции проведения таблицы. и совершенно спокойно можно писать в справочники. Могу даже поспорить на шоколадку и сделать "демоконфигу"... и даже можно проводить еще один такой же документ, хотя в предыдущем будет висеть предупреждение "ок"...
- совершенно спокойно можно писать в разные таблицы... параллельно... можно тоже поспорить на шоколадку... и на демо-конфигу, которая одной обработкой будет заполнять плоский справочник номенклатура, а вторая обработка - справочник.контрагенты.
.
и количество беспроблемно работающих терминалов определяется не тем "что их всего 9", а скоростью реакции системы на операцию с терминала. Потому что и при 2-х терминалах можно мешать друг другу.
.
тем и плохи универсальные решения - что они универсальные. поэтому в 7.7 я не могу в качестве регистратора события с терминала использовать документ, потому что сделано мудачно (но универсально!!!) - может проводиться большой документ реализации секунд 0-15, а за это время у меня на терминале контроллер может раз 10 жмакнуть - и хрен доком запишешь, потому что общий журнал стоит в транзакции... а в справочник (в качестве регистратора) несколько терминалов спокойно пишут - время реакции на СОЗДАНИЕ НОВОЙ ЗАПИСИ - маленькое...
Рискну возразить.
В 7-ке если ты проводишь документ только по по одному регистру , то в этот момент по другому регистру запись невозможна, невозможно даже записать новый элемент какого-нибудь справочника.
Блокировка всей базы.
В 7-ке если ты проводишь документ только по по одному регистру , то в этот момент по другому регистру запись невозможна, невозможно даже записать новый элемент какого-нибудь справочника.
Блокировка всей базы.
Рискну возразить. База блокируется НЕ ВСЯ. Блокируются только задейстованные в транзакции проведения таблицы. и совершенно спокойно можно писать в справочники. Могу даже поспорить на шоколадку и сделать "демоконфигу"... и даже можно проводить еще один такой же документ, хотя в предыдущем будет висеть предупреждение "ок"...
Это прежде всего ограничение платформы 1сv77 .
Невозможность одновременной записи в разные таблицы (то бишь параллельной работы пользователей)
Невозможность одновременной записи в разные таблицы (то бишь параллельной работы пользователей)
- совершенно спокойно можно писать в разные таблицы... параллельно... можно тоже поспорить на шоколадку... и на демо-конфигу, которая одной обработкой будет заполнять плоский справочник номенклатура, а вторая обработка - справочник.контрагенты.
.
и количество беспроблемно работающих терминалов определяется не тем "что их всего 9", а скоростью реакции системы на операцию с терминала. Потому что и при 2-х терминалах можно мешать друг другу.
.
тем и плохи универсальные решения - что они универсальные. поэтому в 7.7 я не могу в качестве регистратора события с терминала использовать документ, потому что сделано мудачно (но универсально!!!) - может проводиться большой документ реализации секунд 0-15, а за это время у меня на терминале контроллер может раз 10 жмакнуть - и хрен доком запишешь, потому что общий журнал стоит в транзакции... а в справочник (в качестве регистратора) несколько терминалов спокойно пишут - время реакции на СОЗДАНИЕ НОВОЙ ЗАПИСИ - маленькое...
И я, кстати, сторонник типовых решений. и стараюсь их использовать по максимум... Проблемы универсальных решений разные... и одна из них - производительность. Универсальное решение будет проигрывать частному по скорости - это стопудово... И там, где на первом плане - скорость - универсальные/типовые решения - нервно курят в сторонке.. Да, можно и универсальное решение превратить в "частное" путем неимоверного усложнения кода... что и видим в той же 8-ке.. универсальное 7-ое решение блокировки таблиц в 8-ке наконец дотелепало до гибких блокировок в типовых решениях, хотя в тех же частных решениях на 7-ке - гибкие блокировки тоже были...
(365) Владимир уже указал мне на эту ошибку см.(350) .
База в 77 блокируется не вся , а только те таблицы ,к котором осуществляется обращение внутри транзакции. Правда Модуль проведения расходной накладной затрагивает столько важнейших таблиц (КОнтрагенты, Номенклатура и т.д.) , что выигрыш невеликий.
Я же толкую сейчас о простом эксперименте . Можно ли писать одновременно в разные элементы справочника в 8-ке SQL ?
Другими словами , можно ли запустить транзакцию на модификацию реквизитов одного элемента справочника если не окончена другая транзакция на модификацию другого элемента справочника ?
В этом смысл эксперимента в (344).
В 8-ке SQL эксперимент (344) должен осуществиться без проблем :
т.к. в каждом сеансе осуществляется одновременная запись в непересекающиеся диапазоны кодов элементов справочников (идут параллельные транзакции).
Почему при записи в элемент справочника не происходит блокировки всей таблицы справочника - вопрос этот нужно начинать обсуждать издалека : что такое объектные данные(таблицы справочников) и что такое необъектные данные (таблицы регистров).
Пока при помощи (344) достаточно установить простой факт : так ли это ?
База в 77 блокируется не вся , а только те таблицы ,к котором осуществляется обращение внутри транзакции. Правда Модуль проведения расходной накладной затрагивает столько важнейших таблиц (КОнтрагенты, Номенклатура и т.д.) , что выигрыш невеликий.
Я же толкую сейчас о простом эксперименте . Можно ли писать одновременно в разные элементы справочника в 8-ке SQL ?
Другими словами , можно ли запустить транзакцию на модификацию реквизитов одного элемента справочника если не окончена другая транзакция на модификацию другого элемента справочника ?
В этом смысл эксперимента в (344).
В 8-ке SQL эксперимент (344) должен осуществиться без проблем :
т.к. в каждом сеансе осуществляется одновременная запись в непересекающиеся диапазоны кодов элементов справочников (идут параллельные транзакции).
Почему при записи в элемент справочника не происходит блокировки всей таблицы справочника - вопрос этот нужно начинать обсуждать издалека : что такое объектные данные(таблицы справочников) и что такое необъектные данные (таблицы регистров).
Пока при помощи (344) достаточно установить простой факт : так ли это ?
"хотя в тех же частных решениях на 7-ке - гибкие блокировки тоже были... "
Меня поправляли , к сожалению, часто по поводу суждений о 77.
Поэтому выражусь аккуратно : есть примеры ?
Сразу скажу, термин "гибкие блокировки" имеет смысл только при модификации таблиц , содержащих необъектные данные (регистры).
При модификации таблиц , сод. объектные данные (справочники) - никакая "гибкость" не нужна : блокируется только сама , модифицируемая запись )элемент справочника, в другие же записи может параллельно осуществляться запись.
Под "гибкостью" понимается такая блокировка , при которой блокируется не вся таблица регистра (вид блокировки "Таблица") , а только диапазон записей (вид блокировки "Запись"). Так вот , пока я жестоко сомневаюсь , что что-то подобное было в 77.
Меня поправляли , к сожалению, часто по поводу суждений о 77.
Поэтому выражусь аккуратно : есть примеры ?
Сразу скажу, термин "гибкие блокировки" имеет смысл только при модификации таблиц , содержащих необъектные данные (регистры).
При модификации таблиц , сод. объектные данные (справочники) - никакая "гибкость" не нужна : блокируется только сама , модифицируемая запись )элемент справочника, в другие же записи может параллельно осуществляться запись.
Под "гибкостью" понимается такая блокировка , при которой блокируется не вся таблица регистра (вид блокировки "Таблица") , а только диапазон записей (вид блокировки "Запись"). Так вот , пока я жестоко сомневаюсь , что что-то подобное было в 77.
(369) Прочитал . Скачать презентацию можно только , отправив запрос.
Текст по ссылке - это вообщем-то рекламный проспект.
Ни намека на метод решения.
Возникло с десяток вопросов , но вопросы эти не к тебе .
Судя по количеству клиентов, в 77 SQL действительно существовали решения c гибкими блокировками.
Текст по ссылке - это вообщем-то рекламный проспект.
Ни намека на метод решения.
Возникло с десяток вопросов , но вопросы эти не к тебе .
Судя по количеству клиентов, в 77 SQL действительно существовали решения c гибкими блокировками.
(370) решения дествительно есть, это не голословные заявления.. причем вроде есть три разных независимых реализации... у софтпоинтцев на семинаре был - интересно, по 8-ку они и говорили про "50" (понятно, что это оценка весьма приблизительная)... оснований не доверять им у меня нет...
(367)
"Другими словами , можно ли запустить транзакцию на модификацию реквизитов одного элемента справочника если не окончена другая транзакция на модификацию другого элемента справочника ? В этом смысл эксперимента в (344). "
Игорь.
Выше по теме есть ответ. Повторю его еще раз, кратко - нельзя.
Но замечу, что утверждение: "в каждом сеансе осуществляется одновременная запись в непересекающиеся диапазоны кодов элементов справочников (идут параллельные транзакции)." - ошибочно. Т.к. в любой СУБД запись в таблицу в текущей момент времени выполняется только для одного сеанса с обязательным использованием технологических блокировок ВСЕЙ таблицы. А исходя из этого Ваш эксперимент из (344) ничего не проясняет в части преимуществ алгоритмов блокировки и транзакций в 8-ке. Но и это уже написано выше по теме... :-(
"Другими словами , можно ли запустить транзакцию на модификацию реквизитов одного элемента справочника если не окончена другая транзакция на модификацию другого элемента справочника ? В этом смысл эксперимента в (344). "
Игорь.
Выше по теме есть ответ. Повторю его еще раз, кратко - нельзя.
Но замечу, что утверждение: "в каждом сеансе осуществляется одновременная запись в непересекающиеся диапазоны кодов элементов справочников (идут параллельные транзакции)." - ошибочно. Т.к. в любой СУБД запись в таблицу в текущей момент времени выполняется только для одного сеанса с обязательным использованием технологических блокировок ВСЕЙ таблицы. А исходя из этого Ваш эксперимент из (344) ничего не проясняет в части преимуществ алгоритмов блокировки и транзакций в 8-ке. Но и это уже написано выше по теме... :-(
(379)
Этот эксперимент я уже проводил лет 8 назад, когда целый месяц пытался доказать 1С-овцам наличие клинча в последовательности выполнения методов Новый(), Записать() при обновлении справочника в двух и более сессиях. У меня нет никаких вопросов (недопонимания) алгоритмов работы 7-ки с СУБД. Т.к. пришлось досконально изучить эти алгоритмы при изготовлении интерфейса для подмены родного движка 1Са на свой. В этой же разработке удалось реализовать инструмент гибких блокировок. Но эту версию я, даже, и не публиковал, т.к. нагружать проблемного программиста такими наворотами посчитал жестокостью...
Этот эксперимент я уже проводил лет 8 назад, когда целый месяц пытался доказать 1С-овцам наличие клинча в последовательности выполнения методов Новый(), Записать() при обновлении справочника в двух и более сессиях. У меня нет никаких вопросов (недопонимания) алгоритмов работы 7-ки с СУБД. Т.к. пришлось досконально изучить эти алгоритмы при изготовлении интерфейса для подмены родного движка 1Са на свой. В этой же разработке удалось реализовать инструмент гибких блокировок. Но эту версию я, даже, и не публиковал, т.к. нагружать проблемного программиста такими наворотами посчитал жестокостью...
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот