Проблема записи изменений в карточке Справочника

1. user1135816 4 28.02.20 08:55 Сейчас в теме
Приветствую. Возникла такая проблема. Есть конфигурация Управление нашей фирмой, редакция 1.6 (1.6.19.215) (последний релиз), Агент сервера 8.3.13.1644 (на нем случались также "проблемы"), а далее был установлен агент сервера 8.3.15.1830 (на нем "проблемы также присутствуют). Сервер SQL версия 18.2. Сервер находится с компьютерами в локальной сети, естественно у менеджеров несколько усеченные права. Подключение базы идет клиент серверное. Проблема заключается в следующем: у одного из менеджеров при внесении в карточку контрагента, информации в поле "Заметки" и при записывании - справа внизу появляется окошко "Изменение Контрагента "___"" Но при выходе из карточки контрагента и повторном входе - информация бесследно исчезает. Нет также записи в журнал регистрации о проведенной транзакции. Кто-то сталкивался с подобной проблемой? Как решилось? На копии, которая разворачивается на сервере с выгруженным дтшником, проблема не воспроизводится, однако на копии работа производится непосредственно на сервере. Планирую: проверить на тестовой - с компьютера менеджера. Но с чем может быть связана данная проблема?
По теме из базы знаний
Ответы
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
18. AlexO 135 29.02.20 12:49 Сейчас в теме
(1)
Но с чем может быть связана данная проблема?
кэш пользовательский почистите.
1С вообще не умеет нормально работать со своим же кэшем, и периодически "бьет" темповые файлы.
2. mazechild 28.02.20 09:06 Сейчас в теме
А на копии проверяли под пользователем, у которого проблемы?
4. user1135816 4 28.02.20 09:15 Сейчас в теме
(2) да, естественно. К сожалению, не повторилась. Причем на удаленном подключении сам видел "ошибку" своими руками.
3. Serega-artem 16 28.02.20 09:13 Сейчас в теме
Нет УНФ под рукой, а подскажите, поле заметки это реквизит справочника или какой-то друго объект метаданных (регистр сведений, например). Ошибка происходит постоянно у этого сотрудника, или время от времени? Есть еще сотрудники с такими же правами? У них как?
5. user1135816 4 28.02.20 09:21 Сейчас в теме
(3) Заметки - это реквизит справочника "Комментарий", тип Строка неограниченной длины. Ошибка "периодическая", мне известно, что она также воспроизводится у еще двух менеджеров (права у 2их одинаковые, у одного есть роль "Администрирование"; виндовые права у всех усеченные). У них также возникает проблема с не сохранением контактной информации Контрагента, т.е. в поле "Факт. адрес", "Юр.адрес" и "Почтовый адрес", не нажимая на "три точки" просто в строку вставляют адрес (в любом формате - Город улица дом, Страна-область-город-улица и т.п.) и при записи он также не сохраняется. Однако, при входе на проблемном контрагенте под проблемным менеджером и внесении адреса через "три точки", все сохраняется.
6. Serega-artem 16 28.02.20 09:44 Сейчас в теме
(5) Давайте порассуждаем, что может быть:

1. Проблемы с правами при записи в SQL
2. проблемы с правами при работе в 1с (При внесении данных в реквизит выполняется какой-то код, получается где-то отказ, и не обрабатываемым исключением закрывается ).
3. Проблема при передачи данных от клиента к серверу 1с.

Ну 1 я бы исключил, т.к. с SQL 1с работает по одной учетной записи и там бы проблема была общая. Хотя, протестировать базу SQL было бы не лишним. Возможно, так же происходит какаято коллизия при записи данных в таблицу.

2. Вроде самое логичное. Тем более и у других менеджеров повторяется проблема. Но почему на тестовой базе все работает?

3. Ну тут как миимум кэш почистить...
7. user1135816 4 28.02.20 10:00 Сейчас в теме
(6) в планах именно чистка кэша: при помощи выгрузки-загрузки файла *.dt. Сам думаю, надо посмотреть, что происходит при ПередЗаписью (Модуль Объекта) у менеджера. Как это сделать - планирую воткнуть через расширение записать ход движения в файл. и посмотреть. Но может это наполеоновские планы и все решит дт-выгрузка
9. Serega-artem 16 28.02.20 10:06 Сейчас в теме
(7) Вы хотите создать новую базу, с новым именем и загрузить туда выгрузку старой? Решение вполне себе здравое, если есть такая возможность. Но про локальный кэш у пользователей тоже не забывайте. ну и перед выгрузкой я бы еще ТиС прогнал. Ну и поищите по имени реквизита в модулях справочника, что он с ним делает, при записи и вообще.
11. user1135816 4 28.02.20 10:10 Сейчас в теме
(9) грубо говоря перезаписать одну и ту же. Это здраво - про тестирование - однако база 11 Гб dt файл и 22 Гб bak файл SQL - соответственно будет тестировать прилично. Но попытаюсь это сделать.
13. Serega-artem 16 28.02.20 10:15 Сейчас в теме
(11) Как по мне, если заморачиваться с выгрузкой загрузкой через dt, так в новую базу. ну или хотябы - Выгрузить ДТ - Удалить БД - Создать новую с таким же именем (раз это критично) - Загрузить ДТ. Но это субъективо.
28. AlexO 135 29.02.20 13:33 Сейчас в теме
(11)
22 Гб bak файл SQL
пару дней ТИИ будет....
ТИИ - это не про проблемы у пользователей. Это коррекция служебных данных таблиц и исправление индексов. Т.е., в конечном итоге, работа на повышение производительности и освобождение БД от "хлама" и "битых" данных (не путайте с битыми ссылками в 1С - это совсем не тот уровень хранения данных, более низкий).
Проще говоря, данная ситуация - может привести к появлению "работы" для исправления в ТИИ, но непосредственно сам ТИИ - не исправит данную проблему.
27. AlexO 135 29.02.20 13:28 Сейчас в теме
(7)
в планах именно чистка кэша: при помощи выгрузки-загрузки файла *.dt
все делается проще: чистите локальный кэш у пользователей (пути знаете?), потом, если не помогло - серверный кэш.
8. user1135816 4 28.02.20 10:05 Сейчас в теме
(6) непонятно почему проблема плавающая? Контрагентов более 1000, а проблема возникает сегодня на этом, завтра на том. Думаю крамольную мысль - может в SQL есть какой то предел/защита отложить сохранение, а потом успешно его забывает?
10. Serega-artem 16 28.02.20 10:09 Сейчас в теме
(8) А размер БД и кол-во пользователей может подсказать? ну и совсем глупый вопрос, SQL у вас не экспресс случаем?
12. user1135816 4 28.02.20 10:13 Сейчас в теме
(10) 12 разношерстных пользователей. Размер выше. SQL не express:
SQL Server Management Studio 15.0.18142.0
Клиентские средства служб Microsoft Analysis Services 15.0.1389.0
Компоненты доступа к данным (MDAC) 10.0.18362.1
Microsoft MSXML 3.0 6.0
Microsoft Internet Explorer 9.11.18362.0
Microsoft .NET Framework 4.0.30319.42000
Операционная система 10.0.18363
14. Serega-artem 16 28.02.20 10:19 Сейчас в теме
(12) ну прямо скажем, это не те объемы,чтобы SQL начинала тупить при транзакциях. Единственное, что немного смущает - НЕ серверная ОС, но по сути не так критично. А сервер 1с и сервер SQL это физически один сервер или разные? И проверьте еще:

1. Нет ли каких-нибудь квот на размер БД в SQL.
2. Нет ли проблем с местом на жестком диске.
15. user1135816 4 28.02.20 11:13 Сейчас в теме
(14) Квоты проверю позже. Проблем с местом нет. По ПО могу сказать следующее - при создании на 64 битную ОС, установили 64 битный Агент сервера и 32 битную платформу. И вот так это все работало. До недавнего времени стали возникать очень частые завершения работы базы при закрытии месяца и было принято решение апгрейдить железо, ко всему прочему приурочили это к обновлению агента сервера и платформы. Апргейд заключался в распределении ресурсов на SSD и увеличение оперативной памяти до 64 Гб. И вот к работе, скорости работы - претензий нет; но появился этот сверчок.
16. Serega-artem 16 28.02.20 11:16 Сейчас в теме
(15) Не очень понял, что значит 64-битный агент сервера и 32-х битная платформа. Сервер 1с предприятия 32-х или 64-х ?
17. user1135816 4 28.02.20 11:30 Сейчас в теме
(16) 64 битный. А Платформа 32 битная
Serega-artem; +1 Ответить
21. AlexO 135 29.02.20 13:02 Сейчас в теме
(17)
А Платформа 32 битная
клиент у вас 32-хбитный. А сервер - 64-хбитный. Понимайте правильно.
А платформа - это "8.3.ХХХ". Вот это - платформа 1С.
20. AlexO 135 29.02.20 13:01 Сейчас в теме
(16)
Не очень понял, что значит 64-битный агент сервера и 32-х битная платформа
Агент сервера - это и есть сам сервер. Т.е. x64 в данном случае. "Платформа" - это клиент. Ибо других вариантов тут быть не может: одно звено - сервер, и одно звено - клиент. Больше звеньев в 1С нет))
СУБД - это не звено 1С, а "носитель" и "держатель" базы.
29. Serega-artem 16 29.02.20 20:43 Сейчас в теме
(20) Ну я так ТСа и понял, что у него на сервер 64, а на локальных компах 32.
22. AlexO 135 29.02.20 13:09 Сейчас в теме
(15)
при создании на 64 битную ОС, установили 64 битный Агент сервера и 32 битную платформу
вот уж это никак друг с другом не связано. Ставьте в любых вариантах.
До недавнего времени стали возникать очень частые завершения работы базы при закрытии месяца
Оптимизируйте регистры. Сделайте свертку базы. У вас наверняка многодесятко-миллионные регистры, с кучей "пустых" записей, которые, тем не менее, обрабатываются тоже.
Смена сервера - ну, тоже решение, на 2-3 года.
Апргейд заключался в распределении ресурсов на SSD и увеличение оперативной памяти до 64 Гб.
У вас, поди, и SQL-сервером вместе с 1С-сервером стоит? Вот SQL-сервер весьма критичен к объему памяти.
1С - они не умеют работать с памятью, там вылеты по памяти при превышении размера блоков записи в память, а не от нехватки оной.
х64 1С все также не умеет работать ни с несколькими процессорами, ни распараллеливать процессы обработки, ни использовать корректно память.
23. AlexO 135 29.02.20 13:17 Сейчас в теме
(14)
чтобы SQL начинала тупить при транзакциях
Это вы еще не знаете, как 1С-сервер может размножить запрос, и заставить SQL выбирать и выбирать данные, раздувая оперативный блок данных до гигантских размеров.
Количество пользователей важно для терминала и количества запросов одновременной обработки (для 1С-сервера).
Единственное, что немного смущает - НЕ серверная ОС
Это вообще не важно. Это важно только для самого ПО - может или нет оно работать в данной ОС.
Серверная ОС не занимается каким-то особыми "настройками" или "доработками" производительности или работы с БД.
Отличие серверной ОС от не серверной - в серверной есть специальные сервисы/службы/"сервера", которые позволяют чего-то там делать и выполняют какие-то специализированные задачи. Потому она и "серверная".
30. Serega-artem 16 29.02.20 20:45 Сейчас в теме
(23) Да не скажите! Много нюансов есть между серверной и не серверной ОС чисто по ресурсам (работа с памятью, кол-во подключений и т.п.). Но в данном случае это и правда не критично.
24. AlexO 135 29.02.20 13:20 Сейчас в теме
(10)
SQL у вас не экспресс случаем?
Это все такой же SQL-сервер, только с ограничениями на размер баз/поддерживаемого количества процов/еще ограничения по мелочи.
В остальном - обычный сервер MS SQL. Если вы в MS Express превысите ограничения - база 1С просто не будет делать ничего, кроме открытия и просмотра (будет заблокирована запись в базу, БД станет только для чтения).
25. AlexO 135 29.02.20 13:25 Сейчас в теме
(8)
может в SQL есть какой то предел/защита отложить сохранение, а потом успешно его забывает?
Такой функционал "отложенной записи" есть, но используется сугубо индивидуально, настраивается (1С не умеет работать с большинством возможностей СУБД, и использует не более 10% возможностей), и работает как технический сервис (т.е. не вот, что сегодня отложили, а завтра - записали): все происходит в рамках транзакций, и за время выполнения транзакций.
Так что "забыть" там что-нибудь никто и ничего не сможет - некому и нечего))
26. AlexO 135 29.02.20 13:26 Сейчас в теме
(8)
непонятно почему проблема плавающая?
потому что любая "плавающая" или "фантастическая" проблема при работе в 1С - это от неумения 1С работать с собственными временными данными (кэшем).
19. AlexO 135 29.02.20 12:55 Сейчас в теме
(6)
1. Проблемы с правами при записи в SQL
о чем SQL вам любезно бы сообщил)
2. проблемы с правами при работе в 1с
1С бы в таком случае (в отличие от SQL) напрямую не сообщила, но минимум - ошибка записи элемента была бы. Что навело бы на мысль о нарушенных правах в 1С.
3. Проблема при передачи данных от клиента к серверу 1с.
Данные или передаются, или не передаются. В 1С в некоторых случаях данные могут передаться "битые" (т.к. нет контроля записи и проверки записываемых данных - получила чего-то там, отдала дальше в БД - а там трава не расти) - но все равно что-то да уйдет в базу. Варианта "данные ушли, но до базы не дошли, и база не в курсе" - возможен только в одном случае: отключение электроэнергии в момент передачи, и если реализовался данный вариант, то после этого база будет 100% битая.
так же происходит какаято коллизия при записи данных в таблицу.
все "коллизии записи данных в таблицу" отслеживаются СУБД. Это вам не 1С))
Тем более и у других менеджеров повторяется проблема.
1С любит повторять ошибки в разных вариациях, и множестве случаев))
о почему на тестовой базе все работает?
Потому что еще не успела сама себя запороть.
3. Ну тут как миимум кэш почистить...
Это и есть причина. Единственная))
31. Serega-artem 16 29.02.20 21:02 Сейчас в теме
(19) все "коллизии записи данных в таблицу" отслеживаются СУБД. Это вам не 1С))

Согласен, но не все админы обладают достаточным уровнем знаний, чтобы это отслеживать. Поэтому она то (СУБД) может и пишет)
32. user1135816 4 02.03.20 09:39 Сейчас в теме
Хорошо, что создал такую тему, многим и мне в том числе будет(было) интересно) По поводу, того, что сделал - перезаписал дт-шник. Буду отслеживать ситуацию. Если опять повторится, займусь чисткой кэша на клиентах (к сожалению, есть сложности с удаленкой с ними). По итогу, естественно отпишусь - помогло или нет
33. user1135816 4 02.03.20 10:35 Сейчас в теме
Почистил кэш "проблемных" пользователей. продолжаю следить за ситуацией!
34. user1135816 4 04.03.20 13:47 Сейчас в теме
2 дня с локальной чисткой кэша - полет нормальный
Оставьте свое сообщение

Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот