Нужна помощь, ни разу не делал, с чего начать и т.д., по пунктам плс.

Что ты имеешь ввиду под своим вопросом?
Может быть, перевод *DBF на SQL?
Если я отгадал, то зачитываю по пунктам.

1. Заходишь конфигуратором в желаемую базу и в меню "Администрирование" выбираешь "Выгрузить данные". 1С высосет все данные из многочисленных *.dbf файлов и запихнёт их в zip-архив вместе с основными файлами конфигурации.
2. Устанавливаешь какой-нибудь sql-сервер типа "MS SQL Server 2000". Обычно на тот же компьютер, где у тебя будет лежать шара с конфигурацией, но теоретически можно и на другой.
3. Заходишь в оснастку "Enterprise Manager" и в папке "Databases" создаёшь новую базу данных.
4. Если хочешь, чтобы юзеры юзали базу по старому адресу, тогда перемещаешь текущее содержимое шары в какое-нибудь безопасное место. То есть, если юзеры лезли по UNC \\Server\database, то освободи полностью этот каталог.
5. Опять в режиме конфигуратора пытайся открыть этот каталог. Поскольку он пустой, 1С спросит тебя -- какой формат хранения данных следует использовать: DBF или SQL? Смело отвечай ему "SQL" и загружайся дальше.
6. Когда загрузишься заходи опять в "Администрирование", пункт меню "Параметры базы данных SQL" и укажи ему желаемые 4 параметра. "Сервер" -- по умолчанию имя текущего компьютера (если при инсталляции эскуэля ты ничего не трогал); "База данных" -- это уже смотри, как ты её сам назвал; "Пользователь" -- по умолчанию в MS-SQL существует один пользователь: "sa"; "Пароль" -- по умолчанию пароль у sa пустой, но из соображений безопасности его лучше назначить. После ввода данных и подтверждения окно должно закрыться; если 1С или SQL выдадут ошибку -- значит где-то ты накосячил с данными. Тем не менее 1С предложит тебе сохранить параметры базы данных "не смотря ни на что". Не соглашайся! Лучше подправь данные ещё раз и введи заново.
Будь внимателен -- во время соединения с базой данных сервисы "MS SQL Server" и "MS SQL Server Agent" должны быть запущены, о чём свидетельствует соответствующий значёк в трее с зелёным треугольником.
7. После того, как ты указал ГДЕ будет храниться база данных, можешь выгружать данные: в меню "Администрирование" выбираешь "Загрузить данные" и скармливаешь ранее заготовленный zip-архив.
8. Можешь юзать.

И ещё пара моментов. В принципе SQL нормально работает по умолчанию, но есть некоторые тонкости.
1. Пароль для sa, как я уже говорил, лучше назначить.
2. В кач-ве протоколов передачи данных SQL использует "TCP/IP" и "named pipes". Говорят, что некоторые маньяки из соображений безопасности отключают второй (хотя я этого делать не стал).
3. Базу данных периодически надо шринкать, иначе какая-нибудь двухсот метровая база рискует разрастись до нескольких гигов.
4. Ну и самое главное -- теперь придётся изменить схему резервного копирования, ибо простого архивирования каталога будет недостаточно. Сделать это можно средствами 1С, можно отдельно средствами самого SQL, можно использовать агента для Веритаса.

Ещё вопросы?

Да вот ещё сам вопрос (почти) в тему задам, дабы топиков не плодить: кто-нибуь ставил 1C на Мускуле под *никсом?
По идее язык sql-запросов стандартизован, значит должно работать... но как оно на практике себя поведёт...

Нужна помощь, ни разу не делал,
---------

можно вопрос?
зачем Вам это надо ?
скорость работы базы не увеличится... да еще дополнительный софт надо ставить (MS SQL сервер) и т.д...

Нельзя сказать однозначно -- будет ли оно быстрее или медленнее.

1С на DBF работает в качестве тупого файл сервера. Это значит: чтобы обработать большую таблицу, клиентская часть ПОЛНОСТЬЮ скачает эту таблицу с сервера, а потом уже будет делать запрос. SQL всё же изначально ориентирован на архитектуру клиент-сервер, засим выборка будет происходить на стороне сервера (что разгрузит клиента), а перекачиваться будут только нужные данные (что разгрузит сеть).
Впрочем, если в сети честная "сотка", компов меньше 10-15 штук (а железо в них на уровне 4-го пня), то ИМХО разницы в производительности опять таки не будет.

С другой стороны -- если компы на уровне 2-го пня, то установка на одного из них ещё и эскуэля только замедлит работу.

to Дохтур:
Ещё один пункт: удостоверься, что твоя версия 1С поддерживает SQL. Если это так, то самый главный бинарник (с которого запускается 1С) называется "1Cv7s.exe".
Если у тебя "1Cv7.exe", то об эскуэле временно забудь (пока не найдёшь другую версию).

Базы стоят на серваке в шаре, версия оболочек 1С for SQL v.21, просто когда 15 юзеров в ней работают, тормозит ужасно.......

Нельзя сказать однозначно -- будет ли оно быстрее или медленнее.
---------

можно сказать однозначно - НЕ БУДЕТ БЫСТРЕЕ
по определению..аксиома, так сказать
SQL в 1С седьмой серии используется для повышения уровня защищенности данных от потери... тем более, сэр, Вы должны знать, что у 1с семерки нет прямого доступа к базе... и всё делается на уровне запросов к SQL серверу...что никак не ускоряет работу всей системы

Есть какие-нибудь мысли, как убрать тормоза?

Microsoft Terminal Services
Citrix MetaFrame

Юзеров и сеть это разгрузит по самое нехочу -- хоть по диалапу на сотом пеньке работай (проверено)... но помни -- для этого тебе потребуется НЕХИЛЫЙ сервер.

>> можно сказать однозначно...
А вы ПРОБОВАЛИ? Пробовали пересаживать людей с SQL на DBF или обратно? Вот я сразу скажу -- не делал ни того, ни другого, поэтому не утверждаю ничего на 100%.

>> Вы должны знать, что у 1с семерки нет прямого доступа к базе...
Гыыы... вы имеете ввиду к файлам *.MDF и *.LDF??? ЕСТЕСССТВЕННО НЕТ! Да разве же SQL-сервер допустит кого-нибудь до них? Он их даже на чтение со стороны других приложений блокирует (уж это я знаю точно).

>> ...и всё делается на уровне запросов к SQL серверу
Вот это я и имел ввиду, когда говорил о клиент-серверной архитектуре. Так работает ЛЮБОЕ приложение ориентированное на SQL, ибо он для того и существует, чтобы обрабатывать запросы.

>> ...что никак не ускоряет работу всей системы
Поскольку (как я уже сказал выше) работа по выборке делается на стороне сервера, и по сети качаются только ПОЛЕЗНЫЕ данные -- ТЕОРЕТИЧЕСКИ скорость должна повыситься (опять таки при хорошем сервере).

Теории достаточно. Если у вас есть ещё какие-либо практические замечания -- всегда рад их выслушать.

to Дохтур:
А ты всё же попробуй SQL поставить -- ничего ведь не теряешь (если всё сделаешь правильно). Расскажешь нам потом с высоты своего нового опыта об изменениях в производительности.

> можно сказать однозначно - НЕ БУДЕТ БЫСТРЕЕ
по определению..аксиома, так сказать

Позвольте, а это относится только к 1С, или к "SQL против DBF" вообще?

7 января займусь........., потом поделюсь опытом.....
Всем

А много таких приложений существует ещё?
(которые работают и на SQL и на DBF)

to Дохтур:
Будем ждать...

такая же проблема.
жду окончания опыта

Позвольте, а это относится только к 1С,
---------
Это только к 1С

