2. У справочников в 7.7 нет служебных таблиц отборов. А периодические реквизиты я пишу, и делаю это с правильными блокировками.
3 По поводу что именно блокируется при проведении спорить не буду. Глубоко не копал.
4 Большие базы, большие справочники: вылеты при записи на раз два.
Цитата:получаются перекресные объекты со всеми вытекающими
пользователь 1 создает обект A ему возвращается объект B
пользователь 2 создает обект B ему возвращается объект A
Такого не встречал. Может такое и возможно.
Могу только сказать, что при правильном использовании моего класса таке невозможно.
Почему?
Потому, что при записи нового элемента новый ID ему даю я самостоятельно. Делается это в таком порядке:
1 Открывается транзакция.
2 читается из базы MAX(ID) справочника с хинтом updlock.
3 Нашему новому элементу присваивается ID+1 (естественно с основанием 36)
4 Элемент записывается.
5 Транзакция закрывается.
Это все никаких чудес и бубнов.
Хинт updlock это и есть правильная блокировка (в данном случае).
А все пять пунктов вместе это: Правильное чтение и правильная запись для MS SQL 2000.
4 Цитата:Если снимишь блокировки со справочников
Я не убираю блокировки. Я даю управление блокировками.В самом начале я указал назначение класса:
Главное назначение - правильная запись и чтение.Что такое
Правильное чтение? Это, когда чтением данных мы управляем подсказками (хинтами).
- Допустим сейчас мы формируем оперативный отчет. Достоверность данных нас не интересует. Главное скорость получения.
Читаем с хинтом (nolock). Что-то прочитаем дважды, что-то ни разу, что-то прочитаем криво (наполовину одни данные на половину другие)
- все х#рня плюс минус пол минллиона нас не интересует.
(Для этой задачи класс не подходит для массового получения данных нужно использовать запросы.)
- Следующая история: в модуле проведения читаем реквизиты товара.
Считаю, что лучше читать с хинтом serializable - гарантирует, что в момент чтения данные не меняются. И большего не нужно.
Не нужно блокировать ни таблицу товаров до окончания транзакции, ни читаемую запись до окончания транзакции.
Если б наш учет нуждался в такой точности, то мы б уже на выходные летали в соседние галлактики.
- История 3: Программно ищем элемент справочника с кодом "0015" если не нашли - создаем.
И вот тут начинается интересное. Попросите 1с найти элемент по коду. Что она сделает?
Правильно - найдет его с хинтом nolock. Что нам гарантирует хинт nolock? - НИЧЕГО.
Например сейчас кто-то выполняет запись элемента именно с таким кодом.
Как вариант добрый 1с возвращет 0 (нет такого элемента). И такой ответ отнюдь не моя фантазия.
Мы, по простоте душевной, верим и создаем новый. Чудно если на Код стоит проверка уникальности
- тогда мы получим исключение, а если не стоит - получим дубликат.
Почему получим исключение в первом случае? Потому, что хитрый 1с знает как проверить уникальность кода при записи.
(А я, когда мне надо было давать свои уникальные номера справочникам не знал. И никак не мог понять почему же у меня столько дубликатов получается).
Как это ДОЛЖНО БЫЛО БЫТЬ (что класс и позволяет делать):Измененный метод НайтиПоКоду() имеет два дополнительных параметра. Синтаксис:
НайтиПоКоду(Код,ФлагПоиска,Хинт=0,ТолькоСсылку=0)
Хинт - способ чтения. Можно указать строкой, можно числом. Строка - все, что съест ms SQL; Число: наиболее полезные подсказки: 0 - nolock, 1 - readcommitted, 2 - serializable, 3 - updlock
ТолькоСсылку значения: 0 - прочитать все реквизиты (по умолчанию); 1 - только найти ссылку (ТекущийЭлемент())
спр = СоздатьОбъект("Справочник.УникальныйПоКоду.Б");
// Ищем ссылку с хинтом
2 (serializable) (гарантированно записанные и никем не изменяемые в момент чтения данные)
// ТолькоСсылку = 1 (допустим нам не нужны реквизиты. Нужна только ссылка на элемент)
Если спр.НайтиПоКоду("0015",0,
2,1) = 0 Тогда
// Если не нашли то его ДЕЙСТВИТЕЛЬНО НЕТ.
// Далее если хочется гарантированно правильных данных придется воспользоваться транзакцией
// Других вариантов не бывает
// Если Не нашли: открываем транзакцию и читаем с хинтом
3 (updlock) - чтение, дающее гарантию, что до завершения
// транзакции никто другой не сможет записать анналогичные данные. (Данные соответсвующие нашим условиям).
НачатьТранзакцию();
Если спр.НайтиПоКоду("0015",0,
3,1) = 0 Тогда
// Если и теперь не нашли, то со спокойной совестью пишем гарантия уникальности = 100%
спр.Новый();
спр.Код= "0015";
спр.Записать();
КонецЕсли;
ЗафиксироватьТранзакцию();
КонецЕсли;
Класс не снимает блокировки. Класс их ДОБАВЛЯЕТ.
Страницы: [1] 
Справочник плюс. Прямая запись и чтение в справочники 1С 7.7 (число прочтений - 28265 )
