FAQ по мотивам Территории 1С

По мотивам форума Территория 1С

1) Вопрос

Общий заголовок: Какой релиз лучше.

А чем отличаются 15 и 17 релизы для SQL?
Кто знает, лучше ли работает с SQL-ем 17 релиз, чем 14?
Сейчас имеется 12 релиз. Стоит ли переходить на 14-й (под SQL) или 15-й? Если да, то почему.
Кто-нибудь уже перешел на 16 релиз для SQL ? Исправлены ли старые глюки и замечены ли новые ?

Ответ

Я сам использую 15, о глюках с 17 при работе с SQL много пишут в архиве.

Разница заключается в том, что 15 релиз работает, а 16 и 17 нет. По крайней мере оперативный учет.

У меня отчет о прибыльности товаров почти типовая Т+С в SQL после установки 17 стал вырубать программу. С 15 работает. Других внешних отличий пока не заметил, но глубоко пока и не копал.

http://www.hare.ru/cgi-bin/wwb.pl?id=1&p=3&t=25&m=3

В 12 у меня был глюк с ЗиК — сошибкой вываливалась Налоговая карточка. Поменял на 15 — все покатило, как бы само. В 15 — сильно мешался глюк в отладчике — с точками останова. То он их видел, то нет... Посему я сейчас на 17. Вроде жить не мешает.

Далее о 16 релизе:

Могу и поделиться:
"SQL State 4200
 Native 170
 Message [...] Line2 Incorrect syntax near 'RA2987'"
И это на запросе, работающем на 15 билде. Выборка из регистра с группировкой по документу.
Меняются люди, меняется время... 1С не меняется :)

Ну что я выяснил,— что отъехали все запросы с группировкой по документу по оборотным регистрам. Так что релиз явно не рабочий, там где используются такие запросы.

2) Вопрос

Общий заголовок: Для работы с SQL Server 2000 нужен релиз не ниже 15

Есть промблемка: Установлено W2K Rus + SQL Server 2000, 14 релиз 1C для SQL. При попытке подключиться в Конфигураторе (как на серевере так и на станциях) выдается сообщение "Для доступа к базе данных требуется ODBC-драйвер для MS SQL Server версии 3.50.0303 или старше", но в системе при инсталяции SQL Server установлен ODBC 03.80.0194. Кто сталкивался подскажите !?

Как это было:
   грохнулся SQL7.0 + sp1
   поставил SQL 2000
Итого:
   На машинах с W2k 1С — работает..Зато на остальных (winNT):" необходим MS SQL server v 6.5 + sp 5"
Кошмар... Что делать-то =((

Ответ

Поставить релиз 1С не ниже 15

3) Вопрос

Общий заголовок: Возможно ли настроить репликацию базы 1С средствами SQL Server

Проблемка:
1С: Торговля стоит на SQL Server. Два вида клиентов: Торговые залы и Передвижные торговые точки. Для передвижных точек требуется репликация продаж на сервер, а назат приходы. Какой метод репликации сработает: метод репликации транзакций или метод слияния?

Посоветуйте как сделать сабж, а то после создания публикации БД 1С не хочет открывать эту БД ни под каким видом...

Как проще среплицировать 2 SQL Server W2K? Какой способ лучше выбрать? Задача: корпортивный клиент, 3 филиала в каждом SQL Server 7.0 и SQL 2000 + 1С Предприятие 7,7 необходимо их реплицировать для получений консолидированных данных в филиалах ежедневно.

Помогите выбрать. Использовал ли кто репликации по запросу MS SQL для связывания центра и удаленных филиалов или нужно выбрать УРБД или что то подобное.

Ответ

Репликация базы 1С средствами SQL Server не работает. При этом нарушается структура таблиц, а также базу невозможно открыть в монопольном режиме. Обмен данными лучше настраивать либо собственными обработками, либо через УРБД или МОД.

4) Вопрос

Возможно ли вместо СУБД MS SQL Server использовать другие, например, Oracle, mySQL, Interbase

Ответ

Нет. Из сереверов подобного типа 1С может работать только с MS SQL Server. Причем разные версии, релизы 1С могут работать только с определенными версиями, сервиспаками SQL сервера. А нормально работать только с определенными версиями ODBC драйверов.

