Продвинутый курс. МГ от 03.01.2011
03.01.2011
комментария 22
Продолжаем отвечать на вопросы участников продвинутого курса.
1. Дублирование ярлыков.
Настройки все сделаны , 1SCStart.exe на сервере. Делаем его ярлык пользователю.
Запускает – устанавливается приложение и создает свой ярлык 1С.
Дальше уже правильность работы пользователя не гарантируется, она может запустить любой из 2-х ярлыков запуска 1С: который создался при установке с локальным путем и наш ярлык из сетевой папки.
Есть решение, кроме как создавать ярлык с картинкой и названием отличным от стандартных 1С?
2. Автоматическая установка.
В Главе 2 урок 3. Идет рассказ об автоматической установке платформы, и утверждается, что не требуются права локального администратора для обновления.
Попытка смоделировать автоматическую установку платформы на клиенте с WindowsXP для учетной записи с ограниченными правами по описанной методике провалилась с сообщением “Не обнаружена установленная версия 1С:Предприятия”.
Если же запуск производился от имени учетной записи с правами администратора, то все отработало как описано в видео.
Может есть какие то нюансы при настройке учетной записи с ограниченными правами?
3. Вопросы по ЖР.
Возможно но ли к существующему журналу добавить другой журнал, например, совместить два журнала с разных периодов?
Что делать если историю изменения смотреть хочется, но файлы на столько большие что получение из них информации тормозят систему в целом?
Если ли смысл хранить журнал по периодам? Будет ли быстрее доступ к данным/запись если выставить к примеру период равный день или месяц?
4. Регистрация события «Доступ».
В описании полей регистрации для описания использования доступа в журнале регистрации приведен текст: ”Тип: Массив. Поля, которые в случае участия их в результате выборки запроса, будут выведены в таблицу значений (поле Данные.Данные события журнала регистрации). Поля регистрации задаются массивом, элементом которого является либо строка – имя поля, либо массив строк – имен полей. Первый уровень массива определяет набор ключевых полей, которые будут зарегистрированы. Если элементом массива является массив строк, то в этом массиве описываются альтернативные ключевые поля. В случае возможности вывода нескольких альтернативных ключевых полей выводится поле с меньшим индексом.“
Можно ли расшифровать написанное?
Поскольку не совсем понятно следующее: ” …Если элементом массива является массив строк, то в этом массиве описываются альтернативные ключевые поля. В случае возможности вывода нескольких альтернативных ключевых полей выводится поле с меньшим индексом.”
5. Проведение документа.
В уроках говорится о том, что в документах при проведении нежелательно обращаться к напрямую к реквизиту документа.
Но при проведении, либо при открытии документа создается объект и следовательно считываются его реквизиты.
Получается в момент проведения мы уже имеем в кэше данные по объекту и обратившись к реквизиту вроде ничего не теряем.
Может я чего то недопонял?
Здравствуйте!
Не могу получить доступ к материалам. Пишет:
К сожалению, у Вас недостаточно прав для просмотра этой записи. Если Вы еще не залогинены на сайте — залогиньтесь. Если Вы оплачивали курс, у Вас активирован токен доступа, Вы залогинены, но Вы видите эту запись — напишите нам на e-mail поддержки.
MamZhan, здравствуйте!
Попробуйте еще раз.
Спасибо, Андрей!
Доступ получил.
MamZhan, пожалуйста!:)
По п.7
1. Запрос к базе при проведении документа – это хорошо. Вот только интересно, во всех ли случаях будут получаться одни и те же данные? Ведь при проведении транзакция еще не зафиксирована, хотя данные объекта уже записаны в базу. И получается, что запрос выполняет “грязное чтение” (Read Uncommited), чтение данных еще не зафиксированной транзакции. Нет ли режимов работы ИБ (автоматический/управляемый режим блокировок, …), которые привели бы к запрету такого чтения и, соответственно, к невозможности применения запросов к данным объекта при проведении?
.
2. Насколько я видел в типовых решениях на 8.1 проведение большинства документов построено на том, что сначала создается структура со значениями реквизитов документа, а затем уже она используется в общих модулях при проведении. Это пример “неэффективного” кода или вообще никак не связано с рассматриваемым вопросом?
2 (продолжение). А может, причина такого кода кроется в ответе на п.1? Ведь не так уж и давно все типовые перешли с автоматического на управляемый режим блокировок…
>>Ведь не так уж и давно все типовые перешли с автоматического на управляемый режим блокировок
Последняя бухгалтерия 2.0 (2.0.18.1): я не нашел ни одного документа, использующего данный режим.
Последняя бухгалтерия КОРП: нашел только 2-а документа.
Надеюсь, когда будем проходить управляемые блокировки, ответы на данные “загадочные” действия разработчиков найдутся! :)
Сейчас нет под рукой типовых.
Однако действительно все типовые (от фирмы 1С) должны быть на управляемых блокировках. Из тем более БП Корп, само название обязывает :)
Посмотрите в свойствах конфигурации (корневого узла), что установлено для “Режима блокировки конфигурации”. Должно быть значение “Управляемый”.
Да, Евгений, Вы – правы. И Вы, Александр, тоже! На корневом узле стоит значение – управляемый. Я видать пока что очень “темный” в плане. Моему разуму почему-то казалось, что чтобы управляемому режиму блокировок заработать, на самом документе должен быть установлен данный признак.
Буду ждать соотв.раздела в нашем курсе. Для просветления ;)
Ок :)
1. Про управляемые блокировки отлично написан раздел 2 книги “1С:Предприятие от 8.0 к 8.1” (авторы: П.С.Белоусов, А.В.Островерх). Мне он очень помог при освоении этой темы. Но для “просветления” все равно стоит дождаться раздела Продвинутого курса :)
2. Режим блокировок у объектов принимается во внимание только тогда, когда у корневого узла установлен режим “Автоматический и управляемый”. Если установлен конкретный режим, то он и применяется, режим объектов не учитывается. Евгений, поправьте, если ошибаюсь.
3. Режим “Автоматический и управляемый” для корневого элемента нужен для постепенного перехода от автоматических блокировок к управляемым. Однажды я был очень удивлен, когда при очередном обновлении вся типовая конфигурация разом перешла на управляемые блокировки! При этом ни строчки кода для поддержки режима управляемых блокировок не появилось! В книге из п.1 я прочел, что блокировки автоматические “разруливаются” на уровне СУБД, а управляемые – на уровне сервера предприятия. Но я так и не понял, почему же не нужно писать код для собственно управления блокировками в управляемом режиме… Так что ждем “просветления”! ;)
> Если установлен конкретный режим, то он и применяется, режим объектов не учитывается.
Все верно.
>Но я так и не понял, почему же не нужно писать код для собственно управления блокировками в управляемом режиме
Код писать нужно. Видимо он был спрятан далеко в общий модуль :)
“Код писать нужно. Видимо он был спрятан далеко в общий модуль :)”
Евгений, я задавал вопрос на эту тему в базовом курсе. Но не совсем понял ответ :) Если в нашей учебной конфигурации установлен режим “управляемый”, но код мы НЕ пишем. В каком режиме работает платформа ? В автоматическом ?
Или управляемом ? Как работают блокировки, если кода нет ?
>В каком режиме работает платформа ?
В режиме управляемых блокировок.
Но он характерен только для клиент-серверного варианта использования платформы.
>Как работают блокировки, если кода нет ?
Блокировки не накладываются. Соответственно при работе нескольких пользователей есть большая вероятность возникновения коллизии.
Однако, в файловом варианте блокировки все равно накладываются автоматически на уровне таблиц.
Александр, спасибо за наводку на книжку! Она у меня есть, правда именно этот раздел я уже давным-давно забыл. Я в основном оттуда только про расширение языка запросов читал :)
Вот Вы, Александр, вы с не типовыми конфигурациями работаете? Видели ли вы, чтоб в какой-нибудь очередной нетленки, использовался режим управляемых блокировок? Насколько я понимаю, в типовых этот функционал появился сравнительно недавно?
>Насколько я понимаю, в типовых этот функционал появился сравнительно недавно?
Навскидку более 2х лет применяется БП, в УПП примерно 3 года.
1. Нужно учесть еще, что типовые конфигурации для России обычно опережают остальные по функционалу на полгода-год. То, что сказал Евгений – это для российских типовых. А, например, Бухгалтерия для Украины перешла на управляемые блокировки лишь летом 2010 года.
2. С нетиповыми конфигурациями встречаться приходится нечасто. Хотя, смотря что называть типовыми. Ведь типовая может быть сильно переработана, а есть еще отраслевые решения… Если речь идет о написанной с нуля “нетленке” – то было дело с использованием регистра сведений в управляемом режиме в одной конфигурации, автоматизировавшей учет презентационных дней компании и помещений. А что именно Вас интересует?
> И получается, что запрос выполняет «грязное чтение» (Read Uncommited), чтение данных еще не зафиксированной транзакции.
Кажется, что грязного чтения здесь быть не может.
Не могут другие транзакции изменить документ, который проводится в текущей транзакции.
Ведь проведение подразумевает запись объекта, которая вызывает блокировку на уровне СУБД. А обработка проведения выполняется после записи объекта.
Можете провести эксперименты, интересно посмотреть на результат :)
>2. Насколько я видел в типовых решениях на 8.1 проведение большинства документов построено на том
Рекомендация использования запроса была и для платформы 8.1. Однако давно не заглядывал в старые конфигурации, точно сказать не могу..
Я говорил о “грязном чтении” в части чтения новых данных, измененных в еще не зафиксированной транзакции. Ведь запись-проведение документа выполняются в единой транзакции. Получается, что при работе метода ОбработкаПроведения() новые данные документа уже записаны в ИБ, но транзакция еще не зафиксирована, ведь так? И в этом методе, выходит, мы читаем данные еще не зафиксированной транзакции…
>при работе метода ОбработкаПроведения() новые данные документа уже записаны в ИБ, но транзакция еще не зафиксирована
Да, совершенно верно.
Можно допустить следующую ситуацию:
0. Пользователь создает новый документ и проводит его.
1. В обработчике ПередЗаписью, были модифицированы данные документа №313. Например, заполнился реквизит СуммаДокумента.
Далее, произошла запись в БД, и начала работу ОбработкаПроведения().
2. В это время другой пользователь формирует отчет, который строится по данным документов (сумм документов). И в отчет могут попасть данные документа №313.
3. Далее в обработке проведения происходит контроль и Отказ устанавливается в Истину.
Получилось, что отчет содержит неактуальные данные.
Вы говорили о подобной ситуации?
Но в этом страшного нет ничего. С таким же успехом пользователь мог провести документ, сформировать отчет, отменить проведение документа. Данные в отчете были бы не актуальные.
А если пойти дальше и предположить, что сумма документа в отчете использовалась вместе с движениями документа? Тогда получится, что данные в отчете “кривые”, а не просто неактуальные: сумма документа уже новая, а данные движений еще старые… Вот это я и называю “грязное чтение” – чтение данных еще не завершившейся транзакции. И по-хорошему, СУБД не должна допускать операций Read Uncommited.
Вообще в книге “От 8.0 к 8.1” детально расписаны режимы работы блокировок каждой СУБД в зависимости от режима блокировок платформы. В частности, в книге я не встречал вообще варианта работы СУБД, когда может работать Read Uncommited… Поэтому и заинтересовало, почему запросом можно получать данные документа, транзакция записи которого еще не завершилась.
Может все дело в том, что данные документа, использующиеся в транзакции при его записи/проведении просто не блокируются, а потому доступны запросом внутри текущей транзакции или даже извне (как в описанном выше способе с отчетом)?
>сумма документа уже новая, а данные движений еще старые…
Такая ситуация возможна.
>Почему запросом можно получать данные документа, транзакция записи которого еще не завершилась.
СУБД выполняет блокировку чтения только в момент физической записи, это незначительное время.