Чуток отрефакторил

МСУP.S. Неполный список перлов от Севы:

1. Membership - это зло
2. Pricipal более продвинутый и гибкий вариант,к нему может быть прикручен любой метод и свойства
3. Пейджинг - это зло
4. "Пейджинг - штука нужная , но только не в шаловливых ручонках"
5. Грязное чтение - грязные данные, первый признак кривизны решения
6. Count делаем с грязным чтением ,но всегда ограничиваем по кол-ву там, где могут быть большие объемы.

Самый главное для Севы: пожелание Изопропила

SeVaMCУ, заглядывай хотя бы иногда в профайлер. Много узнаешь нового. Попроси Изоприла еще тебе ликбез устроить.
Сева, не поверите, только с ним и работаю.

P.S. Вам совет на будущее: когда будет что сказать по теме обсуждаемого вопроса, говорите, не стесняйтесь. Вообще, у Вас отличные ответы, грамотные, толковые. Но не хватает всего-лишь одного - аргументов

P.S2. Ладно, дитя порока, оставляю Вас наедине в Вашей убогой тупостью. Читайте буки и маны, после - приходите ко мне, буду экзаменовать. А пока - садитесь, двойка.

семкиМСУСам запрос - это select top 50
А кол-во записей под пеёджер - это select count(*) from ( select top 50 ) + WHERE

МСУ, я правильно понимаю, что за свою тупость ответить нечего?

Мозгов не хватает понять опечатку, дурень? :)
Это даже в логах всё есть, для таких дятлов как ты и постил

SeVaЕсли ты прочел один букварь это еще не значит, что у всех так.
Если ты прочел один букварь это еще не значит, что у всех так:

МСУP.S. Неполный список перлов от Севы:

1. Membership - это зло
2. Pricipal более продвинутый и гибкий вариант,к нему может быть прикручен любой метод и свойства
3. Пейджинг - это зло
4. "Пейджинг - штука нужная , но только не в шаловливых ручонках"
5. Грязное чтение - грязные данные, первый признак кривизны решения
6. Count делаем с грязным чтением ,но всегда ограничиваем по кол-ву там, где могут быть большие объемы.

Самый главное для Севы: пожелание Изопропила


SeVaКакие фильтры плохие, а какие нет, как происходит выборка по индексам и когда оптимизатор ее не использует - загадка только для тебя.
Загадка для меня не только по поводу "плохих" фильтров (ссылка на определение где?), но и загадка для меня - с какого хрена пейджинг - это зло, грязное чтение - первый признак кривизны решения, Membership - это зло, Pricipal более продвинутый и гибкий вариант, ...

Вы плодите на форуме очень много загадок, верьте мне

buredЛень смотреть профайлер (я по правде и не юзаю LinqDataSource никогда), но у меня подозрение, что он сразу все записи выбирает из БД, а не постранично.
Ну смотря как обрабатывать OnSelecting

buredА пейджинг уже делается на клиенте, как и у других ДатаСорсов.
См. выше

buredу меня подозрение, что он сразу все записи выбирает из БД, а не постранично.
Просто сами логично подумайте - если у Вас табличка в 5 миллионов записей, если выбирать все записи, а потом их "резать" и отдавать на клиента (браузер) - да помножить на количество работающих с этим источником пользователей - то ни один серв не выдержит такого напора.
Поэтому, применяют страничные выборки. А для формирования PageCount нужен второй запрос на Count(*) + WHERE записей.

buredМСУНу смотря как обрабатывать OnSelecting

те же тапки, вид в профиль.

Чего?

P.S. Посмотрите на профайлер в скринах.

buredте же тапки, вид в профиль.
Андрей, там даже болдом выделено:

Кстати, между делом говоря, у меня сам Membership Administrator крутится на LinqDataSource с формированием серверных страничных выборок.
Тестировал на миллионе записей - залил в таблицу ролей. Летает как ветер. Андрюха, зря Вы тянете все данные на сервер приложений и там их режете PageIdnex'ами :)
Для табличек из тыщи записей - да, покатит )

buredя имел в виду, что без Count никак не обойтись.
Разумеется. А я сказал обратное? Но тупые семки мне твердили обратное, типа достаточно одного запроса

P.S. Немного не понял Вас, Андрей. Как понимать это?

buredно у меня подозрение, что он сразу все записи выбирает из БД , а не постранично

buredвсем известно, что стандартный пейджинг GridView осуществляется на клиенте.
В этом плане LinqDataSource ничем не отличается от SQLDataSource.
Еще раз говорю, Вам не нужно отруливать вот этой:
[img=http://i.msdn.microsoft.com/Aa479347.gridview_fg21(en-us,MSDN.10).gif]
фигнёй.
LinqDataSource сам всё это сделает в единственной обработчике селектовки. В этом-то и вся прелесть.

Короче, попробуйте его поюзать, а потом расскажите о впечатлениях :)

Севы
Сынок, почитай про объемы, с которыми люди работают .

МСУP.S. Неполный список перлов от Севы:

1. Membership - это зло
2. Pricipal более продвинутый и гибкий вариант,к нему может быть прикручен любой метод и свойства
3. Пейджинг - это зло
4. "Пейджинг - штука нужная , но только не в шаловливых ручонках"
5. Грязное чтение - грязные данные, первый признак кривизны решения
6. Count делаем с грязным чтением ,но всегда ограничиваем по кол-ву там, где могут быть большие объемы.
7. Если таблица в 5 лимонов записей, то нужно менять структуру

Самый главное для Севы: пожелание Изопропила

SeVaХорошо теперь чукчам. Попробовать апельсин не могут, так хотя бы прочитать можно. Молодец, просвещайся дальше. Посоветуй там свой полный count(*) сделать.
Что, головушка наполнилась лишней извилиной, я смотрю? Нууу, это уже хорошо, с интеллектуальным человеком приятнее говорить, чем с деревом. За годик, думаю, станете интеллектуалом - тогда и будет разговор. А пока - сад, читать на горшке с себе подобными про секционирование.

SeVaПередай от меня привет тюленям и буху.
От кого, от дерева? Они с деревьями не гутарят