Ca sursă de date, specificați Furnizorul de date .Net Framework pentru ODBC, deoarece ODBC este acum totul din nou. ca ConnectionString, următorul șir de conectare:
Faceți clic pe Următorul. Dacă faceți clic pe Înapoi, vom vedea că proprietățile conexiunii sunt transformate din rândul în coloană, astfel încât să puteți vedea lista acestora și să vedeți ce dintre ele este egal cu:
Exemplele de șir de conexiuni pentru driverul dBase ODBC sunt furnizate, de exemplu, în Baza de cunoștințe Microsoft sau pe link-ul resourceringsstrings.com. În general, numirea acestor persoane sau proprietăți este ușor de ghicit din numele lor, cu excepția, probabil, proprietățile lui Deleted, care are exact sensul opus. După cum știți, operația de ștergere a unei linii în dBase / FoxPro nu duce la eliminarea fizică imediată din fișier. Linia marchează numai faptul că este șters. Eliminarea fizică a rândurilor care au un flag de ștergere și o reorganizare a fișierelor este efectuată de comanda PACK. Valoarea NO indică șoferului să includă rânduri șterse din setul de rezultate returnat. Din contră, nu le arătați, trebuie să puneți DA. Faceți clic pe Următorul.
Pe ecranul următor, totul este simplu. Se stabilește o conexiune la SQL Server, inclusiv baza de date în care tabela va fi creată cu rezultatele de import din dbf:
Mergem mai departe. Se recomandă să alegeți o tabelă dbf din lista de tabele sau să scrieți o solicitare manuală. Are sens, de exemplu, pentru baza de date FoxProper, care, ca orice altă bază de date normală, este un container care conține mai multe tabele, în acest caz ca fișiere separate dbf. Pentru un fișier dbf individual acest lucru nu funcționează - vedeți, de exemplu, OdbcConnection.GetSchema ("tables") toate greșit pentru fișierul .dbf. și personalul de asistență Microsoft recomandat în această situație să utilizeze OLE DB Provider pentru Visual FoxPro. În primul rând, cazul a avut loc cu mult înainte de descoperirea radicală a liniei generale a partidului. OLE DB a fost atunci totul, iar ODBC, dimpotrivă, se referea la vechile interfețe moștenite. În al doilea rând, eu nu înțeleg de ce deranjez cu lista dbf atunci când este deja una.
În cazul dbf-urilor disparate care se află în același director, trebuie să setați proprietatea DefaultDir în șirul de conexiuni ODBC (Fig.3), de exemplu,
iar lista dbf din acest director va fi afișată, din care va fi oferit să alegeți:
Dar nu am setat DefaultDir în Figura 3, deci am ales să scriu interogarea:
Dând clic pe butonul Previzualizare, puteți previzualiza conținutul dbf, care ar trebui transferat în SQLServer:
Din fericire, nu este necesar să reporniți, dar expertul de import ar trebui să fie închis și repetat într-un mod nou cu Fig.1.
Faceți clic pe OK, apoi, finalizați expertul, în urma căruia pachetul SSIS este implicit creat și executat:
și a lua gunoi. Gee!
De fapt, de asemenea, este de înțeles de ce. În tabelul Interogare sub rezultatele de import, expertul a creat un câmp de regiune de tip varchar (200), fără indicații explicite de colaționare. Prin urmare, aceasta implică coliziunile bazei de date. Sa întâmplat astfel ca baza de date a bazei de date1 să aibă collațiuni non-ruse:
Pentru a rezolva situația, trebuie să faceți câmpul de regiune unicode sau să îl corectați pentru colocări. Apropo, să mărim lungimea. Deci, doar în caz.
Salvați modificările structurii, ștergeți tabelul trunchiat Solicitați datele și repetați importul Fig.1-14
Acum totul este importat normal. Singurul lucru pe care l-am spus a fost "ștergerea datelor", dar am uitat să o fac singur, iar în imagine au fost respinși. Nu o voi schimba, pentru că nu este fundamentală. Înțelesul este clar.
Articole similare
-
Sfaturi pentru o întreținere eficientă a bazei de date sql server - sql server - produse software
-
Restricție - import - o enciclopedie mare de petrol și gaze, articol, pagina 1
Trimiteți-le prietenilor: