Mam starsze źródło bazy danych PostgreSQL (ODBC), które próbuję migrować do nowego schematu programu SQL Server za pomocą SSIS. Dostaję ostrzeżenie:
Metoda pobierania „wiersz po wierszu” jest wymuszona, ponieważ tabela zawiera kolumny LOB. Zawartość kolumny to LOB
Chodzi o to, że żadna kolumna tak naprawdę nie musi być LOB-em. Istnieje kilka rodzajów TEKSTÓW, ale można je łatwo zmieścić w varchar (maks.). Nawet obcy, choć większość już są typu varchar, ale wydaje się niczego na varchar (128) jest traktowany tak, jakby był to LOB (we właściwościach zaliczek, typ danych jest DT_NTEXT).
Zdarzyło się, że próbowałem wykonać ręczne polecenie SQL, w którym jawnie rzuciłem każdy typ łańcucha na varchar o odpowiedniej długości w instrukcji select i nadal są one ustawiane jako DT_NTEXT w źródle ODBC.
Nie jestem DBA, więc jest całkiem możliwe, że robię coś naprawdę głupiego. Chciałbym po prostu poznać najlepszy sposób, aby upewnić się, że typy skończą się jako varchary, aby móc pobierać partie. Jakieś pomysły?
W razie potrzeby używam SSIS-BI 2014 w Visual Studio 2013.
źródło
varchar(max)że to tylko skrót do stwierdzenia, że dane kolumny mogą mieścić się w maksymalnym rozmiarze varchara, który wynosi około 4000, dla celów SSIS, tak myślę. Tak naprawdę nie przesyłam niczegovarchar(max); chociażvarchar(4000)dla pewności rzuciłem kilka kolumn .Odpowiedzi:
Użyłem konwersji danych dla varchara większego niż 128 jako NTEXT, ale to, co usunęło dla mnie błąd, to ostatecznie ustaw wartość Sprawdź poprawność danych zewnętrznych na False.
źródło
Najwyraźniej sprowadza się to do tego, że SSIS traktuje dowolny varchar większy niż 128 jako NTEXT. Nie pewny dlaczego. Mogę jednak przejść do zaawansowanych właściwości źródła ODBC i zmienić typy z powrotem na coś takiego jak DT_WSTR. Co wydaje się w większości działać.
Jednak ustaliłem, że niektóre tabele, z którymi mam do czynienia, w niektórych swoich kolumnach TEXT przenoszą do 4000 bajtów, więc niestety muszę zostawić te kolumny jako DT_NTEXT, aby zapobiec obcięciu (SSIS nie pozwala ustawiasz typ DT_WSTR z więcej niż 4000 bajtów). Przypuszczam, że w takich przypadkach po prostu utknąłem przy pobieraniu wiersz po rzędzie, ale przynajmniej udało mi się naprawić kilka tabel.
źródło
To rozwiązanie działało dla mnie:
Usunąłem błąd, zmieniając parametr Max Varchar we właściwości źródła danych. Przejdź do menedżera połączeń. Wybierz opcję kompilacji obok ciągu połączenia. Kliknij przycisk połączenia, aby uzyskać dostęp do większej opcji. Zmień wartość Max Varchar.
źródło
W moim przypadku źródłem jest Filemaker ODBC, który również traktuje długi tekst jako typ danych LOB. Mój pakiet był zawieszany przez długi czas z powodu ekstremalnego spadku wydajności dla metody pobierania Wiersz po Wierszu jest wymuszony, ponieważ tabela ma kolumny LOB. Dlatego podczas wdrażania był używany po długim czasie i ostatecznie się nie udawał.
Dzielę się faktycznym rozwiązaniem, które działało dla mnie jak urok. Pobranie jednego dnia o wartości ponad 30 000 danych typu LOB zajęło mi około 10 minut:
Obniż DefaultBufferMaxRows do 1 i zwiększ DefaultBufferSize do maksimum, tj. 100 MB. Następnie zmień źródłowy DSN ODBC, zaznaczając opcję „traktuj tekst jak długi varchar”. I mapuj typy danych od źródła do celu (bez żadnych zmian w zaawansowanym edytorze w źródle).
źródło