Версия 1С 7.5 работает с SQL Server версии 6.5 SP не ниже 5а или SQL Server 7.0 SP не ниже 1. Версия 1С 7.7 работает с SQL Server версии 6.5 SP не ниже 5а или SQL Server 7.0 SP не ниже 1. Начиная с 15 релиза 1С 7.7 работает с SQL Server 2000. Для работы с SQL Server 7.0 лучше использовать SP3 (иногда лучше SP2). Драйвера ODBC лучше использовать либо поставляемые с SQL Server, либо из поставки 1С.

4) Вопрос

Общий заголовок: "Когда лучше использовать SQL версию 1С или что лучше dbf или SQL"

а) Собираемся внедрять 1С Торговлю и склад. Количество ползователей 15. Примерно 200 документов в день на всех. В каждом документе примерно по 20 позиций. Какая версия предпочтительней в данном случае с точки зрения устойчивости, скорости и стоимости владения? Не хотелось бы потом коней на переправе менять. Насколько фатально зависание одной машины в DBF базе? Насколько будет меняться скорость работы в зависимости от количества пользователей?

б) У клиента 50 рабочих мест. Количество выписываемых документов в день — 400. Само-собой много всякого рода справочников, отчетов, журналов. Кроме того, есть куча всяких журналов, отчетов и справочной информации. Потянет ли все это платформа 1С SQL? Хотелось бы увидеть примеры из жизни. Есть ли у кого такого рода клиенты? Какая у них техника стоит?

в) Ув. коллеги. Проблема предельно проста — бухи жалуются на низкую скорость работы = 1С 7.70.014 (сетевая версия), три пользователя, незагруженный НТ сервер и нормальное железо. SQL версию 1С я в глаза не видел. Увеличится ли реально скорость работы при переходе на SQL версию, я так понимаю, что на рабочие станции передается только "копия экрана". Для сравнения, есть такой софт — RS-BANK, так он дал выигрыш в 10-15 раз. Заранее благодарен (играться просто некогда, я один, без ансамбля).

Ответ

а) SQL предпочтительна. На таком количестве пользователей может быть выигрыш в скорости и не проявится. Но самое главное это устойчивость. У нас при таком количестве пользователей и DBF-базе несколько раз в неделю приходилось посреди дня изгонять людей из базы и переиндексировать, а после этого еще долго звон в ушах стоит. Сейчас SQL юзеров порядка 50 и система спокойно переживает скачки напряжения с отваливанием всех клиентов. Был случай, когда случайно выключили сервер и всё ОК. В DBF отваливание одного - другого, третьего клиента вызывало необходимость переиндексации.

Считается что dbf способна жить с базой до 1Гб, выше,— производительность падает. Учти, что файл-сервер предъявляет требования к сети и к рабочим станциям, в то время как сиквел — только (в основном) к серваку.

У каждой платформы - свое предназначение. Например, с типовой конфигурацией ТиС 8.Х на DBF больше 5 юзверей просто погибают от тормозов, при условии, что непрерывно лупят документы. Правда, если 200 доков равномерно распределены по времени, то выживут и 10-15. Но если железо и квалификация позволяют, то ИМХО, предпочтительнее SQL.

Альтернатива SQL — терминальный доступ... можете хоть с 386-й работать и отваливание пользователя безболезненно и для юзера и для окружающих...

15 пользователей - однозначно SQL. Стабильнее, надежнее. "Навороты" — это же только плюс. Хочешь — применяй, хочешь — нет. Нравится TSE — ставь его в связке с SQL. Хочешь работай так-хочешь по другому. Сырость - есть такое. Но сырость не критичная. Если контора оформляет 200 доков — деньги на SQL уже найдутся.

Третий год работы с 1С под SQL. Полет нормальный. До этого семилетний опыт работы с MS SQL и десятилетний опыт работы с самыми разными базами данных. Заявляю: при прочих равных политических и технических услових эксплуатации 1С не вижу сколь либо серьезных преимуществ работы с DBF взамен SQL. Обратных преимуществ вижу много-много десятков. Лично я перехожу на SQL версию начиная с четвертого-пятого компьютера в сети. Ни разу об этом не пожалел.

