Курсоры в ADO.NET или их альтернатива

Идея с разомкнутым доступом данных в ADO.NET, конечно просто замечательная. Но я столкнулся с совсем не веселой проблемой. Суть проблемы: у меня есть огромная таблица (примерно 15,6 миллиардов строк и 218 полей). Задача - как минимум, просматривать эту таблицу в гриде. Соответственно, при попытке заполнения набора данных я получаю сообщение о нехватке оперативной памяти. И как с этим можно жить в .NET.

Если кого-то интересует как я с этим жил раньше, могу ответить. Приложение было написано на Дельфи, и при обращении к этой таблице я оставлял курсор на стороне сервера. Соответственно, чтение из таблицы происходило по мере перемещения в Гриде.

Буду крайне признателен за ответ или ссылку на ответ или пример.

P.S. Для реализации задачи используется VS 2003.

не могу себе представить ситуацию, когда тебе в гриде необходимы все 15 млрд. строк. Чтоб хотя бы бегло просмотреть такой объем глазами тебе потребуется пару лет, кол-во строк должно исчисляться максимум тысячами и то это многовато
так что придумывай условия отбора

А DataReader не подойдет

You can use the ADO.NET DataReader to retrieve a read-only, forward-only stream of data from a database. Results are returned as the query executes, and are stored in the network buffer on the client until you request them using the Read method of the DataReader. Using the DataReader can increase application performance both by retrieving data as soon as it is available, rather than waiting for the entire results of the query to be returned, and (by default) storing only one row at a time in memory, reducing system overhead

см тут

mvictor

не могу себе представить ситуацию, когда тебе в гриде необходимы все 15 млрд. строк. Чтоб хотя бы бегло просмотреть такой объем глазами тебе потребуется пару лет, кол-во строк должно исчисляться максимум тысячами и то это многовато так что придумывай условия отбора

Вопрос состоял не в том чтоб дать мне совет на счет условий, а по теме. А такое количество строк просматривать подряд никто и не собирается. Даже если я достаточно жесткими условиями играничиваю результат, то он переваливает через 500 000, а такое количество в набор данных тоже не загрузится. Более того, сами рабочие станции не отличаются завидной производительностью.

Зенит-чемпион

А DataReader не подойдет

Он конечно, не плохая штука, только не совсем то, что надо. Я уже рассматривал этот вариант и эксперементировал. Слишком много лишнего кода, от написания которого программист избавлен при использовании курсоров на стороне сервера, приходится писать.

Мне уже просто даже интересно, неужели в новой версии ADO.NET не реализовали этой функции?! :(

хочешь динамически подгружай, хочшь предоставь эту возможность пользователю http://www.sql.ru/faq/faq_topic.aspx?fid=105

Попробуй тогда заюзать обычный ADO.

Andrew M

Идея с разомкнутым доступом данных в ADO.NET, конечно просто замечательная. Но я столкнулся с совсем не веселой проблемой. Суть проблемы: у меня есть огромная таблица (примерно 15,6 миллиардов строк и 218 полей). Задача - как минимум, просматривать эту таблицу в гриде. Соответственно, при попытке заполнения набора данных я получаю сообщение о нехватке оперативной памяти. И как с этим можно жить в .NET. Если кого-то интересует как я с этим жил раньше, могу ответить. Приложение было написано на Дельфи, и при обращении к этой таблице я оставлял курсор на стороне сервера. Соответственно, чтение из таблицы происходило по мере перемещения в Гриде. Буду крайне признателен за ответ или ссылку на ответ или пример. P.S. Для реализации задачи используется VS 2003.

ADO и ODBC для создания серверных курсоров использует те же процедуры sp_cursor****, что указаны в пункте 4 вышеозначенной ФАКа. Нет препядствий для создания серверного курсора в ADO.NET через те же процедуры.