Есть какие-нибудь мысли, как убрать тормоза?
-------

1.апгрейд дисковой подсистемы,
2.терминальный режим работы юзеров
3.апгрейд сетевого оборудования

Поделюсь своим опытом
Как было сказано выше есть два варианта
1)Перевод на SQL
2)Перевод на ТС
оба варианта требуют покупки мощного сервера
SQL - не ускорит работу конкретного пользователя( даже в случае если монопольно запустить 1с по сети, то дбф версия будет шустрее чем SQL), но если взять общую производительность то она увеличиться.

ТS- плох тем что существуют ограничения на размер дбф-ной базы, при размерах базы >1-2 ГБ регулярно будут сыпаться индексы.

Я считаю что при небольшом размере базы < 1 Гб и большом кол-ве пользователей предпочтительней TS, если же размер базы большой, то одназночно SQL. Есть еще вариант TS+SQL, но я бы не стал работать там где необходима такая связка.

>> SQL не ускорит работу конкретного пользователя, но
>> если взять общую производительность то она увеличиться.
Интересно -- а разве общая производительность складывается не из скоростей конкретных пользователей?
Как это -- у всех стало быстрее, а у каждого стало медленнее? Поясните, если не затруднит.

>> Есть еще вариант TS+SQL, но я бы не стал
>> работать там где необходима такая связка.
Почему? Я же работаю.

Неужто при объемах > 1 GB, да по сети DBF выигрывает?

Исходя из личного опыта, на мой взгляд если база менее 1.5 Гб, то идеальнейшей связкой является 1С + Citrix Metaframe (у меня стоит 1.8).
Пробовал переходить на SQL но как оказалость, скорость только упала, сразу оговорюсь, всея сетка 100 Мбит, на серваке стоит 1Гбит.
Так что в моем случае эксперемент полностью провалился, я уже молчу о том, что говорили бухгалтера:)
Мож кому поможет, скажу как повысил скорость работы 1С. Два сервака соединеных по 1Гбит+Load balansing (опять же через Citrix) Теперь все просто летает:)
Опятьже на мой взгляд, переход на SQL необходим если число пользователей работающих В ОДНОЙ БАЗЕ болше 12-15 человек иначе как извесно DBF-ки сыпятся.

если число пользователей работающих В ОДНОЙ БАЗЕ болше 12-15 человек иначе как извесно DBF-ки сыпятся.
-------------

здесь я не согласен... DBF ки сыпятся(точнее - могут посыпаться) когда обрабатывается большой объем информации а не сидение большого количества народа в базе... например расчет зар.платы на 1000 человек и больше

Опять же и в терминале скорость хорошая... если правильно подобрано и сконфигурировано серверное и сетевое "железо"

Тогда уж не 2 а 3 сервера. На 2 серверах стоит собственно 1С, а базы лежат на третьем. тогде действительно Load balansing работает на ура + всегда можно легко добавить третий и четвертый сервер, если первые два не справляются с пользователями.
По крайней мере у нас такая система работает.

А 1 - 1.5 Гиг - достаточно большой объем? По идее (с 1С я не слишком знаком) DBF при таких объемах должна уже отдыхать.

Если база данных стоит на отдельном от 1С сервере, то тогда я так понимаю что теряются преимущества DBF - все данные приходится гонять через сеть. Вариант DBF + Citrix означает, что на сервере работает "эквивалент" SQL Servera, написанный в 1C.
Если DBF базу и клиента начать разводить по разным машинам, даже при "честных" 100Mbit, то тормоза будут гораздо сильнее, чем в случае SQL сервера.

