ГриняЕсть база на серваке.

ДатаСет - это некая мобильная база в оперативных мозгах компа. Так вот вопрос , какой объем данных допустимо закачивать в ДатаСет, например на серваке есть таблица где примерно 50 000 записей и 10 полей.

Что будет если для закачки данных в Датасете исчерпается вся оперативная память? Свопиться на винт будет?

Половина полей текстовые , половина int. Есть ли смысл писать хранимки на сервере , запросы и прочую ботву или качать это на локальные компы и обрабатывать локально. Для меня было бы проще написать обработку и выборку данных уже из датасета через Датавью.

Компы мощные пни 4 , 3 ГигаГерц процы и 512 метров памяти? Сетка хорошая и гари на 100 мегабит. Кол-во клиентов юзеров, чуть больше 30 ...

Жду мнения гуру. С объемом данных проблем нет. С обработкой - как напишите.
Только помните, что
1 во многом вы берете на себя работу сервера базы данных
2 DataSet - это не "некая мобильная база в оперативных мозгах компа" поэтому:
3 Из набора "хранимки на сервере , запросы и прочую ботву " в DataSet можно закачать далеко не все.

Перед проектированием рекомендую подумать как вы будете обрабатывать конкурентные изменения одних данных разными пользователями. Это то, что в статье от AiSK написано в разделе Синхронизация данных с сервером

ИМХО: модель briefcase имеет смысл использовать, когда существует необходимость работы пользователей с данными, а непосредственная связь с сервером БД отсутствует. Как только она (связь) появляется, лучше переходить на обычный клиент-сервер

Гриня
А я и делаю в обычной архитектуре клиент-сервер.
Нет, вы скорее пытаетесь создать что-то похожее на файл-сервер. Все данные идут к клиенту, он с ними что-то делает, затем данные отправляются к серверу. Конфликты данных, к-е получались при такой работе с увеличением числа пользователей, которое произошло с развитием сетей - это одна из основных причин появления КС
Гриня
Конфликты при редактровании записей на серваке разными пользователями могут быть , но вот как их обойти? Использовать блокировку записей средствами АДО.НЕТ ? Не могут быть, а будут. Как их обходить - решать вам. Использовать блокировку записей средствами АДО.НЕТ - это хорошее решение.

Понимаете, вы пытаетесь применить технологию отсоединенных данных там, где в этом нет необходимости. Она нужна когда физически нет доступа к серверу. Пользователь взял laptop, и уехал в командировку. Мерчендайзер взял наладонник и поехал по торговым точкам. И т.д. Именно для этого данная технология и нужна и так работа с ней и позиционируется. О чем и говорится в приведенной выше статье
Требования бизнеса по обеспечению работы мобильных пользователей http://www.rsdn.ru/article/db/briefcase1.xmlСоздание программного обеспечения, позволяющего пользователям работать лишь в пределах офиса, на сегодняшний день становится явно недостаточно. Сотрудникам офиса требуется обеспечить доступ к информационным массивам фирмы в командировке, из дома, из офиса клиента . При этом пользователи хотят не только просматривать данные, но и иметь возможность вносить в них изменения.Мой вам совет - если не хотите работать с "чистым SQL" посмотрите в сторону Data Binding. Ado.Net отлично развит в этом направлении. Таким образом вы и обработку сделаете через DataSet, DataTable, DataView etc (как вы хотите) и данные лишний раз перекачивать не будете. И с блокировками разберутся Ado.net и SQL Server

Начать следует с чтения MSDN и поиска примеров.
Наберите в любом поисковике ".Net Data Binding Windows Forms"

Например
http://www.devhood.com/tutorials/tutorial_details.aspx?tutorial_id=633

http://www.akadia.com/services/dotnet_databinding.html

http://www.codeproject.com/vb/net/databindingconcepts.asp