Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Провайдер SQLOLEDB - есть ли ограничение объем выбираемых данных?  [new]
Dimitry Timokhov
Member

Откуда: Москва
Сообщений: 71
Здравствуйте!

1. Кратко: ADODB+SQLOLEDB использую давно. Но столкнулся с зависанием ADODB.Command.Execute.

2. Подробно:
а. Есть запрос. Запрос большой. 2.7млн записей и 240мб в результате.
б. С помощью ADODB.Command.Execute выполняю его с целью получения Recordset.
в. ADODB.Command.Execute виснет наглухо. Причем даже ADODB.Command.Timeout игнорируется.
г. В QA тот же запрос выполняется за 20 секунд (откуда я и знаю данные из п. а выше).

3. Вопрос: есть ли какие-то в провайдере SQLOLEDB ограничения на объем выборки?
Я не нашел. Может, неумело искал.

Спасибо!

PS
а. MSSQL 2012
б. И в QA и в ADODB протокол named pipes.
5 дек 19, 10:02    [22032814]     Ответить | Цитировать Сообщить модератору
 Re: Провайдер SQLOLEDB - есть ли ограничение объем выбираемых данных?  [new]
StarikNavy
Member

Откуда: Москва
Сообщений: 2375
Dimitry Timokhov,

ограничений нет. глюки возможны
5 дек 19, 10:55    [22032867]     Ответить | Цитировать Сообщить модератору
 Re: Провайдер SQLOLEDB - есть ли ограничение объем выбираемых данных?  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30825
Dimitry Timokhov
в. ADODB.Command.Execute виснет наглухо. Причем даже ADODB.Command.Timeout игнорируется.
Равновероятно, что это глюк ADODB+SQLOLEDB, или это невыполнение самого запроса.

То, что в QA запрос выполняется, не значит, что он выполнится из клиента, такое бывает, из заз разных параметров коннекта.

Посмотрите в профайлере - запрос начал выполняться? И что там сервер делает.

UPD: да, и никаких ограничений на объём у ADODB+SQLOLEDB нет.

Сообщение было отредактировано: 5 дек 19, 11:15
5 дек 19, 11:14    [22032887]     Ответить | Цитировать Сообщить модератору
 Re: Провайдер SQLOLEDB - есть ли ограничение объем выбираемых данных?  [new]
ShIgor
Member

Откуда: Нижний Новгород
Сообщений: 2300
Dimitry Timokhov,

Какие настройки Mode, CursorLocation и IsolationLevel у соединения и СursorType у возвращаемого RS?
5 дек 19, 11:19    [22032900]     Ответить | Цитировать Сообщить модератору
 Re: Провайдер SQLOLEDB - есть ли ограничение объем выбираемых данных?  [new]
Dimitry Timokhov
Member

Откуда: Москва
Сообщений: 71
Коллеги, благодарю за внимание к вопросу.
Но, похоже, тему можно закрывать, т.к. я на простом тестовом примере выяснил причинно-следственную следственную связь. Если кратко, то ADODB+SQLOLEDB есть проблемы, но я сам виноват, т.к. загнал провайдера в ситуацию, на которую он не рассчитан. Однако напишу выводы, может, полезно кому-то еще будет.

Подробнее:

1. Моё окружение: Windows10 64 бита, 16гб оперативки, SQL2012, Delphi2007 (т.е. 32 бита), ADODB используется как OLE через позднее связывание (т.е. не используются стандартные библиотеки Delphi).
Вот пример:
var
   cnn, cmd, rs: OleVariant;
begin
   cnn := CreateOleObject('ADODB.Connection');
   cnn.CursorLocation := $00000003{adUseClient};
   cnn.Open('Provider=SQLOLEDB;Server=server;Database=db;Trusted_Connection=Yes;Application name=test1');

   cmd := CreateOleObject('ADODB.Command');
   cmd.CommandText := cSql2;

   cmd.CommandType := $00000001{adCmdText};
   cmd.CommandTimeout := 1000;
   cmd.ActiveConnection := cnn;

   rs := cmd.Execute(Options := $00000001{adCmdText});
end;


2. Запрос cSql2 выдает 2.7 млн строк, где одно поле varchar(8000) (в реальности хранится макс. 100 символов), 4 varchar(255) (в реальности хранится макс. 20-30 символов), остальные 11 int и smalldatetime. Общий размер результата 240мб.

3. При первом выполнении в тестовом примере свалилось с EOleException "Недостаточно памяти".
Добавил в проект флаг {$SetPEFlags $0020} // IMAGE_FILE_LARGE_ADDRESS_AWARE
Сваливаться перестало, но навечно (игнорируя cnn.CommandTimeout) зависает.
По диспетчеру задач - приложение крутится где-то в районе 2.4гб занятой памяти.

4. Пробовал выполнять запрос на 25млн строк с размером результата 600мб, где типы полей только int. Работает!!!

5. ВЫВОДЫ:
а. Провайдер SQLOLEDB не может переварить (обработать рез-ты запроса), когда много строковых данных.
б. Надо переходить на последние версии Delphi в 64 бита, а не держаться за старые версии.

Сообщение было отредактировано: 5 дек 19, 11:43
5 дек 19, 11:42    [22032946]     Ответить | Цитировать Сообщить модератору
 Re: Провайдер SQLOLEDB - есть ли ограничение объем выбираемых данных?  [new]
aleks222
Member

Откуда:
Сообщений: 857
Dimitry Timokhov
данных.
б. Надо переходить на последние версии Delphi в 64 бита, а не держаться за старые версии.


Это же классический говнокод.
Я не рассматриваю вопрос "нафига козе баян 2.7млн записей на клиенте?". Это очевидно.
Допускаем, что "нужно".
Т.е. говнокодер знает знает, что у него "дохера и более строк".
Но никак не пытается обдумать парадигму "нешто мне первому приспичило?"
В ADODB есть методы получения "дохера и более строк" кусками.
5 дек 19, 12:39    [22033040]     Ответить | Цитировать Сообщить модератору
 Re: Провайдер SQLOLEDB - есть ли ограничение объем выбираемых данных?  [new]
Wlr-l
Member

Откуда:
Сообщений: 512
Dimitry Timokhov,

5. ВЫВОДЫ

в. Перейти на новую версию драйвера OLE DB:

https://docs.microsoft.com/en-us/sql/connect/oledb/oledb-driver-for-sql-server?view=sql-server-ver15

3. Microsoft OLE DB Driver for SQL Server (MSOLEDBSQL)
5 дек 19, 14:31    [22033198]     Ответить | Цитировать Сообщить модератору
 Re: Провайдер SQLOLEDB - есть ли ограничение объем выбираемых данных?  [new]
Dimitry Timokhov
Member

Откуда: Москва
Сообщений: 71
aleks222,

aleks222
Это же классический говнокод.

Культура? Не, не слышал.

aleks222
Я не рассматриваю вопрос "нафига козе баян 2.7млн записей на клиенте?". Это очевидно.
Допускаем, что "нужно".

Распечатать шрифтом size=5 и сдать в архив 20 кг макулатуры. Не вариант?

aleks222
В ADODB есть методы получения "дохера и более строк" кусками.

Сам ADODB ничего не умеет. он пользуется серверными курсорами, которыми мы не пользуемся.
Если речь, конечно, идет про CursorLocation и adUseServer?
Типа того:
   rs := CreateOleObject('ADODB.Recordset');
   rs.CursorLocation := adUseServer;
   rs.Open(cSql1, cnn, adOpenKeyset, adLockOptimistic); 

Или речь про еще какие-то возможности ADODB?
5 дек 19, 16:08    [22033323]     Ответить | Цитировать Сообщить модератору
 Re: Провайдер SQLOLEDB - есть ли ограничение объем выбираемых данных?  [new]
Dimitry Timokhov
Member

Откуда: Москва
Сообщений: 71
Wlr-l,

Благодарю! Обязательно посмотрю.
5 дек 19, 16:09    [22033327]     Ответить | Цитировать Сообщить модератору
 Re: Провайдер SQLOLEDB - есть ли ограничение объем выбираемых данных?  [new]
Dimitry Timokhov
Member

Откуда: Москва
Сообщений: 71
Интересный факт: если в самом запросе сделать касты строк до меньших размеров, то ADODB+SQLOLEDB переваривает это.

Т.е. можно сделать вывод, что в момент обработки SQLOLEDB полагается на размеры строк, которые ему выдает запрос - сказал запрос, что тип поля varchar(8000), значит временно резервируем 8000. Когда уже отдает клиенту, конечно, обрезает до реального размера.
5 дек 19, 16:12    [22033332]     Ответить | Цитировать Сообщить модератору
 Re: Провайдер SQLOLEDB - есть ли ограничение объем выбираемых данных?  [new]
Dimitry Timokhov
Member

Откуда: Москва
Сообщений: 71
Wlr-l,


Wlr-l
в. Перейти на новую версию драйвера OLE DB:

https://docs.microsoft.com/en-us/sql/connect/oledb/oledb-driver-for-sql-server?view=sql-server-ver15

3. Microsoft OLE DB Driver for SQL Server (MSOLEDBSQL)


Что интересно:
1. По памяти MSOLEDBSQL более прожорливый (при постепенно увеличении результата перестает работать раньше, чем SQLOLEDB).
2. Но зато быстрее процентов на 10%.

Спасибо. Буду думать, переходить или нет. Как понял, его ставить надо отдельно (у меня Win-10 64, а не было установлено).
5 дек 19, 16:33    [22033356]     Ответить | Цитировать Сообщить модератору
 Re: Провайдер SQLOLEDB - есть ли ограничение объем выбираемых данных?  [new]
court
Member

Откуда:
Сообщений: 1956
Dimitry Timokhov
Или речь про еще какие-то возможности ADODB?
например, про adAsyncFetch
5 дек 19, 16:51    [22033373]     Ответить | Цитировать Сообщить модератору
 Re: Провайдер SQLOLEDB - есть ли ограничение объем выбираемых данных?  [new]
Dimitry Timokhov
Member

Откуда: Москва
Сообщений: 71
court
Dimitry Timokhov
Или речь про еще какие-то возможности ADODB?
например, про adAsyncFetch


После упоминания adAsyncFetch, я подумал - а что я им не пользуюсь то?
Покопался в своих архивах. Нашел. Проверил. Так и есть.

В случае, когда Connection.CursorLocation := adUseClient (а у меня именно так) опция adAsyncFetch принципиально ничего не меняет. Все равно Recordset грузится в итоге полностью, пусть и не сразу.

Я пробовал сделать Recordset.CursorType равным adOpenForwardOnly. Может тогда асинхронность сыграет (что прочел уже в памяти не нужно)?
Но свойство Recordset.CursorType становится в итоге adOpenStatic. И никак иначе согласно https://docs.microsoft.com/en-us/sql/ado/reference/ado-api/cursortype-property-ado?view=sql-server-ver15 (см. второй абзац в Remarks). Т.е. Recordset в памяти оказывается целиком (иначе как по нему можно лазить вперед-назад?).

К тому же adAsyncFetch бесполезна, когда в запросе много фунционального кода (while, if и пр. TSQL) - все равно этот кусок должен выполниться полностью. Асинхронность начинает работать только на SELECT.
6 дек 19, 14:17    [22034232]     Ответить | Цитировать Сообщить модератору
 Re: Провайдер SQLOLEDB - есть ли ограничение объем выбираемых данных?  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 49572
Dimitry Timokhov
Распечатать шрифтом size=5 и сдать в архив 20 кг макулатуры. Не вариант?

Вариант, конечно, но программисту, который для этой задачи использует "CursorLocation := adUseClient" надо руки отрывать ибо не ведает он что творит. Для этой задачи используются однонаправленные курсоры без кэширования.
6 дек 19, 14:50    [22034282]     Ответить | Цитировать Сообщить модератору
 Re: Провайдер SQLOLEDB - есть ли ограничение объем выбираемых данных?  [new]
Dimitry Timokhov
Member

Откуда: Москва
Сообщений: 71
Dimitry Sibiryakov
Dimitry Timokhov
Распечатать шрифтом size=5 и сдать в архив 20 кг макулатуры. Не вариант?

Вариант, конечно, но программисту, который для этой задачи использует "CursorLocation := adUseClient" надо руки отрывать ибо не ведает он что творит. Для этой задачи используются однонаправленные курсоры без кэширования.


Руки отрывать никому не надо.
1. До сей поры запросы были под моим чутким контролем - они не большие по объему.
2. Сейчас тестирую библиотеку в встроенном в нашу систему скриптовом языке по генерации запросов к БД.
3. Решил проверить ее на "а слабо?".
4. Получил не ошибку или долгий запрос, а глухое зависание.
5. С этим и разбираюсь. Ибо для разработчика хуже нет, чем глухое зависание - ни словечка от системы, что что-то не так.

Но общий вывод полезный. Обсужу с серверменом, почему мы изначально не пользуемся серверными курсорами (Вы же про серверные курсоры говорите, когда говорите "однонаправленные курсоры"?).


PS В действительности, разобрался. Возможно ретрограду, типа меня, будет полезно. См. вложение.
Краткое описание:
Данный пример демонстрирует следующий негативный эффект провайдера SQLOLEDB (и более нового MSOLEDBSQL):
  • В 32-х битном приложении (у меня Delphi2007).
  • При использовании 3Гб памяти (т.е. при наличии флага {$SetPEFlags $0020}).
  • С клиенским курсором (т.е. когда Connection.CursorLocation := adUseClient).
для некоторых запросов выполнение уходит в глухой завис (игнорируется AdoDb.Command.CommandTimeout).

Причем, такое происходит для любых способов обращения к данным AdoDb.Recordset:
  • Синхронно/Асинхронно.
  • Получение данных через MoveNext/GetRows.


К сообщению приложен файл (AdoDbFetchingTest.zip - 16Kb) cкачать
6 дек 19, 15:03    [22034303]     Ответить | Цитировать Сообщить модератору
 Re: Провайдер SQLOLEDB - есть ли ограничение объем выбираемых данных?  [new]
4d_monster
Member

Откуда: Москва
Сообщений: 1615
Dimitry Timokhov
Я пробовал сделать Recordset.CursorType равным adOpenForwardOnly. Может тогда асинхронность сыграет (что прочел уже в памяти не нужно)?
Но свойство Recordset.CursorType становится в итоге adOpenStatic.

В документации сказано:
Microsoft
Static cursor Provides a static copy of a set of records for you to use to find data or generate reports; always allows bookmarks and therefore allows all types of movement through the Recordset. Additions, changes, or deletions by other users will not be visible. This is the only type of cursor allowed when you open a client-side Recordset object.

Т.е. он и так Static из-за CursorLocation := adUseClient. Разве нет?
6 дек 19, 15:05    [22034306]     Ответить | Цитировать Сообщить модератору
 Re: Провайдер SQLOLEDB - есть ли ограничение объем выбираемых данных?  [new]
Dimitry Timokhov
Member

Откуда: Москва
Сообщений: 71
4d_monster,
4d_monster
Т.е. он и так Static из-за CursorLocation := adUseClient. Разве нет?


Да я и не спорю. Так я это и написал. Возможно, мутно выразился.

Я к тому, чтобы пояснить, что коллега
court
например, про adAsyncFetch

упомянул про adAsyncFetch. А я говорю, что все равно роусет будет Static - с асинхроном или без. Все равно он в памяти окажется. Т.е. асинхрон не уменьшает потребность в памяти. И, если ее в синхроне не её хватало, то и в асинхроне не хватит.

Сообщение было отредактировано: 6 дек 19, 15:12
6 дек 19, 15:10    [22034310]     Ответить | Цитировать Сообщить модератору
 Re: Провайдер SQLOLEDB - есть ли ограничение объем выбираемых данных?  [new]
Wlr-l
Member

Откуда:
Сообщений: 512
Dimitry Timokhov
Wlr-l,


Wlr-l
в. Перейти на новую версию драйвера OLE DB:

https://docs.microsoft.com/en-us/sql/connect/oledb/oledb-driver-for-sql-server?view=sql-server-ver15

3. Microsoft OLE DB Driver for SQL Server (MSOLEDBSQL)


Что интересно:
1. По памяти MSOLEDBSQL более прожорливый (при постепенно увеличении результата перестает работать раньше, чем SQLOLEDB).
2. Но зато быстрее процентов на 10%.

Спасибо. Буду думать`, переходить или нет. Как понял, его ставить надо отдельно (у меня Win-10 64, а не было установлено).


SQLOLEDB был разработан для 2000 сервера. Но, как только он стал частью Windows XP, его перестали адаптировать под новые версии SQL Server, а вместо него стали использовать нативные провайдеры второго поколения 9, 10, 11.

MSOLEDBSQL, действительно, работает быстрее, даже нативных провайдеров второго поколения. Может он и требует больше памяти в приложении, но меньше нагружает SQL Server, что гораздо важнее (монитором можно посмотреть как выполняется запрос на изменение данных с использованием одного и другого провайдера).
Главное, он поддерживает все типы данных 2017 (2019 пока не рассматривали). Попробуйте, например, в ХП указать параметр типа date и передать в него дату из приложения. В случае SQLOLEDB дата будет преобразована в строку "гггг-мм-дд", которую ХП не воспримет как дату. Для нас это более важно; миллионы строк для десятка килограмм макулатуры уже ушли в далекое прошлое.
Да, этот провайдер должен устанавливаться отдельно, так как для 2017 рекомендуется ODBC.

И последнее, DBGrid, например, умеет брать от сервера столько строк, сколько помещается на экране, а не вытягивает сразу все строки. А вы все еще теоретизируете. Мне тоже не понятно, зачем по миллионам строк "лазить вперед-назад", да и "в запросе много функционального кода (while, if и пр. TSQL)" смущает.
6 дек 19, 15:56    [22034375]     Ответить | Цитировать Сообщить модератору
 Re: Провайдер SQLOLEDB - есть ли ограничение объем выбираемых данных?  [new]
Dimitry Timokhov
Member

Откуда: Москва
Сообщений: 71
Wlr-l,

Насчет MSOLEDBSQL спасибо. Действительно полезная информация. Ибо я на тип date пока "забил". Как раз из-за тог, что даты там в виде строки. Деталей не помню, но вот, что написано у меня в комментах "при возврате в Delphi ADODB возвращает тип [date] как varOleStr в виде '2018-01-01'. Эта проблема на момент написания комментария решена не была."

Насчет DBGrid. Он это делает через серверный курсор. Сам по себе DBGrid делать ничего не умеет в части загрузки видимой части. Я смотрел DBGrid от Delphi2007 и какой-то более поздний (точно не скажу). Такая частичная загрузка работает только для серверных курсовров (Connection.CursorLocation := adUseServer).
А у нас adUseClient. Возможно, стоит посмотреть на серв. курсор. Но, согласитесь, в системе возраста 20 лет, над этим надо шибко сильно думать.
6 дек 19, 16:14    [22034399]     Ответить | Цитировать Сообщить модератору
 Re: Провайдер SQLOLEDB - есть ли ограничение объем выбираемых данных?  [new]
Dimitry Timokhov
Member

Откуда: Москва
Сообщений: 71
Wlr-l
Да, этот провайдер должен устанавливаться отдельно, так как для 2017 рекомендуется ODBC.

Вот! Об этом спросить хотел!
Направьте, пожалуйста, куда смотреть, чтобы изучить тему ODBC?
Хорошо бы, конечно, под Delphi, но можно и иначе.
6 дек 19, 16:15    [22034403]     Ответить | Цитировать Сообщить модератору
 Re: Провайдер SQLOLEDB - есть ли ограничение объем выбираемых данных?  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30825
Dimitry Timokhov
aleks222
В ADODB есть методы получения "дохера и более строк" кусками.

Сам ADODB ничего не умеет. он пользуется серверными курсорами, которыми мы не пользуемся.
Если речь, конечно, идет про CursorLocation и adUseServer?
Так используйте.

Никаких проблем не было получать из запроса миллиард записей, с момента появления ADO, но вы явно читаете всё в память, из за каких то неправильных настроек.
Из настроек я вижу только "cnn.CursorLocation := $00000003{adUseClient};", и "rs.Open(cSql1, cnn, adOpenKeyset, adLockOptimistic)"

Зачем они?

Понятно, что если вы указываете, что курсор клиентский, и что вам нужно лазить по записям туда-сюда, то вы тем самым говорите, "Оледиби и Адо, дорогие, не давайте мне записи порциями с сервера, скачайте как мне их в память".

Уберите строку с cnn.CursorLocation, и у rs.Open оставьте параметр курсора по умолчанию, и всё будет нормально.
6 дек 19, 20:12    [22034579]     Ответить | Цитировать Сообщить модератору
 Re: Провайдер SQLOLEDB - есть ли ограничение объем выбираемых данных?  [new]
Dimitry Timokhov
Member

Откуда: Москва
Сообщений: 71
alexeyvg,

1. Когда начинал топик, то был в полном замешательстве.
Закончил тем, что показал, что в провайдерах SQLOLEDB и MSSELOLESQL есть ошибка при работе с клиентскими курсорами при работе в 32-разрядных приложениях с флагом PE, который позволят использовать 3гб (вместо 2гб) оперативной памяти флагом. Оформил соотв. ключевыми словами. Возможно, кому-то полезно будет.

2. В общем то у меня нет проблем с большими данными. У меня все порции данных маленькие - забрал, обработал, измененное вернул. Конкретно исходный большой запрос был тестовым. Можно сказать, случайным.

3. По части rs.Open без параметров. Действительно, берет любые миллионы записей. Интересно чисто технически - как это сделано? Очевидно, что это серверный курсор. Но почему профайлер ничего не показывает? Только "select * from t". Может, знаете? Спасибо.
7 дек 19, 00:37    [22034684]     Ответить | Цитировать Сообщить модератору
 Re: Провайдер SQLOLEDB - есть ли ограничение объем выбираемых данных?  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 49572
Dimitry Timokhov
Обсужу с серверменом, почему мы изначально не пользуемся серверными курсорами (Вы же про серверные курсоры говорите, когда говорите "однонаправленные курсоры"?)

Ты думаешь я дизлексик и говорю не то, что говорю?
https://docs.microsoft.com/en-us/sql/relational-databases/cursors?view=sql-server-ver15
Forward-only

A forward-only cursor is specified as FORWARD_ONLY and READ_ONLY and does not support scrolling.

Если ты программируешь на Delphi, то RTFM TDataSet.Unidirectional.
7 дек 19, 14:35    [22034815]     Ответить | Цитировать Сообщить модератору
 Re: Провайдер SQLOLEDB - есть ли ограничение объем выбираемых данных?  [new]
Dimitry Timokhov
Member

Откуда: Москва
Сообщений: 71
Dimitry Sibiryakov,

Дмитрий, я вижу. ты разбираешься в ADO.
Можешь объяснить, как технически сделана связка CursorLocation=adUseServer/CursorType=adOpenForwardOnly?
Сначала пример:
var
   fCnn, fRS: OleVariant;
begin
   fCnn := CreateOleObject('ADODB.Connection');
   fCnn.CursorLocation := $00000002{adUseServer};
   fCnn.Open('Provider='+cProvider_MSOLEDBSQL+';Server=<server>;Database=<db>;Trusted_Connection=Yes;Application name=test1');

   fRS := CreateOleObject('ADODB.Recordset');
   fRS.ActiveConnection := fCnn;
   fRS.Open(Source := 'select 1234 as [fld]'

// В профайлере только "select 1 as [fld]"
//      , CursorType := $00000000{adOpenForwardOnly}

// В профайлере есть обращение к "sp_cursorfetch" и CursorOpen
//      , CursorType := $00000001{adOpenKeyset}
//      , CursorType := $00000002{adOpenDynamic}
//      , CursorType := $00000003{adOpenStatic}
   );

   while not fRS.Eof do
   begin
      ShowMessage(fRS.Fields['fld'].Value);
      fRS.MoveNext;
   end;
end;


При работе через CursorType = adOpenKeyset/adOpenDynamic/adOpenStatic профайлер показывает, что это сделано через сист. проц. sp_cursorfetch и CursorOpen.

При работе через CursorType=adOpenForwardOnly в профайлере есть только select 1234 as [fld] и всё (в профайлере включены события OLEDB и Cursor - там пусто!).

Как же так, ведь сказано, что fCnn.CursorLocation := $00000002{adUseServer}!!! Значит должна быть работа с курсором!

Как в случае использования связки adUseServer+adOpenForwardOnly OLEDB использует серверный курсор, если нет обращений к серверу по части курсоров?

Объясни, если можешь. Собственно этот необъяснимый вопрос и не позволил мне в 2000 году начать использовать adUseServer+adOpenForwardOnly вместо текущих adUseClient+adOpenStatic.
7 дек 19, 15:38    [22034830]     Ответить | Цитировать Сообщить модератору
 Re: Провайдер SQLOLEDB - есть ли ограничение объем выбираемых данных?  [new]
invm
Member

Откуда: Москва
Сообщений: 9128
Dimitry Timokhov,

Для adOpenForwardOnly не требуется обеспечивать навигацию по курсору. Поэтому курсор на стороне сервера, которым и реализуется навигация, не нужен.
7 дек 19, 16:43    [22034854]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить