Як джерело даних вказуємо .Net Framework Data Provider 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 Provider for Visual FoxPro. По-перше, випадок мав місце задовго до корінного перелому генеральної лінії партії. OLE DB тоді було наше все, a ODBC, навпаки, ставилося до старих успадкованим інтерфейсів. По-друге, я не розумію, навіщо Броуз список dbf, коли він і так один.
У разі розрізнених dbf, що лежать в одній директорії, треба задати в рядку ODBC-з'єднання (Рис.3) властивість DefaultDir, наприклад,
і буде виведений список dbf в цій директорії, з якого буде запропоновано вибрати:
Але я не ставив DefaultDir на Рис.3, тому вибираю написати запит:
Натиснувши тут же кнопку Preview, можна попередньо ознайомитися з вмістом dbf, которoе передбачається перенести на SQLServer:
Перезапускатися при цьому, на щастя, не потрібно, однак візард імпорту слід закрити і повторити по-новій з Рис.1.
Тиснемо ОК, Next, закінчуємо візард, в результаті чого неявно створюється і виконується SSIS-пакет:
і отримуємо фігню. Ги!
Це, насправді, теж зрозуміло, чому. У таблиці Query під результати імпорту візард створив поле region типу varchar (200) без явного вказівки Коллацо. Отже, для нього за умовчанням використовується Коллацо бази. Так вийшло, що база Database1 мала неросійських коллацію:
Щоб виправити ситуацію, треба зробити поле region юнікодовскім або відкоригувати йому коллацію. До речі, давайте йому ще довжину збільшимо. Так, про всяк випадок.
Зберігаємо зміни структури, очищаємо дані truncate table Query і повторюємо імпорт Ріс.1-14
Тепер все імпортується нормально. Єдино, я сказав "очищаємо дані", але у себе це зробити забув, і на зображенні вони задвоілісь. Переробляти вже не буду, тому що не принципово. Сенс зрозумілий.