Обкурил большинство информации и нигде не нашел однозначный ответ.
Вник в механизм файла .1cd,есть и спорные моменты...
Понял,что при запуске тонкого клиента,вместе с ним поднимается серверная микросреда.Ну ок...а если речь идет о файловой базе на УФ,расшаренной на NAS,на нем 1сные процессы не подняты,транспортный протокол может и не собрать пакет по разным причинам.
1)Как в таком случае контролируется целостность базы?
2)И в каком случае целостность базы под угрозой,в случае ее расшаривания (я про типы подключения:толст.,тонкий и м.б. разновидность конф.)?
3)Про скажите,расшаренную БП3 не экстремально бзать тонким клиентом через VPN?)

если не опубликована, что тонкий, что толстый разницы быть не должно. Опубликованная через впн шикарно, скорость локалки. Без публикации плохая идея

Под публикацмей WEB-сервер понимается?

да

Что есть целостность базы в данном контексте?

и почему она должна страдать?

(3) Web-сервер не публекуеться на NAS (автономный файловый сервер на своей зажатой ОС)

По схеме: 'NAS' <сеть> 'комп с поднятым Web-клиентом'
если между ними "порвется" логическое взаимодействие,как пострадает файловая база? - на ее стороне нет процессов отслеживающих транзакции,кроме как запись каких-либо флагов в таблицы файла базы или рядом с ним (некий кэш)...ведь емкось буфера транспортного протокола не учитывает особенности архитектуры файловой базы или разрабы 1с все хитро учли?

(4) Логическая завершенность данных,при их считывании/записи клиентом (Толcтым/Тонким)

(5) на стороне NAS (расшаренной базы) нет процессов отслеживающих транзакции,кроме как запись каких-либо флагов в таблицы файла базы или рядом с ним (некий кэш)...

да Web-сервер вроде как реализует механизм обработки управляющих команд и трансформации данных в HTTP,т.е. он не берет на себя задачу контроля транзакционной целостности самой логики конфы (архитектуры платформы).

или я не прав,поправьте мои сомнения более развернутым ответом)

(6) "Процессы отслеживающие транзакции" на насе есть всегда. Файловые блокировки называются. Это заодно причина того, что на файловой базе уровень транзакции всегда сериализация.

(9) веб сервер просто дает ещё один уровень "сериализации" - сначала выстраивает запросы от клиентов в очередь, а затем единолично общается с файлом базы.

(9) В чем выражаются эти процессы? -в виде файла?
...ведь любые осознанные манипулящии происходят на удаленном компьютере,который на NAS возвращает в виде модифицированны областей,которые могут тупо не все "приехать" обратно на NAS в виду обрыва сетевого-взаимодействия...или на каждую модификацию (одного байтика) отрабатывает сначала блокировка в виде некого файла рядом с базой?

Соответственно, ответ на твой вопрос об угрозах - все, что может помешать файловым блокировкам. От неисправного сетевого адаптера, через ошибки протоколов до некорректного кэширования какой нибудь службой автономных файлов

(7) все правильно, только веб сервер работает как веб сервер с модулем 1с который соединяется типа с (файловым) сервером приложений, который должен работать с базой локально. Его минус что он однопоточный, т.е. для одной публикации клиенты будут обслуживаться по очереди и ожидать на длительных операциях. Решается публикацией нескольких инстансов

(10) т.е. все таки web-сервир некий псевдо-заменитель серверного процесса 1с,который не только юзает управляющие команды?

(11) "эти процессы" выражаются в стандартной функциональности самбы на насе по блокированию фрагментов файлов.

ок,т.е.:
1)Расшаренная база на УФ <сеть/инет> Тонкий клиент = не безопасно
2)Расшаренная база на УФ <сеть/инет или в рамках компа> Web-сервер <сеть/инет> Тонкий клиент = безопасно

так?

А при тех же равных Толстый клиент что может натворить?

(16) чаще портится кеш, маленький риск получить битую базу

(14) Нет там никакого сервера.
Он тупо преобразовывает вызовы по хттп в те же операции с файлом, которые положение  делает само. Причем используя те же самые длл. Единственный профит в том, что ошибки сети до файла не долетают. Ну, если вебсервер с файлом базы на одной машине ессно