Реальный пример — загрузка базы данных из "выгрузки" (27 метров ZIP~a) в дбф (комп P3-700/256mb винт ATA100) — ~ около 40 часов. Загрузка в SQL того-же самого (комп P2-350/192mb винт скази — старый (второй что-ли)) ~5 часов. Тест 2 удаление из базы ~20000 документов - 1-й ~18 — часов, 2-й около 6-ти
PS: обьём базы в SQL — 2.2 гига.

ИМНО нужно пробовать (если есть возможность) в конкретной ситуации. Знавал базу под ДБФ более 1 Гб с более 10 юзверями, переиндексировали раз в день, утром. Перевели под SQL выигрыша по времени не получили (ничего хорошего не получили ;) надежность!? и так было нормально. Так и оставили! А еще одну базу знаю. Живет под SQL (приближается к 1Гб), работают 5-6 человеков. При выгрузке в ДБФ (для конфигурирования, тренировки и т.п.) замечено, что отчеты формируются в разы быстрее. Но в большинстве случаев SQL помогает. Мое соотношение где-то 15% к 85% (из опыта ИМНО). Вот только с ЗиК никак не определюсь, советовать клиентам или нет? Зик +SQL?

б) Лучше все делать не в одной информационной базе, а в нескольких связанных.
Например: Нижний уровень — Производство
          Средний уровень — Сбыт
          Верхний уровень — Бухгалтерия.
Остается настроить передачу данных. Еще можно поэкспериментировать с репликацией (для получения отчетов из зеркальной базы). Я лично делал систему, где работали 10 операторов, и все работало. Сейчас делаю более крутую, где будет порядка 40 пользователей, из них 15-20 активных. Пока скорость удовлетворительная. Но: все отчеты и все запросы к регистрам по проведению я делаю только прямыми запросами на Rainbow.

На 25 пользователей не надо ни двух баз, ни OLAP (если не нужна статистика, анализ и пр.), ни репликация. Все живет совершенно нормально на PIII-600, 512ОЗУ, RAID-5, 100мб сеть. Правда без бухгалтерии и с приличными ресурсами клиентских машин. Любые разделенные базы - повод для гемороя. Сихронизировать их в реальном режиме практически невозможно. Доводы о том, что оперативность не нужна не состоятельны для управленческого учета.

Я рекомендую установить MSSQL7.0 на базе Windows NT 4.0. Интеловские платформы а-ля STL2 с двумя процессорами 750-800 P3 256-512 мозгов. Стековый хаб-свитч с несколькими портами с поддержкой транка на 1Гб к серверу. На сервер несколько гигабитных карт — 2 будет достаточно. Хаб тоже интеловый можно взять. Подробности по проекту на почту. TSE тоже может пойти — но не оптимально — всетаки 50 мест. Скорее даже не пойдет.

Многое завистит и от самой конфигурации, точнее от ее оптимизированности (например понятно, что в данной ситуации типовая комплексная работать просто не будет). С первой частью согласен (MS SQL 7), а вторая просто вызывает недоумение: ИМХО если контора серьезно собралась автоматизировать 50 мест, то одним сервером здесь не обойтись — 1 под SQL и 1-2 под ферму Сitrix TSE ...

в) Ты перепутал божий дар с яичницей. "Копия экрана" — это TSE. SQL — это из другой оперы, при которой никакой пользы не получишь. На трех пользователях, естественно.

Народ! Вы хотите сказать, что 3 (!) места могут так нагрузить? Не верю! Какая база? Объем? Сколько документов вбивают в день? Посчитать легко - нумерация имеется... Блин. Сейчас обработку напишу чтоб статистику давала...

SQL дает прирост по скорости это однозначно (если правильно настроен)!!! Я сравнивал 1С Однопольз ДБФ против 1С+SQL на базе около 700 мегов. У ДБФ быстрее идет запись на диск, у SQL быстрее рассчитываются итоги (в нескольок раз). Кроме этого переиндексация и пересчет итогов в ДБФ это просто головная боль.

На трех юзверях, при условии отсутствия роста количества оных, поставь TSE 4.0.
Преймущества:
 — загрузишь ресурсы сервера;
 — скорость будет конкретная (при условии достаточности ресурсов железа);
 — бухи больше доставать не будут;
 — будет время на поиграться (я не про игры);

Однозначно. СКЛ для этого — как из пушки по ма-а-а-леньким таким комарикам.

 наверх