Перевод dbf в SQL.

База данных 1с предприятия хранится в dbf фаилах.<br><br>Хочется перевести ее в SQL, как это сделать? что для этого нужно?<br><br>Если можно попобробнее.<br><br>И как потом заставить 1с конектится к этой базе?

Вообще то все написано в Руководстве по установке и запуску SQL-версии.

1. Установить на сервер MSSQL. Для MSSQL7 обязательно нужен SP — например, SP1, а лучше SP3. Без этого 1С:Предприятие просто НЕ будет работать. <br><br>2. Установить на рабочую станцию драйвера ODBC из поставки 1C или ODBC-клиента от Microsoft (он зовется MDAC). <br><br> sic! Если Вы планируете использовать на одной машине SQL-базы и 7.50 и 7.70, устанавливайте ODBC-драйвера из поставки 7.50. Это важно — если установить ODBC из поставки 7.70, базы 7.50 перестанут открываться. Простая переустановка старой версии ODBC поверх новой не поможет — предварительно нужно руками удалить из Windows\System\ файлы Odbcbcp.dll и Sqlsrv32.dll.<br><br>В случае с MDAC эти шаманские действа смысла не имеют, но и базы 7.50 запросто могут не работать.<br><br>3. Установить на рабочую станцию собственно SQL-версию 1С:Предприятия, ее исполняемый файл, в отличие от сетевой версии, назвается 1Cv7s.exe. <br><br>4. Открыть SQL Enterprise Manager и создать новую базу данных. Если непонятно, как это делать — почитайте хелп, он там весьма развесистый. Размер БД выбирается из следующих соображений: данные в sql-базе займут места раза в 2-2.5 больше, чем весит dbf-база, и как минимум 20% пространства sql-базы должно остаться свободным. Размер лога также играет роль — если планируется перенос данных из dbf-версии, следует иметь лог ~25% от размера sql-базы. Можно сразу же установить для базы режим Truncate log on checkpoint, это поможет избежать проблем с переполнением лога и немного повысит производительность, но лишит возможности в случае аварии БД сделать откат на момент “за пять минут до сбоя”. <br><br>5. Подготовить данные dbf-версии к переносу — если он планируется. Это делается с помощью операции “Выгрузить данные”, которая не просто запаковывает таблицы, а переводит информацию в хитрый формат и кладет в файл с расширением *.dat. <br><br>6. Создать пустую директорию для хранения конфигурации sql-базы. <br><br>sic! Она не должна совпадать с директорией, где хранятся файлы собственно sql-базы, последние вообще желательно сделать недоступными для пользователей.<br><br>7. Открыть Конфигуратор, зарегистрировать новую базу данных (та самая пустая директория) и на вопрос о типе БД ответить “SQL server”. <br><br>Выставить в конфигураторе “Параметры базы данных sql...” — это сетевое имя 8. сервера, имя базы данных, как оно было задано в Enterprise Manager, имя пользователя и пароль для доступа к данным через ODBC (встроенная в MSSQL учетная записть администратора имеет логин sa и пустой пароль). <br><br>9. Загрузить данные в БД. Если Вам нужна пустая конфигурация, это делается с помощью процедуры “Загрузить измененную конфигурацию”, если данные переносятся из dbf-версии — “Загрузить данные”, конфигурация при этом загрузится автоматически. <br><br>10. Можно работать с БД. Не забывайте время от времени архивировать и индексировать свою sql-базу — архивация средствами sql, в отличие от файл-серверной версии, не требует монопольного доступа к базе и может осуществлятся прямо во время работы. Индексация и проверка целостности БД производится последовательным запуском двух TSQL-скриптов, очень простых: <br><br>dbcc checkdb — проверка БД<br><br>exec _1sp_dbreindex — индексация.<br><br>Индексация требует монопольного доступа к данным, поэтому не пытайтесь в это время работать. И архивирование, и индексацию можно (и нужно) повесить на автоматическое исполнение и делать “по будильнику”. <br><br>