(17) ...даже в случае (2)?

(19) прошу прощения:
(17) ...даже в случае в (16) пункт (2)?

(19) нет, перечитай все ответы и см (18)

Расшаренная база на УФ <в рамках компа> Web-сервер <сеть/инет>

файловые базы 1с не содержат надежных механизмов отката не завершенной транзакции. Да и что такое уровни изоляции данный не знает то-же...

По этому ЛЮБАЯ конфигурация файловой базы несет потенциальную угрозу целостности данных и структуры в целом...

да и вообще - есть же практически бесплатный минисервер 1с с бесплатными СУБД... нафига пытаться впихнуть тестувую субд в продакт бизнеса?

(18) ооот)
"...Ну, если вебсервер с файлом базы на одной машине ессно"

(22) я правильно понял,такая связка более безопасна?

(25) нет, не правильно... в файловой базе (все равно какой конфигурации) 100% кода выполняется на клиенте... Ну нету сервера !!!

(25) Да. Ценой потери производительности на многих клиентах к одному инстансу вебсервера.

(23) Ок)
По такой схеме работает подразделение и меня не слушает(

(25) да, спасает от части страшилок. Плюс визуально интерфейс более отзывчивый
(26) есть

(26) вот эти мысли у меня и возникли,почему  и тему завел,жаль что мало кто понимает глубину вопроса

(26) Дядь Дим, речь о снижении риска повреждения файла базы, сначала тему почитай, плз. Твоя серверность из другой оперы.

(29) интересно про сервер у файловой базы,

небось скажешь, что он расположен на веб сервере? так расстрою тебя, это не сервер, а немного специфичный клиент и не более того... У него нет функций блокировки, балансировки нагрузки, работу с транзакциями и т.д.

(32) он мини, и он однопоточный, к нему некоторые слова просто не применимы

УФ - зло, ставить УФ на ларек или среднюю сеть глупо по самое не хочу, работа по РДП или вообще на локальной машине, на кой здесь тонкий клиент и УФ? Только попусту разбазаривать ресурсы...

(34) "работа по РДП или вообще на локальной машине" попробуй отказаться и удивись

(31) да я понимаю о чем. Риск работы с файловой базой заключен в двух моментах
1. разрушение/рас синхронизация структур ответственных за хранение страниц таблиц
2. не валидность данных

обе проблемы идут именно от отсутствия софта который обеспечивает блокировки и транзакции, ну если с блокировками клиенты 1с сами еще умеют (хоть и плохо) работать, то с чужими транзакциями клиенты 1с вообще не умеют работать. Именно это и приводит к 99% отказов файловых баз

итог:
А)Расшаренная база на УФ <в рамках компа> Web-сервер <сеть/инет> - но все равно присутствуют риски,ожидание на блокировках.
Б)Серверная СУБД с базой на УФ <> Серверный процесс 1с (кластер) <> клиент - безопасно по целостности но дорого

Коллеги,а если в случае (Б) но база на обычных формах и  подключаться Толстым клиентом,это безопасно для целостности базы/конфигурации?

(34) Изначально предложил как проверенный вариант,но не хотят)

(35) А на хрена?

(33) ха.... как думаешь к одному файлу базы сколько можно подключить web серверов (ну или клиентов)? и как они будут друг с другом работать ? неужели как кластер????

(34) им нравиться простота,кинул базу в расшаренную папку,указал режим и доступ...думать не надо,админ починит если че)
а тут какой то РДП...)
Такая логика у продвинутых юзеров

(39) там опять файловые блокировки, я тебя понял. Но у файловой опубликованной нет _взаимоблокировок_ и _чужих_ транзакций, но плюсы все равно остаются
(40) ну, достанут пару раз первичку чтобы вбить по новой, забудт и потеряют пару заказов. Получат дабл дип, и деньги потеряли и потратились таки на нормельное решение

(36) Эх. Еще один на лошадке с сабелькой правду-матку рубить прискакал.
Есть такой софт, есть. Файловые блокировки операционки. Именно на них построен единственный уровень изоляции, доступный файловой базе - сериализация. А при работе по сети эти блокировки реализуются самбой. Которая своего мнения о них. Добавим нестабильность сети, ошибки реализации на всех уровнях и получим минусы решения.

(41) с файловой опубликованной базой нельзя работать напрямую???

(41) Вот как только сделаешь две публикации для производительности, к тебя появятся "чужие" блокировки

(39) я даже на А3 нарисовал (абстрактно) содержимое .1cd и (дофантозировал) фалы блокировки + нарисовал движение пакетов по сети,передача в рамках NAS по OSI,обработка пакетов механизмами протоколов с их кэшем...симуляция работы трех пользователей,конкурентной борьбы за области данных...
вопросов вогон и не доверии к расшаренной базе)

(40) Увы, это так - похоже жертвы реформы образования уже начали доказывать свою "профпригодность"...

Меня например учили, что ресурсы нужно беречь... А конечный продукт (изделие) должен быть максимально простым и понятным для пользователя...

(44) они будут на стороне операционки и вероятно в каких то файликах, чтобы закрыться от разных версий клиентов хотя бы
(45) добавь еще кеши 1с ос рид эехед райтбэк смб 1.0, только перед сном не читай)

(46) И кран с водой закрывать...

Вот у них и есть максимально простой и понятный продукт. Они его поняли и эксплуатируют. Просто и понятно. Для них.
А тут какие-то админы о чем-то своем возмущаются.

(46) да я и сам дилетант,но с большим любопытством и поиском безопасных (почти) решений

страшилка от друга знакомого. После обновления на одном компе где база через шару была, клиент 1с решил что новая конфа старее, "конфигурация базы не соответствует блабла бла. применить изменения?" фигня вопрос, конечно. База умерла, минус час работы, повезло что час

(50) ))))))))
вот поэтому в прошлом запросил бюджет на зерколо из жирных дисков и молюсь на кобиан...т.к. и жизни не хватит во всем разбираться)

(51) зеркало из другой оперы, там изящно протух кеш

(51) Админы делятся на 2 типа:
1. Которые делают бэкапы
2. Которые собираются делать бэкапы

(47) да хрен там, 1с использует блокировки операционнки "на участок файла" (такие-же как в 77 для списка активных юзеров), проблема в том, что эти блокировки не монопольные и могут накладывается одна по верх другой (блокировка на основе дискрипторов)

(54) буду знать. но "для ларьков" публикация все равно сильно лучше и веб клиент иногда сильно выручает

(55) даже для ларька 15тр на минисервер 1с это не деньги

(53) Из трёх. Третьи периодически бэкапы на вменяемость проверяют. Знавал я твой второй тип, которые гордо потрясали бэкапом с зашифрованными файлами и просили себе премию за дальновидность.

(57) да) по третьему пункту (проверка бэкапа), согласен,иногда с ленью борюсь)

(54) Не все так просто, там хитрее. Блокировки бывают разные (и монопольные тоже, как попросишь). 1С использует их, чтобы защититься от разных сценариев порчи данных. По сравнению с 7.7 прогресс есть. В некоторых случаях даже получается откатить незавершенные транзакции после сбоя. Еще есть высокоуровневые объектные блокировки, они тоже реализуются через файловые. Есть еще файлик .1CL, там тоже живут разные блокировки. Технология отработана еще со времен первых версий Micfosoft Access.

Филиал-msk дело говорит, слушайте его.

(0) Нет, не страдает. Ибо в файловом варианте есть два состояния базы - поломана и работоспособна. Но я бы рекомендовал через веб-сервер развернуть базу ибо он балансирует нагрузку.

(59)
Значит можно дописать необходимый функционал на УФ для УТ10 и смело в файловом через WEB-сервер,подключаться по (даже) WiFi,так получается?
(60)
...опять не уверенность вселяете)))

Через браузер пистолет (сканер) работает? - пока нет под рукой пистолета,не могу проверить.

(61) По Wi-Fi я бы не советовал, ненадежно. Но через браузер, наверное, можно.

P.S. Чтобя меня правильно поняли, я не утверждаю, что файловая база так же надежна, как SQL. Сценариев, когда происходит потеря данных, тоже полно, и они случаются.