Здравствуйте!

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.

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

Подробнее:

1. Моё окружение: Windows10 64 бита, 16гб оперативки, SQL2012, Delphi2007 (т.е. 32 бита), ADODB используется как OLE через позднее связывание (т.е. не используются стандартные библиотеки Delphi).
Вот пример:



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 бита, а не держаться за старые версии.

aleks222,


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


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


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


Или речь про еще какие-то возможности ADODB?

Wlr-l,

Благодарю! Обязательно посмотрю.

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

Т.е. можно сделать вывод, что в момент обработки SQLOLEDB полагается на размеры строк, которые ему выдает запрос - сказал запрос, что тип поля varchar(8000), значит временно резервируем 8000. Когда уже отдает клиенту, конечно, обрезает до реального размера.

Wlr-l,




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

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

После упоминания 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.

Руки отрывать никому не надо. 1. До сей поры запросы были под моим чутким контролем - они не большие по объему. 2. Сейчас тестирую библиотеку в встроенном в нашу систему скриптовом языке по генерации запросов к БД. 3. Решил проверить ее на "а слабо?". 4. Получил не ошибку или долгий запрос, а глухое зависание. 5. С этим и разбираюсь. Ибо для разработчика хуже нет, чем глухое зависание - ни словечка от системы, что что-то не так. Но общий вывод полезный. Обсужу с серверменом, почему мы изначально не пользуемся серверными курсорами (Вы же про серверные курсоры говорите, когда говорите "однонаправленные курсоры"?). PS В действительности, разобрался. Возможно ретрограду, типа меня, будет полезно. См. вложение. Краткое описание: Данный пример демонстрирует следующий негативный эффект провайдера SQLOLEDB (и более нового MSOLEDBSQL):

• В 32-х битном приложении (у меня Delphi2007).
• При использовании 3Гб памяти (т.е. при наличии флага {$SetPEFlags При использовании 3Гб памяти (т.е. при наличии флага {$SetPEFlags $0020}).20}).
• С клиенским курсором (т.е. когда Connection.CursorLocation := adUseClient).

для некоторых запросов выполнение уходит в глухой завис (игнорируется AdoDb.Command.CommandTimeout). Причем, такое происходит для любых способов обращения к данным AdoDb.Recordset:

Синхронно/Асинхронно. Получение данных через MoveNext/GetRows.

4d_monster,


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

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

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

Wlr-l,

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

Насчет DBGrid. Он это делает через серверный курсор. Сам по себе DBGrid делать ничего не умеет в части загрузки видимой части. Я смотрел DBGrid от Delphi2007 и какой-то более поздний (точно не скажу). Такая частичная загрузка работает только для серверных курсовров (Connection.CursorLocation := adUseServer).
А у нас adUseClient. Возможно, стоит посмотреть на серв. курсор. Но, согласитесь, в системе возраста 20 лет, над этим надо шибко сильно думать.

Вот! Об этом спросить хотел!
Направьте, пожалуйста, куда смотреть, чтобы изучить тему ODBC?
Хорошо бы, конечно, под Delphi, но можно и иначе.

alexeyvg,

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

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

3. По части rs.Open без параметров. Действительно, берет любые миллионы записей. Интересно чисто технически - как это сделано? Очевидно, что это серверный курсор. Но почему профайлер ничего не показывает? Только "select * from t". Может, знаете? Спасибо.

Dimitry Sibiryakov,

Дмитрий, я вижу. ты разбираешься в ADO.
Можешь объяснить, как технически сделана связка CursorLocation=adUseServer/CursorType=adOpenForwardOnly?
Сначала пример:



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

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

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

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

Объясни, если можешь. Собственно этот необъяснимый вопрос и не позволил мне в 2000 году начать использовать adUse Server +adOpenForwardOnly вместо текущих adUse Client +adOpenStatic.

alexeyvg,

У меня Profiler от 2012. Там нет Extended Events.

Спасибо. Я реально начал понимать что-то про связку adUseServer+adOpenForwardOnly.
Действительно, есть повод задуматься об её использовании, когда надо распечатать 20кг бумаги (это реально бывает - на электронный архив только переходим).

Для обычной работы adUseClient+adOpenStatic достаточно - там маленькие и аккуратненькие запросы с небольшим выводом.

Коллеги, спасибо всем. Реально разобрался!