В одной из статей нашего сайта уже рассматривался вопрос о том , каким образом можно отконвертировать ваши данные из MS Access в базу MS SQL Server. Если учитывать то обстоятельство , что формат баз данных DBF также был весьма популярен в своё время , то информация об аналогичной конвертации из dbf в MS SQL может оказаться весьма востребованной. Один из способов такой конвертации данных предлагается с использованием утилиты DBF Viewer 2000 .
Предположим , что имеется некая табличка dbf с данными о городских строениях. Запускаем вышеупомянутую утилиту DBF Viewer и идём меню Файл > Сохранить/Экспорт :
. и в опциях Тип файла выбираем (для нашего случая) SQL files :
В следующей форме необходимо уточнить тип конкретного SQL- сервера :
Жмём OK . Далее запускаем оболочку SQL Server Management Studio и по меню Файл > Открыть :
. подхватываем сгенерированный только-что скрипт :
Выглядеть текст скрипта для нашего учебного случая будет приблизительно сл. образом (прим. смысл скрипта в том , что он просто вставляет конструкцией insert into значения , взятые из исходной dbf -таблицы ):
Жмём F5 (или кнопку Выполнить) и в таблице master можем увидеть нашу отконвертированную таким образом dbf- табличку :
О том , как ещё можно экспортировать/импортировать данные из/в MS SQL Server смотрите здесь
Как импортировать файл .dbf в SQL Server с помощью SQL-скрипта?
Найдено ответов от этой должности, но, к сожалению, ни один из них не работает для меня :(:
Когда я пытаюсь этот код:
Я получаю эту ошибку:
OLE DB provider "MSDASQL" for linked server "(null)" returned message "[Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified". Msg 7303, Level 16, State 1, Line 1 Cannot initialize the data source object of OLE DB provider "MSDASQL" for linked server "(null)".
А также, при попытке это:
Я получаю эту ошибку:
Msg 7438, Level 16, State 1, Line 1
The 32-bit OLE DB provider "VFPOLEDB" cannot be loaded in-process on a 64-bit SQL Server.
Я не хочу, чтобы загрузить приложения сторонних производителей. Вот почему я пытаюсь найти все возможное решение, и теперь мне нужна ваша помощь, ребята. Я создаю небольшое приложение для импорта файлов .DBF в SQL Server.
Создан 05 дек. 13 2013-12-05 04:09:54 Gimo Gilmore
Вы должны начать с основ. Используйте эту ссылку, чтобы открыть администратора ODBC. http://windows.microsoft.com/en-au/windows7/using-the-odbc-data-source-administrator. Теперь создайте системный DSN для подключения к вашему файлу DBF — это работает? – Nick.McDermaid 05 дек. 13 2013-12-05 06:26:51
Это одноразовый или повторяющийся импорт данных? – Eccountable 12 дек. 13 2013-12-12 01:38:19
Хороший вопрос. У меня такая же проблема. @Nick, я попробовал добавить системную DSN, но A) Я и люди, использующие сценарий, который я пытаюсь создать, не имеют прав администратора, и B) для этого потребуется, чтобы каждый пользователь скрипта добавлял драйвер и настраивал система DSN, которая выходит за рамки понимания многих из них. Любые идеи или указатели были бы оценены вдвойне, ребята (и дамы). – cfwschmidt 22 апр. 15 2015-04-22 15:45:51
Учитывая, что вы создаете _application_ для этого, вы поняли, что для использования ‘OPENROWSET’ драйвер должен быть установлен на SQL Server? Если вы хотите импортировать файл DB2 в SQL Server с помощью «переносного» приложения, не используйте OPENROWSET, поскольку это активность на стороне сервера, и вам нужно, например, установить драйверы DBF на SQL Server. Возможно, вы сможете точно определить, как вы хотите, чтобы это работало. – Nick.McDermaid 22 апр. 15 2015-04-22 22:57:01
@cfwschmidt, возможно, запустит новый вопрос, но . во-первых, это всего лишь тестовая деятельность для тестирования, ее не обязательно запускать, а во-вторых, это активность на стороне сервера, каждый пользователь не должен будет этого делать. Его нужно тестировать только на сервере. – Nick.McDermaid 22 апр. 15 2015-04-22 23:15:06
4 ответа
Вы используете 64-разрядную SQL Sever, но драйвер FoxPro OLE DB является 32-бит. Вам необходимо обратиться к this article, в котором обсуждается, как использовать 32-разрядный драйвер OLE DB с 64-разрядным SQL Server.
Создан 05 дек. 13 2013-12-05 10:54:38 Alan B
Gimo, я не уверен, что это сработает, и я не эксперт MS SQL Server, но в последнее время я борюсь с подобной проблемой, и у меня есть идея. Я думаю, что вы можете быть в состоянии получить, что первый блок кода из вашего вопроса, чтобы работать, если выполнить следующие операторы первым:
EXEC sp_configure ‘show advanced options’, 1 RECONFIGURE; GO
EXEC sp_configure ‘Ad Hoc Distributed Queries’, 1 RECONFIGURE; GO
Это может не работать, если у вас нет соответствующих прав (что произошло в моей ситуации), но это может стоить того.
Создан 22 апр. 15 2015-04-22 23:00:44 cfwschmidt
Наш офис, гуру SQL/GIS, Burce, решил аналогичную проблему, с которой я столкнулся. Я не уверен во всех подробностях о том, как он это сделал, поэтому, хотя я не хочу вводить это как «Ответ» (слишком много символов для ввода в качестве комментария), я опишу, что могу, если это произойдет полезен для всех. Сначала имейте в виду, что он имеет полные разрешения на SQL Server, поэтому это решение может оказаться невозможным для всех пользователей БД. Брюс создал связанный сервер, подключенный к каталогу «. /DBF /» на нашем файловом сервере LAN. Он также создал аналогичный каталог Linked Server & для файлов CSV. Любой пользователь нашего офиса может просто скопировать DBF-файл в этот каталог, а затем получить доступ к нему в SQL Server, как если бы он был обычной таблицей в базе данных SQL Server. Я обращаюсь к этому в SSMS, подключившись к Database Engine, затем перейду в «Объекты сервера»> «Связанные серверы»> «DBF»> Каталоги> по умолчанию> Таблицы>имя файла.Свойства связанного сервера сказать следующее:
Из вкладке Общие окна Свойства 
Из вкладке Безопасность окна свойств 
На вкладке Параметры сервера в окне Свойства 
Обратите внимание, что это может быть или не быть безопасной конфигурацией для всех сред сервера баз данных, но это находится на SQL Server, который находится в нашей внутренней сети, доступен только в нашем офисе без каких-либо конечных точек или доступа за пределами нашей локальной сети (это не используется как сервер для Интернета или других интернет-сервисов).
Создан 15 июн. 15 2015-06-15 18:37:05 cfwschmidt
У меня были подобные проблемы, где вещи просто не работал, пытаясь переместить устаревшие таблицы из VFP в SQL 2008R2 и использовали следующую процедуру:
- выберите таблицу в VFP
- копию blahblah XL5
- Шаг 2 приводит к файлу Excel
- Используйте SQL 2008 R2 или выше «Импорт и экспорт данных (32 бит)» для импорта файла excel.
- Я работал под управлением Windows 7 64 бит и все еще должен был использовать 32-битный импорт, чтобы он работал плавно.
Создан 24 июн. 15 2015-06-24 17:07:06 Jeffrey Berezin
Несмотря на то, что dbf давно считается legacy форматом, сабж до сего времени остается насущной задачей судя по количеству вопросов в Интернете. В частности, я с ней столкнулся при попытке затянуть в таблицу карту. Карта ArcGIS содержала метаданные в формате dbf . Имело смысл прочитать их заодно в SQL Server , чтобы не делать вручную подписи к полигонам, линиям и иным картографическим объектам. В давние времена Visual FoxPro 6 и SQL Server 7.0 это не составляло проблемы , но с тех пор многое изменилось. С выходом SQL Server 2005 в MSDN появилась информация, что мастер импорта и экспорта в SQL Server не поддерживает импорт и экспорт dBASE-файлов и других DBF-файлов. В качестве решения рекомендовано использовать SQL Server Integration Services или промежуточный импорт в Access или Excel . Такая же ситуация формально сохраняется по сей день, включая SQL Server 2012 . Это не всегда удобно, потому что, помимо SQL Server , требует дополнительной установки MS Office , а средства разработки ETL -пакетов не входят в состав бесплатной редакции SQL Server Express . В этой заметке я постараюсь импортировать dbf в SQL Server , не пользуясь ничем, кроме SQL Server .
Имеется файл regions2010_wgs.dbf, взятый отсюда . Открываем SQL Server Management Studio , в Object Explorer выбираем базу, в таблицу которой будем импортировать dbf , и из контекстного меню говорим Import Data :
В качестве источника данных указываем . Net Framework Data Prov > for ODBC , коль скоро ODBC теперь снова наше все , в качестве ConnectionString — следующую строку соединения:
Нажимаем Next . Если теперь нажать Back , мы увидим, что свойства соединения развернулись из строки в столбец так, чтобы можно было лицезреть их список и видеть, чему каждое из них равно:
Примеры строки соединения для ODBC -драйвера dBase приводятся, например, в Microsoft Knowledge Base или на ресурсе connectionstrings.com . В целом, о назначении тех или свойств легко догадаться из их названий, кроме, пожалуй, свойства Deleted, которое имеет прямо противоположный смысл . Как известно, операция удаления строки в dBase / FoxPro не приводит к ее немедленному физическому удалению из файла. Строка лишь помечается, что она удалена. Физическая очистка строк, у которых проставлен признак удаления, и реорганизация файла выполняются командой PACK . Значение NO говорит драйверу включить удаленные строки в возвращаемый набор результатов. Чтобы, наоборот, их не показывать, надо поставить YES. Жмем Next .
На следующем экране все просто. Задается соединение с SQL Server , включая ту базу, в которой будет создана таблица с результатами импорта из dbf :
Идем дальше. Предлагается выбрать dbf -ную таблицу из списка таблиц или написать руками запрос. Имеет смысл, например, для FoxPro шной базы, которая, как и всякая нормальная база, представляет собой контейнер, в котором содержится несколько таблиц, в данном случае в виде отдельных dbf -файлов . Для индивидуального dbf -файла это не работает — см., например, OdbcConnection . GetSchema (" tables ") all wrong for . dbf file , и сотрудники поддержки Microsoft рекомендовали в этой ситуации использовать OLE DB Prov > for Visual FoxPro . Во-первых, случай имел место задолго до коренного перелома генеральной линии партии. OLE DB тогда было наше все, a ODBC , наоборот, относилось к старым унаследованным интерфейсам. Во-вторых, я не понимаю, зачем броузить список dbf , когда он и так один.
В случае разрозненных dbf , лежащих в одной директории, надо задать в строке ODBC -соединения (Рис.3) свойство DefaultDir, например,
Тогда можно отметить Copy Data from one or more tables or views.
и будет выведен список dbf в этой директории, из которого будет предложено выбрать:
Но я не задавал DefaultDir на Рис.3, поэтому выбираю написать запрос:
а в ответ получаю ошибку The Microsoft Jet database engine could not find the object ‘regions2010_wgs.dbf’:
Эта ошибка происходит из-за того, что глупый драйвер до сих пор воспринимает имена файлов в формате MS-DOS 8.3 . Если переименовать файл regions2010_wgs.dbf в, скажем, aaa . dbf , а запрос Рис.8, соответственно, заменить на select * from c:Tempaaa.dbf , ошибка пропадает. Будет предложено выбрать существующую или задать название таблицы, которая будет создана на SQL Server в базе Database 1 (см.Рис.4) под результаты импорта из dbf . Oставляю предлагаемое название как есть:
Нажав здесь же кнопку Preview , можно предварительно ознакомиться с содержимым dbf , котор o е предполагается перенести на SQL Server :
Все хорошо, только удручает абракадабра вместо русского текста. Причину ее появления в популярной форме объясняет уважаемый автор Lalex здесь . Русские символы слетают из-за того, что глупый драйвер ожидает dbf ный файл в DOS овской кодировке ( CP 866, она же OEM ). Он, похоже, считает формат dbf очень древним, чисто досовским наследием. ArcView же по умолчанию считает DBF виндосовским форматом ( ANSI 1251). Так и стоят эти две программы, как два бычка, упершись лбами .
Итак, причина ясна, осталось ее поправить. Пляски с бубном прописать в строку соединения collate=Machine или Russian / CodePage=ANSI / Collating Sequence=1251 к успеху не привели. Изменил 29-й байт в aaa . dbf на 0хС9 — ноль эмоций. Действительно, признак кодовой страницы в заголовке dbf драйвером игнорируется. Однако настройку драйвера можно изменить в реестре. Она хранится в DataCodePage по пути HKLM SOFTWARE Microsoft Jet 4.0 Engines xBase или HKLM SOFTWARE Microsoft Office 14.0 Access Connectivity Engine Engines Xbase или, соответственно, HKLM SOFTWARE Wow 6432 Node Microsoft Jet 4.0 Engines xBase или HKLM SOFTWARE Wow 6432 Node Microsoft Office 14.0 Access Connectivity Engine Engines Xbase в зависимости от того, был ли установлен на машину Office и если да, то как. По умолчанию, свойство действительно имеет значение OEM , что заставляет драйвер читать все dbf ы из расчета этой кодировки. Если изменить его на ANSI
кириллица в ANSI шном dbf ‘ e , естественно, будет читаться по-человечески:
Перезапускаться при этом, к счастью, не требуется, однако визард импорта следует закрыть и повторить по-новой с Рис.1.
Жмем ОК, Next , заканчиваем визард, в результате чего неявно создается и выполняется SSIS -пакет:
и получаем фигню. Гы!
Это, на самом деле, тоже понятно, почему. В таблице Query под результаты импорта визард создал поле region типа varchar (200) без явного указания коллации. Следовательно, для него по умолчанию используется коллация базы. Так получилось, что база Database 1 имела нерусскую коллацию:
Чтобы исправить ситуацию, надо сделать поле region юникодовским или откорректировать ему коллацию. Кстати, давайте ему еще длину увеличим. Так, на всякий случай.
Сохраняем изменения структуры, очищаем данные truncate table Query и повторяем импорт Рис.1-14
Теперь все импортируется нормально. Единственно, я сказал "очищаем данные", но у себя это сделать забыл, и на картинке они задвоились. Переделывать уже не буду, потому что непринципиально. Смысл понятен.