Забыл уточнить что у нас 1С на SQL-е и между серверами гигабит.
Просто в случае, если человек хочет пользовать Load balansing, то просто необходимо разделить сервера, которые будут заниматся обработкой приложения (сервер приложений) и хранилище баз данных.
Если пользовать систему с распеделением нагрузки и база даннх будет лежать на одном из сервером, то быстро работать будет только у тех, кто будет логинится на сервер, на котором собственно и лежат файлы базы, а человек, залогиненый на втором сервере будет уже работать с этой базой по сети (иначе как сделать так, чтобы пользователи работали в одной базе?). А куда залогинется очередной пользователь, который будет запускать опубликованое приложение будет определять как раз Load balansing в зависимости от многих параметров.
Далее, если пользовать схему только из двух серверов (на одном 1С + база, на другом просто 1С) - то в случае выхода из строя сервера с базой - от второго сервера толку будет никакого.
Для случая 2 сервера приложений + сервер данных выход из строя однго из серверов приложений позволит спокойно работать дальше. Конечно, если накроется сервер баз данных, то будет очень грустно, но на этом сервере резервируется все, что можно (не резервируется только мать, но мы и это обошли)

Я конечно согласен, что 3 сервака гораздо лучше чем 2, но когда денег не дают, и в тоже время требуют "чтоб все работало причем еще вчера и быстро", то приходится изголяться:)
Кстати, я как-то краем уха слышал про такую связку 1С+Радуга(Rainbow)+SQL причем человек клялся что скорость работы возрастает в десятки раз!! Правдо головняков при создании такой связки тоже не мало.
Просвятите если кто знает че это за зверь??

>> Пробовал переходить на SQL но ... скорость только упала,
>> сразу оговорюсь, всея сетка 100 Мбит, на серваке стоит 1Гбит.
Гыыы. Попробую отгадать. А ты случайно не на ОДИН и тот же сервак пробовал поставить MetaFrame и SQL?... Я тоже как-то экспериментировал с этим делом... Скоросто упала ТАК СИЛЬНО, что все просто взвыли дружным хором. В общем, я сделал вывод, что у SQL и MetaFrame страшная половая несовместимость и ставить их на одну тачилу -- самоубийство... Даже работа ОДНОГО человека в MF тормозила работу ВСЕХ остальных, кто обращался к серваку напрямую.
Решилось абсолютно аналогично: один сервак отвёл чисто под хранение данных в SQL, другой сделал чисто терминальным, ну и 1ГБит-ный канал между ними (без Load Balancing).

>> переход на SQL необходим если число...
В общем, у нас размер баз от 0.5 до 3-4 гигов и народу человек 30 -- так что считаю использование SQL абсолютно оправданным.

ЗЫ. А где же Дохтур, который обещал после 7-го числа поделиться опытом? :о

Неее, я пробовал на другом серваке, который собственно щас учасвует как второй в Load balansing, потому как тоже доходили слухи про половую несовместимость, так что для читоты эксперемента даже пробовать не стал....

Даже работа ОДНОГО человека в MF тормозила работу ВСЕХ остальных, кто обращался к серваку напрямую.

Значит что-то не ладно у тебя в консерватории.Есть у нас сервера из разряда "все-в-одном". И терминальный сервер и SQL и 1C. И до 10 одновременных пользователей. И не тормозит. Так шта-а-а-а...

Всё ладно в моей консерватории.

>> И до 10 одновременных пользователей. И не тормозит.
Так до десяти, а не до тридцати! К тому же, будьте любезны, озвучте конфигурацию сервака.

Если ты слышал только краем уха и тебе особо оно не надо то разговор займет много времени :). Так же кроме проекта Rainbow стоит упомянуть 1С++, 2С. Плюс есть любители ( хотя почему любители, скорее профессионалы) переводить базу на прямые запросы.

P.S. База DBF размером более 1 гб не загибается а живет счатсливо и весело. SQL версия не даст выигрыша в скорости проведения документов, но вот выигрыш в скорости формирования отчетов она скорее всего даст, и причем достаточно существенную. А если еще посидеть над настройкой SQL сервера как это делал памятный МУ-МУ с Территории 1С, то результат вполне даже ничего.

P.P.S. Большой прирост скорости как правило дает банальная оптимизация кода. Но тут большие риски.