1C+SQL или 1С(dbf) + RDP

Вобщем наболело мне, пришёл жаловатся...
По мере своей работы часто приходится сталкиватся с 1сниками, иногда очень тугими

Значит типичная ситуация, есть небольшой офис, который покупает 1С к примеру 8.1 сетевую, приезжает человек, ставит дистрибутив на сервер, расшаривает базы, подключает их к локальным машинам, всё! после этого его работа сделана, что касается установки.

Далее, проходит месяца три\четыре, база растёт, ну и как вы уже догадались, что в dbf исполнении она тормозит, иногда очень. Бухгалтера жалуются на 1С кренделю который их обслуживает, тот им сообщает, что у вас такая конфигурация сети  
звоните вашему админу и пусть разбирается, и пусть вам делает терминальный доступ к серверу.
Дальше я начинаю общатся с 1сником

Он мне, давай делать доступ к 1с через удалённый рабочий стол  
Говорю ему, нахрена мне что б десяток человек логинился на сервер на котором лежат базы? нафига мне писать политику в домене для этих пользователей? да и нафига мне вобще открывать RDP на сервере баз данных?
Говорю ему, давай поставим шаровой SQL Express, там база до 4гиг и куча подключений и забудем.


плюс к этому всему терминальные лицензии стоят денег, около 80уе 1шт, но 1сники почему-то считают или вобще не знают, что они платные.

И таких у меня уже несколько человек, просто не хотят или скорее всего не могут переделать нормально и всё! находят разнообразные отговорки, даже аж смешно иногда.
я уже и сам начал сомневатся, что 1с + sql это зло, и нужно работать с dbf через rdp, переодически ругатся что неудобно работать и парится с принтерами, особенно когда их много


просветите гуру 1С, если есть таковые, а то тоскливо как-то...

Ross, из моего опыта.
Когда я этим занимался, 8-ка только-только появлялась...
Всегда (10+ юзерей) 1С ставилась на отдельный сервак, который обслуживал только 1С. Максимум еще - файловый сервак для документов.
На него всегда заводили юзеров по RDP. Проблем никаких - вместо explorer.exe у юзеров политиками настраиваем запуск 1С, все ненужное - закрываем.
Делов на час.
Плюсов масса - скорость, удобство проведения maintenance на базах, и прочее...
С выходом восьмерки все стало немного не так, т.к. SQL версия восьмерки стала гораздо аккуратнее обращаться с сетевым траффиком. Что позволяет забыть про RDP путем недолгого курения мануалов и перехода на SQL.
Что очень не любят делать 1С-ники  - лень им разбираться, как я понимаю

ps. Мне как раз наоборот, удобнее было, когда рабочие сессии юзеров на сервере - админить весь софт проще. Естественно, в случае, когда на серваке весь рабочий софт, а не только RDP для 1С.
Про лицензии в те времена никто и не заикался

У Вас 8-ка не на SQL? Как она вообще работает?
Шутка  
Там вообще-то с переходом на SQL вообще не должно быть проблем. Я 1С-ник и всегда агетировал за SQL. Вот только там есть приколы с самим SQLем, для того, что бы он сам шустро и правильно работал, там нужно что бы были определенные размеры кластера и еще куча каких-то настроек, с которыми у мну ну вообще никакого желания разбираться небыло. Поэтому, если нужно просто поставить SQL и перевести на него 1С, то можем вместе сесть и поколдовать, времени это много занять не должно. Если все получится, то с Вас пиво  

На мой взгляд актуальнее выделеный сервер под 1С и необязательно dbf - наоборот скорее SQL и все равно терминал для работающих в 1С, как в головном офисе - так и на удалении в филиалах по VPN каналам, с вторичным доменконтроллером в удаленном офисе.

Живой пример - сейчас подымаю такую сетку.

При базе в формате dbf использую только терминалы.
Когда была семёрка - использовал SQL.

Есть сеть на вайфай и 8-ка, терминалами реально решил проблему сетевой нагрузки, хотя мне все обещали что "всё умрёть".
Но вот вопрос лицензий я пока не поднимал

Да, кстати, почему-то 1С-ники под 8-ку мне попадаются не ахти, SQL  они не любят. Я подозреваю что просто не умеют.

Added after 3 minutes:

я к чему...
без терминала по-любому не жизнь

А удалённо как работать? У меня человек с ноута в Зимбабве без проблем видит все базы, данные и т.д. через терминал + впн.

