Проблемы с доступом к базе
Здравствуйте. Есть база 1С 8.3 Зарплата и управление персоналом 3.1.10. Она находится на съёмном жёстком диске, который подключён к компьютеру, который в свою очередь выступает в качестве сервера в локальной сети. Почему сделано именно так я не знаю и поменять возможности нет. Вопрос не в этом. К данной базе есть доступ по сети. Проблема следующая. Когда Сервер заходит в эту базу он видит одни данные, когда заходит человек с другого компьютера, подключаясь по сети он видит другие данные. Пути проверены не раз, по идее это одна и та же база, но документы разные. Пробовали создавать нового пользователя и заходить им, суть не поменялась. После, требовалось обновить данную базу, я решил обновить её именно с компьютера где заходят по локальной сети, в итоге при заходе с сервера релиз базы не обновлённый, а с компьютера где обновлял - обновлённый..не могу понять куда копать, заранее спасибо.
По теме из базы знаний
- Практика доступа в базу 1С через протокол oData. Чтение данных
- Универсальная система оповещений в базе или по почте по произвольным условиям, расписанием, ролям и пользователям (Расширение / конфигурация для платформ 8.3.6+, для ЛЮБЫХ баз)
- Распространенные ошибки разработчиков, приводящие к проблемам производительности
- SynchroSber - полноценный модуль API интеграции с маркетплейсом Мегамаркет (СберМегаМаркет) для 1С УТ 11.X, КА 2.X, ERP 2.X, УНФ 1.6, 3.0 (возможность работы как с публикацией, так и без публикации базы)
- База для управления базами. Монстр или Франкенштейн?
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
Какая проблема перенести файл базы на нормальный жесткий диск, лучше - SSD?
Тем более, вы не назвали даже ОС на сервере.
Почему сделано именно так я не знаю и поменять возможности нет.
Если машину зачем-то поставили на квадратные колеса и нет возможности это изменить - не стоит ожидать, что она будет нормально ездить и спрашивать: "Куда копать?"
Какая проблема перенести файл базы на нормальный жесткий диск, лучше - SSD?
я решил обновить её именно с компьютера где заходят по локальной сети, в итоге при заходе с сервера релиз базы не обновлённый, а с компьютера где обновлял - обновлённый.
Тут можно бесконечно гадать: то ли все-таки не тот диск расшарен, то ли отложенная запись на внешний HDD тормозит, то ли использование автономных файлов включено, то ли какая-то неведомая приблуда для зеркалирования (или кэширования) криво работает.
Тем более, вы не назвали даже ОС на сервере.
(5)
Получается лечение по словесному описанию фотографии больного. ;)
(6)
На сервере ОС WIn 10
Уже лучше, но это ничего не говорит о ее настройках и установленном софте.
Получается лечение по словесному описанию фотографии больного. ;)
(6)
Самому нет возможности выехать туда, так как это в другом городе, приходится искать варианты по удалёнке
Для начала можно попробовать подключиться удаленно к одному компу (например, сетевому), с него закинуть в папку с базой какой-нибудь безобидный файлик с уникальным именем (типа !!!.txt), потом переключиться на сервер и проверить - появился в папке на внешнем диске этот файл или нет?
(2) Спасибо за то что подсказали про автономные файлы, в общем вот что получается. Я правильно пониманию из-за вот этой вещи все изменения которые люди вносят с данного компьютера остаются только у них на компьютере и не попадают в базу по сути? Теперь главный вопрос что с этим делать: попробовать провести синхронизацию или же отключить автономные файлы вообще. И если я отключи автономные файлы не потеряем ли мы все изменения?
Прикрепленные файлы:
(1)
Точно разные базы. Проверяйте пути до файлов.
А, вообще, с такими параноиками лучше не работать.
Когда Сервер заходит в эту базу он видит одни данные, когда заходит человек с другого компьютера, подключаясь по сети он видит другие данные. Пути проверены не раз, по идее это одна и та же база, но документы разные.
Точно разные базы. Проверяйте пути до файлов.
А, вообще, с такими параноиками лучше не работать.
Да просто базы разные.
зы. Как то один клиент тоже решил держать базы на внешних жеских ради безопасности. Больше мы с ним не работали)
Проверить можно было сразу, отсоеденив жесткий диск и зайдя по сети с другого компьтера. полюбому зашел бы куда то.
зы. Как то один клиент тоже решил держать базы на внешних жеских ради безопасности. Больше мы с ним не работали)
Проверить можно было сразу, отсоеденив жесткий диск и зайдя по сети с другого компьтера. полюбому зашел бы куда то.
(3) При отключении жёсткого диска попасть в базу нельзя. Оказалось что на компьютере включены автономные файлы, с какой целью это делали, я не знаю, видимо из-за того что сетка работает как попало((( Висят ошибки в автономных файлах, я так понимаю мы сейчас должны провести как раз эту синхронизацию чтобы файлы обновились на сервере?
Прикрепленные файлы:
(10)
А по уму я сравнил бы - какой из вариантов базы содержит более актуальные данные, из этого бы и исходил.
P.S. Внешний ЖД и автономные файлы - лично я бы послал такого клиента... на поиски толкового сисадмина.
из-за того что сетка работает как попало((
Это называется: "Лечить рак кожи лейкопластырем".
я так понимаю мы сейчас должны провести как раз эту синхронизацию чтобы файлы обновились на сервере?
Если вы готовы положиться на капризы и глюки Винды - да.
А по уму я сравнил бы - какой из вариантов базы содержит более актуальные данные, из этого бы и исходил.
P.S. Внешний ЖД и автономные файлы - лично я бы послал такого клиента... на поиски толкового сисадмина.
(11) В общем суть такая что приглашали разных людей и каждый всё делал и настраивал по своему, в итоге получилось то что получилось(( Актуальные данные находятся как раз на том компьютере где ошибки синхронизации висят, с этого компьютера забиваются все документы, а на сервере Гл. Бух иногда просто заходит в базу чтобы посмотреть нужную информацию. Ещё такой вопрос, вот эти данные которые висят в ошибках синхронизации, их реально физически увидеть на компьютере или же они висят на подобие как в облаке?
(12)
Сам бы я зашел в конфигуратор, выгрузил более актуальную базу в .dt, а после приведения настроек в более-менее нормальный вид, загрузил бы ее на сервере и сделал ТиИ.
Разумеется, с предварительным сохранением копий всего и вся.
данные которые висят в ошибках синхронизации, их реально физически увидеть на компьютере или же они висят на подобие как в облаке?
Без понятия, я никогда плотно не работал с автономными файлами - они для редко изменяемых файлов, а это условие к 1С не относится. Попробуйте погуглить что-то типа "где Windows хранит автономные файлы"
Сам бы я зашел в конфигуратор, выгрузил более актуальную базу в .dt, а после приведения настроек в более-менее нормальный вид, загрузил бы ее на сервере и сделал ТиИ.
Разумеется, с предварительным сохранением копий всего и вся.
(15)
Если битая, то поврежденные данные утрачиваются и восстановлению не подлежат, никаким способом. Именно поэтому 1С не рекомендует такую выгрузку как способ создания бэкапов.
Когда выгружаешь базу в dt там же все данные полностью сохраняются?
Если база целая (без ошибок) - то да.
Если битая, то поврежденные данные утрачиваются и восстановлению не подлежат, никаким способом. Именно поэтому 1С не рекомендует такую выгрузку как способ создания бэкапов.
Внимание! Тема сдана в архив
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот