Здравствуйте, Nikolay_P_I, Вы писали:
N_P>Библиотеки, которыми я пользуюсь для решения этой задачи (как раз пейджинг и реализуют) есть только под C# ADO.NET.
А твое приложение что, для доступа к БД использует и другие фреймворки, кроме ADO.NET? Я все еще не вижу проблемы.
N_P>Так проблема в том, что никто не знает времени исполнения произвольного запроса до его исполнения. Мы не можем настроить правильный таймаут заранее. Мы можем сделать его разумно большим, но в этом — свои неприятности. Подробнее — ниже.
Если для выполнения запроса СУБД нужен час, то таймаут для этого запроса должен быть не меньше часа. По-моему это очевидно. Для большинства запросов таймаут вообще не стоит ставить. Таймаут ставят там, где гарантированное время отклика важнее даже получения результата.
N_P>Именно этот вариант сейчас в работе. Правда, на сторонних библиотеках. Есть ли варианты кроме пейджинга? Какие есть варианты read only forward only paging?
Альтернатива — просто выполнить запрос и читать строки результата такими порциями, как тебе удобно.
N_P>Проблема — управляемое чтение больших массивов данных. Не в смысле количества байт, а в смысле числа строк. И мне показалось изначально разумным, что все сразу мы не получим и запрос будет разбит на подзапросы. Именно из-за требования больших таймаутов для исполнения большого запроса.
OK, если проблема в таймауте, убери таймаут совсем и нет проблемы.
N_P>Потому что практика показывает, что большой таймаут несет проблемы с реакцией оператора (не только в GUI), трудностями в отмене операции, трудностями в реагировании на сбои (понять, что отвалился сервер желательно как можно раньше, а у нас таймаут — час), трудностями с блокировкой ресурсов БД и отъеданием ресурсов сервера БД.
Это все общие слова. Приведи конкретный сценарий (не надуманный) с конкретной проблемой, можно обсудить.
Насчет "отвалился сервер". Еще раз — если запрос выполняется час, значит нужно ждать час, ничего с этим не поделаешь (кроме оптимизации). И не нужно мешать серверу таймаутами. Понимать "как можно раньше" — это не твоя задача, как разработчика; это задача DBA. И у них есть свои инструменты для этого. Некоторые СУБД даже предоставляют API для отслеживания прогресса выполнения конкретных "долгоиграющих" запросов. Но они опять же, для админов.
На этапе же выборки результата управление полностью на твоей стороне и вышеописанных проблем нет.
N_P>Курсоры, как учат нас книги и интернет — вселенское тормозное зло. Что применять?