да, да, да и ещё раз да
терминальный доступ для этого и планировался, или удалённого доступа к рабочему столу или для тонких клиентов, но ни как не для облегчения жизни работы 1С.
Кстати потому и цена терминальной лицензии 80 баксов, так как изначально терминальный доступ расчитан на тонких клиентов у которых есть только мыш и клава.

так, что с удалённым доступом из Зимбабве всё ясно, но нафига мне парится с терминальным доступов если все бухгалтера и операционисты работают локально?

Added after 48 minutes:



для базы до 4гиг игратся с кластерами нет смысла

по поводу перерноса 1С, я как бы и сам не глупый и покурив вечерок мануал смогу и сам перенести на SQL, для меня не понятно другое, почему это не делают люди, которым по сути платят за это деньги? и почему продавая 1С 8 сразу не предлагают купить SQL версию и поставить на шаровой SQL Express? при том заведомо зная, что через какое-то время она будет тормозить

если кратко:
8.Х - SQL (если пользователей много то разнести сервер приложений и сервер БД на разные машины)
7.7 - RDP

работает около 300 пользователей полет нормальный

Потому что другие люди недостаточно твердо этого требуют Напрягайте 1С-ников, пусть деньги отрабатывают. Если это профессионал, то он сам предложит SQL. Если нет - см пункт 1.

Ross,
Если в 2ух словах про 7,8 и DBF и SQL:
7ка с ДБФом изначально была расчитана на ДБФ. С SQL она то работает, но запросы к SQL базе она формирует не оптимально (много не нужный подключений, гребет кучу "лишних" данных и потом их обрабатывает на клиентской машине, загружая эту машину). По этому даже в SQL  варианте быстродействие будет выше при работы на через RDP.

С 8кой , точнее с 8.1, всё по другому. Она изначально рассчитана на работу в клиент-серверном варианте. На сервер ставится "1С Сервер предприятия". Клиенты "шлют" запросы на "1С сервер предприятия", он в свою очередь "обращается" к SQL серверу, получает от него данные, ОБРАБАТЫВАЕТ! эти данные и клиенту выдает готовый результат. Работает действительно оптимально и лишних данные не гоняет (в отличии от 7ки), клиентские компы без необходимости не грузит. Работает кстати не только с MS SQL но и с шаровым Postgre SQL (там есть нюансы, но в целом работает) и теоретически даже на Линухе работает с Postgre SQL.

Так вот при варианте работы 1С 8 с Сервером предприятия
вполне можно работать на локальных компах, при этом разница по сравнению с RDP будет не особо заметна. Это если грубо взять, опять же есть свои нюансы на "больших" базах или на местах где оперируют большими объемами данных (например отчет по продажам за пару лет с детальной аналитикой).

Если єто 8ка, я советовал бы 1С Сервер предприятия + MS SQL (хотя Postgre SQL совсем отбрасывать не стоит). Если быстродействия не будет хватать, то нужно анализировать узкие места и искать пути их решения (где-то комп мощнее поставить, где-то канал расширить, где-то на сервер памяти добавить и под это дело поднастроить SQL сервер , какого-то аналитика таки через RDP подключить  и т.д.). В любом случае если такой вариант будет "тормозить" то файловый вариант 1С 8ки даже при работе через RDP будет тормозить больше, причем возможно существеннее.

По чему 1Сники не шевелятся вопрос риторический - тут как многие у нас в стране во многих отраслях.

Ещё важный момент лицензия 1С на использование сервера предприятия стоит 7,440 грн (на x86 12,960). Понятное дело что технически она без проблем ломается. Но это только технически.

ПС Мог бы меня и набрать или Антона.

Added after 8 minutes:



А вы знаете детали договоренностей по обслуживанию 1Сником данного предприятия?
Я бы такие однозначные выводы не делал бы.

А если человеку поставили задачу что бы было быстро, но при этом бюджет на покупку лицензий не выделили и перенастройку режима работы не выделили. Тогда технически вариант повышения быстродействия довольной не плохой - загнать всех в терминал и работать с файловым вариантом. По любому лучше чем так как есть.
Но опять же это технически. Практически он мог бы и предложить, и вести себя более корректней и т.д.
Но разница между "Мог бы"  и "обязан" существенная.

Added after 3 minutes:



А знаешь сколько мне 1Снику невменяемых админов попадается? Ууу... На 9ть проблем из 10ти ответ один "ну надо винду переставить"



Не верно. 1С 8.1 и SQL это может и не добро, но уж точно не зло. Вот 1С 7.7 и SQL там всё печальней, но тем не менее и с этим можно работать.

Мой программер 1С, делающий нам 8-ку подозрительно долго не хочет переходить на SQL. Говорит ему "так труднее будет вносить изменения". Я этого понять не могу.
Сложности с бэкапами, соответственно, из-за незавершенных сессий.

Кстати ищу нового программера 1С. Мои явно не справляются.
Кто к теме и готов работать (никакого официала, договоров и т.д., система деньги-товар, сразу говорю) - велкам.

Нииипааанятнааа..
Технически при редактировании/сохраниении/обновлении конфигурации без разницы в каком формате база. Возможно какие-то другие причины.

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

В восьмерке файл конфигурации хранится в самой базе - бекапить на порядок удобнее, чем 7.7

atMamont,
есть RDP и есть пользователи, которые забывают отключать сеансы.
Обрубить их сеанс принудительно со стороны сервера не проблема. Но остаётся висящим профиль, а в них открыты базы.
Скрипт бэкапа (8-рочный, выгрузка) говорит "нафиг" и ничего не делает.

mpa, висит сессия, в которой висит процесс клиентского 1с ?

mpa, в АД, настройках юзера есть сеансы
там нужно посавить галку "завершение отключенного сеанса" и выставить время тайм аута сколько тебе нужно

Ross, это сделал.
Но почему-то скрипт выгрузки не может получить доступ к базе.
Программист утверждает что есть зависшие сессии.

mpa, если используется Сервер Предприятия (8 истественно), то эти сеансы отрубаются запросто из самого Сервера Предприятия 1С. Если висят сеансы файловой системы, то необходимо грохнуть (под Админом сервера) сам процесс 1С того юзвера.
Поправте если в чем не прав.

stalkerion, как это поддается автоматизации, скажем в три часа ночи ?

Рубить сессию это как бы не корректно. Оно то помогает, но очернь-очень редко но могут быть сбои базы. Это типа как миш и клаву PS/2 на горячую вынимать - оно то работает, но очень-очень маленькая вероятность спалить контроллер всетаки есть и хз окгда оно случится (я лично один контроллер я в своей жизни спалил )

Если уже руюить то более правильным будет через Диспетчер служб терминалов делать завершение сеанса конкретных пользователей.

Я вообще если база в вайловом варианте - то тупо делаем копию каталога базы не смотря на висячих пользователей. Это и будет бекап. Можно настроить архиватор или какую-то другую софтину для делания этого автоматом и расположения в нужной папке.

mpa, это варианты критические, и варианты рубить процесс юзвера опять-же в критических моментах (например зависшего юзвера в 3 часа ночи). Данный процесс достигнуть автоматизации теоретически возможно, как сказал  Romich, "через Диспетчер служб терминалов".
Если использовать СКуЛ, то боли головной меньше. ИМХО

mpa,


Скриптом. Командной строкой - она умеет очень много гитик
+1 за автомаптический бекап DBF базы - ни разу проблем не было.

У меня работало не нескольких сетях. В 01:00 подымается скрипт. Рубим все сеансы, ребут. В 1:15 - запуск скрипта бекапа.
За, в среднем, 4 года - тьфу-тьфу-тьфу, ни одной проблемы не вызвало.
На самой большой сети делал бекап два раза - в 12:30 (обед) и ночью. Бухгалтера привыкали к перекуру в 10 минут неделю, после чего вопросы пропали.

_dem, я не привык для бекапа делать ребут

mpa, я когда-то тоже не привыкши был. Любил, знаете ли, вечерами медитировать на "online : 1024 hours", или отмечать рубеж в "полгода онлайн" с админом из соседней конторы

Но это не роутер, этому - можно.

Насчет тупого бекапинья каталога базы 8ки я вполне серьезно. Там даже не папка, а 1ин файл. Копируем базу с подключенными пользователями хоть несколько раз в день. Потом без проблем её можем скопировать обратно и пользоваться.

Как по мне оптимальное решение если без Сиквела.

ПС а размер базы хоть какой?


_dem, ребут это совсем жестко.. я б не рискнул такое на автомат поставить.

Romich, аргументы против ?