Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Dotyczy:
SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)
Aplikacja ODBC ma trzy opcje pobierania danych wyników.
Pierwsza opcja opiera się na SQLBindCol. Przed pobraniem zbioru wyników aplikacja używa SQLBindCol do powiązania każdej kolumny w zbiorze wyników z daną zmienną programu. Po powiązaniu kolumn sterownik przesyła dane z bieżącego wiersza do zmiennych powiązanych z kolumnami zestawu wyników za każdym razem, gdy aplikacja wywołuje SQLFetch lub SQLFetchScroll. Sterownik obsługuje konwersje danych, jeśli kolumna zbioru wyników i zmienna programowa mają różne typy danych. Jeśli aplikacja ma SQL_ATTR_ROW_ARRAY_SIZE ustawiony powyżej 1, może przypisać kolumny wyników do tablic zmiennych, które będą wypełniane przy każdym wywołaniu SQLFetchScroll.
Druga opcja opiera się na SQLGetData. Aplikacja nie używa SQLBindCol do wiązania kolumn zbioru wyników ze zmiennymi programu. Po każdym wywołaniu SQLFetch aplikacja wywołuje SQLGetData raz dla każdej kolumny w zbiorze wyników. SQLGetData instruuje sterownik do przeniesienia danych z konkretnej kolumny zbioru wyników do określonej zmiennej programu oraz określa typy danych tej kolumny i zmiennej. Pozwala to sterownikowi na konwersję danych, jeśli kolumna wyników i zmienna programowa mają różne typy danych. Kolumny tekstowe, ntext i obrazy są zazwyczaj zbyt duże, by zmieścić się w zmiennej programowej, ale nadal można je pobrać za pomocą SQLGetData. Jeśli dane tekstowe, ntext lub obrazowe w kolumnie wyników są większe niż zmienna programu, SQLGetData zwraca SQL_SUCCESS_WITH_INFO oraz SQLSTATE 01004 (dane ciągu, po prawej stronie obcięte). Kolejne wywołania do SQLGetData zwracają kolejne fragmenty tekstu lub obrazu . Gdy dane zostaną osiągnięte, SQLGetData zwraca SQL_SUCCESS. Każde pobieranie zwraca zbiór wierszy, czyli zestaw wierszy, jeśli SQL_ATTR_ROW_ARRAY_SIZE jest większe niż 1. Przed użyciem SQLGetData musisz najpierw użyć SQLSetPos , aby określić konkretny wiersz w zbiorze jako aktualny wiersz.
Trzecią opcją jest użycie mieszanki SQLBindCol i SQLGetData. Aplikacja mogłaby na przykład powiązać pierwsze dziesięć kolumn zbioru wyników, a następnie przy każdym pobieraniu wywoływać SQLGetData trzy razy, aby pobrać dane z trzech kolumn niepowiązanych. Zazwyczaj stosuje się to, gdy zbiór wyników zawiera jedną lub więcej kolumn tekstowych lub obrazowych .
W zależności od opcji kursora ustawionych dla zestawu wyników, aplikacja może również korzystać z opcji przewijania w SQLFetchScroll do przewijania zbioru wyników.
Nadmierne wykorzystanie SQLBindCol do powiązania kolumny zbioru wyników z zmienną programu jest kosztowne, ponieważ SQLBindCol powoduje alokację pamięci przez sterownik ODBC. Gdy przypisujesz kolumnę result do zmiennej, to powiązanie pozostaje w mocy, dopóki nie wywołasz SQLFreeHandle , aby uwolnić uchwyt instrukcji, lub nie wywołasz SQLFreeStmt z fOption ustawionym na SQL_UNBIND. Przypisania nie są automatycznie cofnięte po zakończeniu polecenia.
Ta logika pozwala skutecznie wykonać to samo polecenie SELECT kilka razy z różnymi parametrami. Ponieważ zbiór wyników zachowuje tę samą strukturę, możesz powiązać zbiór wyników raz, przetworzyć wszystkie instrukcje SELECT, a następnie wywołać SQLFreeStmt z fOption ustawionym na SQL_UNBIND po ostatnim wykonaniu. Nie powinieneś wywoływać SQLBindCol , aby wiązać kolumny w zbiorze wyników bez wcześniejszego wywołania SQLFreeStmt z fOption ustawionym na SQL_UNBIND, aby uwolnić wcześniejsze powiązania.
Korzystając z SQLBindCol, możesz stosować przypisywanie wierszami lub kolumnami. Owiązywanie wierszami jest nieco szybsze niż owiązywanie według kolumn.
Możesz użyć SQLGetData do pobierania danych kolumna po kolumnie, zamiast wiązać kolumny zbioru wyników za pomocą SQLBindCol. Jeśli zbiór wyników zawiera tylko kilka wierszy, szybsze jest użycie SQLGetData zamiast SQLBindCol ; poza tym SQLBindCol zapewnia najlepszą wydajność. Jeśli nie zawsze umieszczasz dane w tym samym zestawie zmiennych, powinieneś używać SQLGetData zamiast ciągłego przypisywania. Możesz używać SQLGetData tylko na kolumnach znajdujących się w liście select po tym, jak wszystkie kolumny są powiązane z SQLBindCol. Kolumna musi również pojawić się po kolumnach, na których już używałeś SQLGetData.
Funkcje ODBC, które zajmują się przenoszeniem danych do lub z zmiennych programowych, takie jak SQLGetData, SQLBindCol i SQLBindParameter, wspierają konwersję typów danych niejawnych. Na przykład, jeśli aplikacja wiąże kolumnę całkowitą z zmienną programu łańcucha znaków, sterownik automatycznie konwertuje dane z liczby całkowitej na znak, zanim umieści je w zmiennej programowej.
Konwersja danych w aplikacjach powinna być minimalizowana. O ile konwersja danych nie jest wymagana do przetwarzania wykonywanego przez aplikację, aplikacje powinny wiązać kolumny i parametry ze zmiennymi programowymi tego samego typu danych. Jeśli dane muszą być konwertowane z jednego typu na inny, efektywniej jest, aby konwersję przeprowadził sterownik niż w aplikacji. Sterownik ODBC natywnego klienta SQL Server zazwyczaj przesyła dane bezpośrednio z buforów sieciowych do zmiennych aplikacji. Poproszenie sterownika o konwersję danych zmusza go do buforowania danych i wykorzystania cykli CPU do konwersji danych.
Zmienne programowe powinny być na tyle duże, by pomieścić dane przesyłane z kolumny, z wyjątkiem tekstu, ntextu i danych obrazowych . Jeśli aplikacja próbuje pobrać dane ze zbioru wyników i umieścić je w zmiennej zbyt małej, by je pomieścić, sterownik generuje ostrzeżenie. To zmusza sterownik do przydzielenia pamięci dla wiadomości, a zarówno sterownik, jak i aplikacja muszą poświęcić cykle procesora na przetwarzanie wiadomości i obsługę błędów. Aplikacja powinna albo przydzielić zmienną wystarczająco dużą, aby pomieścić pobierane dane, albo użyć funkcji SUBSTRING w liście select, aby zmniejszyć rozmiar kolumny w zbiorze wyników.
Należy zachować ostrożność przy użyciu SQL_C_DEFAULT przy określaniu typu zmiennej C. SQL_C_DEFAULT określa, że typ zmiennej C odpowiada typowi danych SQL kolumny lub parametru. Jeśli SQL_C_DEFAULT jest określone dla kolumny ntext, nchar lub nvarchar , dane Unicode są zwracane do aplikacji. Może to powodować różne problemy, jeśli aplikacja nie została zaprogramowana do obsługi danych Unicode. Te same typy problemów mogą wystąpić z typem danych unikalnego identyfikatora (SQL_GUID).
Dane tekstowe, ntext i obrazowe są zazwyczaj zbyt duże, by zmieścić się w jednej zmiennej programowej, i zwykle są przetwarzane za pomocą SQLGetData zamiast SQLBindCol. Podczas korzystania z kursorów serwera, sterownik ODBC natywnego klienta SQL Server jest zoptymalizowany tak, aby nie przesyłać danych dla niepowiązanych kolumn tekstowych, ntextowych lub obrazowych w momencie pobierania wiersza. Tekst, ntext lub dane obrazowe nie są faktycznie pobierane z serwera, dopóki aplikacja nie wyda SQLGetData dla kolumny.
Optymalizacja ta może być zastosowana w aplikacjach, tak aby podczas przewijania kursora przez użytkownika nie były wyświetlane żadne dane tekstowe, ntext ani obraz . Po wybraniu wiersza aplikacja może wywołać SQLGetData , aby pobrać dane tekstowe, ntextowe lub obrazowe . Pozwala to zaoszczędzić przesyłanie tekstu, ntekstu lub danych obrazowych dla dowolnego wiersza, którego użytkownik nie wybierze, i pozwala zaoszczędzić przesyłanie bardzo dużych ilości danych.