Добрый день!
Столкнулись со следующей проблемой в ADO.Net.

Есть таблица на SQL сервере, для простоты - одна таблица. В настоящее время она занимает 61Мб.
При загрузке этой таблицы в DataTable "съедается" ровно 160 Мб (а если использовать DataSet и DataTable, то немножко побольше - 168Мб). В дальнейшем эта таблица грузится не в стандартный DGV, а в самописный контрол, к-росто летает (очень быстро скроллирует и перемещается по таким большим данным). НО уже сейчас у программы начинаются проблемы (нехватка памяти), а в дальнейшем таблица будет только расти.

Одна из задач программы - показать все данные сразу (так удобнее работать клиенту, и так работают программы у конкурентов). Т.н. "paging" (как на интернет-форумах - показывать постранично, с кнопками "следующая страница", "предыдущая страница", и т.п.) нельзя использовать, т.к. неудобно пользоваться.

В то же время, MS Sql 2k5 Management Studio, написанная также на C# и Ado.Net, легко справляется с подобными данными, и даже гораздо большими. Например, полное открытие (не select * from table, а именно right click on table -> open table) открывает всю таблицу, используя 12Мб ОЗУ, а когда мы проскроллим всю эту таблицу до самого конца, у нас будет израсходовано еще столько же - 12Мб ОЗУ.

Таким образом, если мы по-простому (как в учебнике ADO) открываем таблицу, то расходуется 160Мб, а SQL Management Studio на это же действие расходует всего лишь 12-24Мб. Есть предположения, как она это делает?

И вопрос в догонку - почему с#, framework, ado.net не используют виртуальную память, а вылетают с исключением "Out of memory"? Может, настройка такая есть?

Что значит "XML наше все"? Прокомментируйте.

Что касается фильтров = конечно же, они есть. Я не говорю, что пользователю отображается вся таблица, я сказал "вся таблица грузится в память". Грузится для того, чтобы пользователь одновременно мог наложить любое количество фильтров и отобразить любое количество вкладок с данными. Таким образом, таблицу мы загружаем в память один раз, а показываем уже либо всю, либо фильтрованные части. И при наложении каждого нового фильтра память уже не расходуется.

Уважаемые, но ведь SQL Server Management Studio успешно работает, и быстро, и с большими (гораздо большими, чему у меня) объемами! Вопрос - как она это делает?

Вообще, идея насчет виртуального режима интересная. Данные у нас лежат сейчас в xml на жестком диске, но можно сделать и dbf, и mdb, и даже SQL Compact CE.

Только вот еще задача: должна поддерживаться сортировка. Виртуальный режим позволит применять сортировку таблицы?

Спасибо за наводку на виртуальный грид!

Теперь я знаю на 100%: в SQL Management Studio именно так и реализовано.
Теперь память не "съедается", максимум - 26Мб, и работает все быстро.

Хороший пример здесь: http://msdn.microsoft.com/ru-ru/library/ms171625.aspx
Пример использует базу Nortwind, но не заточен под нее, будет работать с любой другой таблицей, где первый столбец - уникальный ключ. Сотня тысяч строк - и все летает (ну насколько стандартный dgv вообще может летать...).

Вроде бы решили задачу: поставили SQL CE, сунули в него эту большую таблицу. Нарисовали грид в виртуальном режиме - все бы замечательно. Но, как Вы знаете, существует не так много способов организации PAGING (постраничная выборка) при использовании MS Sql.

Учитывая что SQL CE не умеет работать с row_number и не умеет делать set rowcount, этих способов остается еще меньше - два или три. При этом на 60 тыс. записей возникает следующая проблема = первые страницы возвращаются быстро, чем дальше - тем медленнее, последние страницы вообще еле-еле ворочаются :(

Модератор: Тема перенесена из форума "C#.NET".