В последнее время появилась проблема. Самостоятельно каждый день (иногда и не по разу) меняется дата запрета редактирования. При чем без всякой логики может ставить любую дату, но на будущий период. Пользователем не доступно менять эту константу. Даны права только одному пользователю. В журнале регистрации действия по изменению этой даты не фиксируются (значит пользователи этого не делают.) Несколько раз было замечено, что дата менялась даже при отсутствие каких-либо действий пользователей. Проблема эта возникла месяц назад. В последнее время еще было замечено, что акты сверки (типовые) формируются некорректно. При чем не всегда. Формирую по одному и тому же контрагенту несколько раз, акты могут формироваться несколько раз неверно и несколько верно. База dbf более 4 Гб. 1с 7.7. Бухгалтерия 4.5. Работает в базе примерно 15 пользователей с терминальным доступом. Кто-нибудь встречался с подобной ситуацией и что подскажите?
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) ЮлияМ, Разные данные при формировании одного и то же отчёта и размер базы подсказывают Вам чтоб пора переезжать на SQL или обрезать базу. Кроме того, есть недокументированные возможности по обходу некоторых (не всех) ограничений размера базы, но тут же на свой страх и риск.
Возможно, и самопроизвольное изменение константы - следствие этой же проблемы
Возможно, и самопроизвольное изменение константы - следствие этой же проблемы
(6) ЮлияМ, самопроизвольно ничего не делается! тут либо в базе сбой произошел вследствие какой - нибудь незапланированной(случайной) перезагрузки, либо... критическая ошибка и закрытие 1с у кого - то... пробуйте делать тестирование и исправление... если не поможет... пробуйте создать чистую базу такую же( с такой же версией конфигурации) и сделать выгрузку из рабочей базы и загрузку в эту чистую... в итоге у вас будет нормальная целая база с документами ... и вот на ней проверьте все ли верно...
я б так сделал
я б так сделал
(1)
Юля.
А может, посадить на ОбработкаОжидания() сравнение текущего значения константы с предыдущим запомненным в глобальной переменной. И писать в журнал факт изменения с дополнительной информацией о пользователе. Можно и экран сохранить в неком файле.
Т.е. выяснить точнее время изменения и "список" активных пользователей. А если поставить маленькое время опроса, то и "внешнюю обработку" на снимке экрана может удастся разглядеть.
Юля.
А может, посадить на ОбработкаОжидания() сравнение текущего значения константы с предыдущим запомненным в глобальной переменной. И писать в журнал факт изменения с дополнительной информацией о пользователе. Можно и экран сохранить в неком файле.
Т.е. выяснить точнее время изменения и "список" активных пользователей. А если поставить маленькое время опроса, то и "внешнюю обработку" на снимке экрана может удастся разглядеть.
(87) hogik,
Я не совсем поняла мысль, что это может дать? Одновременно работает в базе около 10-16 пользователей. И дата правиться только на будущий период... На месяца два, или три, или четыре. При чем нет никакой логики. Например сегодня 17.07.2013, а дата менялась на 09.09.13, 10.08.2013 и на 18.10.2013..Было замечено один раз в журнале регистрации, что никто не работал (только один пользователь зашел и вышел), а дата поменялась.
Я не совсем поняла мысль, что это может дать? Одновременно работает в базе около 10-16 пользователей. И дата правиться только на будущий период... На месяца два, или три, или четыре. При чем нет никакой логики. Например сегодня 17.07.2013, а дата менялась на 09.09.13, 10.08.2013 и на 18.10.2013..Было замечено один раз в журнале регистрации, что никто не работал (только один пользователь зашел и вышел), а дата поменялась.
(88)
"...что это может дать?"(с)
Юля.
1) Это даст запись в журнал факта изменения константы. Далее надо будет анализировать журнал. Т.е. искать КТО и ЧТО делал после изменения константы. А еще и добавить в "ловушку" рекомендации из (66) сообщения. Но, это имеет смысл делать, если константа меняется по "умыслу" пользователя.
2) С чисто технической ;-) точки зрения изменение константы может происходить только, если выполняется явное присвоение. Это при условии, что таблица констант не превышает одного гигабайта. В Вашей базе это так? А ошибочное явное присвоение может выполняться в алгоритмах конфигурации, если для определения значения константы используется информация из таблиц с размером более одного гигабайта.
3) Т.е. надо проискать в конфигурации все операторы присвоения значения константы. И анализировать их. Если есть возможность - присоедините в тему форума файл MD. Поищем хором. :-)
P.S. Информацию "только один пользователь зашел и вышел"(с) пока не учитываю в своих рассуждениях.
"...что это может дать?"(с)
Юля.
1) Это даст запись в журнал факта изменения константы. Далее надо будет анализировать журнал. Т.е. искать КТО и ЧТО делал после изменения константы. А еще и добавить в "ловушку" рекомендации из (66) сообщения. Но, это имеет смысл делать, если константа меняется по "умыслу" пользователя.
2) С чисто технической ;-) точки зрения изменение константы может происходить только, если выполняется явное присвоение. Это при условии, что таблица констант не превышает одного гигабайта. В Вашей базе это так? А ошибочное явное присвоение может выполняться в алгоритмах конфигурации, если для определения значения константы используется информация из таблиц с размером более одного гигабайта.
3) Т.е. надо проискать в конфигурации все операторы присвоения значения константы. И анализировать их. Если есть возможность - присоедините в тему форума файл MD. Поищем хором. :-)
P.S. Информацию "только один пользователь зашел и вышел"(с) пока не учитываю в своих рассуждениях.
Если конфигурация типовая, то эта дата может меняться:
Через обработку НастройкаПараметровУчета (ТиС) или УстановкаЗначенийОбщая (Бух)- запретить пользователям ее использовать.
На прямую через список констант - запретить пользователям эту константу менять (видимо уже сделано).
Через внешнюю обработку - оставить пользователям только общие внешние обработки, а общие проверить на изменение этой константы.
Если пользователи работают круглосуточно - нужно попробовать посмотреть не происходит ли это в полночь - или просто переставить в меню / Сервис / Настройка параметров системы - установить у рабочей даты "Не изменять в полночь".
Ну и шпионский вариант, дописать глобальный модуль:
И чуть дописать в глобальном модуле процедуру ПриНачалеРаботыСистемы
Поймать нарушителя за руку.
Через обработку НастройкаПараметровУчета (ТиС) или УстановкаЗначенийОбщая (Бух)- запретить пользователям ее использовать.
На прямую через список констант - запретить пользователям эту константу менять (видимо уже сделано).
Через внешнюю обработку - оставить пользователям только общие внешние обработки, а общие проверить на изменение этой константы.
Если пользователи работают круглосуточно - нужно попробовать посмотреть не происходит ли это в полночь - или просто переставить в меню / Сервис / Настройка параметров системы - установить у рабочей даты "Не изменять в полночь".
Ну и шпионский вариант, дописать глобальный модуль:
//ХХХ\\ Для проверки изменения константы
Перем ХХХисходнаяДата Экспорт;
Процедура ХХХДополнительнаяОбработка(пар=0)
Если Константа.ДатаЗапретаРедктирования <> ХХХисходнаяДата Тогда
Предупреждение("Всем стоять бояться - изменена Дата запрета редактирования! Служба безопасности уже к вам едет!");
КонецЕсли;
КонецПроцедуры //ХХХДополнительнаяОбработка
//ХХХ\\ Конец вставкиИ чуть дописать в глобальном модуле процедуру ПриНачалеРаботыСистемы
//ХХХ\\ Доп обработка
ХХХисходнаяДата = Константа.ДатаЗапретаРедактирования;
ХХХДополнительнаяОбработка(1);
ОбработкаОжидания("ХХХДополнительнаяОбработка",60);
//ХХХ\\ конец вставки
КонецПроцедуры // ПриНачалеРаботыСистемы()Поймать нарушителя за руку.
Ну тут пока вижу только 2 причины:
- первая, это либо события по установке или снялию даты запрета редактирования не попадают в журнал регистрации;
- вторая, это возжможно какой то умник написал обработку и чисто двигает дату для того что-бы править прошлые косяки.
Как варинат, раз вы админите базу, оставте эту возможность только себе
- первая, это либо события по установке или снялию даты запрета редактирования не попадают в журнал регистрации;
- вторая, это возжможно какой то умник написал обработку и чисто двигает дату для того что-бы править прошлые косяки.
Как варинат, раз вы админите базу, оставте эту возможность только себе
(2) SaschaL, Что я и сделала.. Я оставила эту возможность только одному человеку. И у пользователей прописала роли , по которым они имеют право только просматривать, но не редактировать, Еще меня смущает что на одно тоже время по актам сверки выдает разные данные.. Не выводит данные например на какое-то число. А иногда выводит верно акты...
В журнале регистрации не отображаются действия по изменению даты регистрации в том случае, когда это делается обработкой. Я не вижу таких обработок... Но самое интересное, что дата устанавливается не прошлым периодом, а будущем. при чем совершенно хаотично. На один день может закрыться 19.10 или 9.09. А рабочая дата к примеру 12.07.
Почистите кэш (частенько глюки бывают из-за него):
На каждом компьютере пользователей удалите все папки с длинным нечитаемым названием в C:\Documents and Settings\Пользователь\Application Data\1C\1Cv82
Пользователь-профильная папка
На каждом компьютере пользователей удалите все папки с длинным нечитаемым названием в C:\Documents and Settings\Пользователь\Application Data\1C\1Cv82
Пользователь-профильная папка
Дата запрета... каждый день меняется в хаотичном порядке...(в разное время и на разное число).... Стоит таких три базы но разные фирмы. И во всех базах происходят изменения этой даты.Произошло это месяц примерно назад. И сейчас происходит каждый день по два- четыре раза в разных фирмах. Бывает даже что пользователи никаких действий не производили (только зашли или вышли из программы.) И дата сама перескочила на другое число. При чем постоянно на будущий период (примерно на 2 - 3 месяца вперед) Никак не могу отследить из-за чего.
(17) ЮлияМ, на сколько я знаю кэш у 7-ой версии хранится в реестре:
Пуск - Выполнить - regedit
Ветка: HKEY_CURRENT_USER\Software\1C\1Cv7.
На сколько я знаю, там хранятся временный файлы.
У меня у самой был однажды глюк с определенным пользователем. Удалила раздаел в ветке, принадлежащий ему и глюк исчез
Пуск - Выполнить - regedit
Ветка: HKEY_CURRENT_USER\Software\1C\1Cv7.
На сколько я знаю, там хранятся временный файлы.
У меня у самой был однажды глюк с определенным пользователем. Удалила раздаел в ветке, принадлежащий ему и глюк исчез
(116) Ёпрст, ну может я не так выразилась. но исходя из личного опыта я могу сказать, что чистка реестра помогает избавиться от некоторых глюков.
В моем случае конкретный пользователь не мог зайти в базу, хотя за день до этого это ему удавалось, и ни каких работ с базой да и сервером за этот период не производилось. Почистила реестр и пользователь смог работать
В моем случае конкретный пользователь не мог зайти в базу, хотя за день до этого это ему удавалось, и ни каких работ с базой да и сервером за этот период не производилось. Почистила реестр и пользователь смог работать
ну я поняла.. это самый легкий вариант
это не самый легкий, но правильный путь исправления ошибок
Переиндексации мало, следуе попробовать именно тестирование и исправление. Только сначала на копии базы. И отключить внешние компоненты, если они есть.
А потом это сделать.
(41) АлексейН, Да. Я знаю... Но у меня само интересное что одно и тоже на трех базах происходит.ю Ладно бы просто на одной. А стоят три базы 7.7 и в них дата запрета редактирования меняется, но в разное время. Кстати, в одной из них она меняется реже чем в других (тут она может смениться один раз в трое суток.)
(44) finansoft., Я все уже прошарила.. все посмотрела. Нет там такого. Я даже в одной программе ДатуЗапретаРедактирования поменяла на другое имя.. Думала изначально что кто-то обработкой ее меняет. Безрезультатно.. К тому же я роли прописала всем. Поставила запрет на редактирования этой константы и обработку "Общая настройка" запретила даже на просмотр (времеено естественно)
(63) ЮлияМ, для dbf-файла вообще предел 2 GB, для 1С на практике 1Gb становится верхней планкой. По этому поводу и здесь куча постов, и на других сайтах.
Поэтому только SQL ! Я уже молчу про то, насколько SQL быстрее и надежнее (правда в 1с это не очень заметно:) ).
Поэтому только SQL ! Я уже молчу про то, насколько SQL быстрее и надежнее (правда в 1с это не очень заметно:) ).
(68) не надо советовать то, в чем не разбираетесь.
SQL,
а)не быстрее, а медленнее
б)при размере 1 гб можно еще жить столько же..
Тем более, бухия на скуле - тот еще подарок. Если автор не знаком с классами Берездецкого или Александра, то просто ау - вся работа остановится.
SQL,
а)не быстрее, а медленнее
б)при размере 1 гб можно еще жить столько же..
Тем более, бухия на скуле - тот еще подарок. Если автор не знаком с классами Берездецкого или Александра, то просто ау - вся работа остановится.
(69) у меня комплексная на SQL уже лет 7 назад стояла. И сейчас бухня 7.7 на SQL стоит. И никакие твои классы Берездецкого на хрен не нужны.
А если у тебя проблемы разобраться с SQL, то другим голову не морочь.
А если у тебя проблемы разобраться с SQL, то другим голову не морочь.
При таком размере файла проводок, у тебя данные в отчетах (во всех) будут всегда разные..
таже оборотка или анализ счета.
И какой из этого выход ?
таже оборотка или анализ счета.
(76) Ёпрст, Хотели делать свёртку на комплексной, но как прикинули, что бухи не будут видеть прошлые данные в этой же базе, акт сверки сделать за 2 года (куча дебиторов и кредиторов, история долгов которых тянется века:)) к примеру и прочее - столько минусов. Решили перейти на SQL и сохранить всю историю в одной базе
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот