Создал в SQL Server свой View, который отображает данные из нескольких таблиц + виртуальные поля созданные запросом(такие как Sum и Count)
Как мне отобразить его в DataGridView? 
Или может я выбрал не правильный подход...

Moid, так же, как и таблицу. Не считая некоторых нюансов, на уровне sql-запроса View равносильно таблице.

Idsa,  Не совсем понятно...
Как вариант рассмотрел следующее, тогда и использование вью опадает: тот запрос что выполняется во View выполнить и заполнить свой DataTable, затем привязать его к DataGridView.

Вам не нужно думать о том, какой запрос выполняется во View. Используйте ее как обычную таблицу.

Еще момент: можно ли в запрос View подставить програмно значения переменных, как к примеру это можно сделать при заполнении таблицы методами из xsd.
Если нет, то в принципе тогда и отпадает нужда использовать View, а формировать запрос через строку.

Нет, нельзя. Используйте голые запросы или хранимые процедуры.

Idsa, спасибо... тогда тема закрыта.

В чем проблемма, VIEW эта та же таблица.


и потом так:


или я что то не так понял?

Это сообщение отредактировал(а) MasterOfCode - 19.11.2008, 14:10

MasterOfCode, http://databases.aspfaq.com/database/shoul...d-function.html

Т. е. мы не может сделать select from SomeView(@param1, @param2...).


Допустим, нам нужно сделать View, выбирающую определенный диапазон значений.

Такой запрос во View не прокатит. Получается, отсеивать значения нужно во внешнем относительно View запросе, как в Вашем примере. Во-первых, это неудобно. Гораздо удобнее воспользоваться table-valued function:

Во-вторых, возможны проблемы с производительностью: ведь мы сначала считываем все значения View, а только потом отбираем нужные. Хотя, наверное, современные оптимизаторы запросов это дело красиво разруливают.
Если предыдущее утверждение насчет производительности, скорее всего, неактуально... есть еще один вариант. Зачастую View используются для того, чтобы ограничить доступ пользователей к таблицам, атрибутам и т. д. Допустим, DBA хочет, чтобы пользователь мог получить информацию только по одному пользователю. Через вьюху этого не сделаешь, т. к. она возвращает все данные. А если в таблице 20 миллионов записей? Так неопытный "писун" прикладного приложения может повесить сервак, если не добавит надлежащих ограничений в where.
Таких примеров можно напридумывать кучу (фантазия у меня - дай Бог  ).

Это сообщение отредактировал(а) Idsa - 19.11.2008, 14:51

немного не понял... это как по одному пользователю?

Это я говорил о воображаемой таблице Users, к которой используется запрос:

Ну дак понятно. Для этого и существует возможность фильтровать вьюшку в запросе 
У нас тут почти все на вьюшках построенно. И работает я скажу без потери производительности, хотя я не проверял, но не скажу что долго.
Что это за база такая которая повиснет при выборе 20 млн записей? какая нибудь настольная, но если у тебя есть 20млн записей, то имхо нужно что то по серьезнее использовать 

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

Теперь посмотрим, как это можно реализовать черзе table-valued function, внутрь которой уже заложена логика по отбору пользователей по дате регистрации:

Удобнее, неправда ли?
Это я все к тому, что порой действительно удобнее инкапсулировать логику отбора в table-valued function, нежели приписывать ее к внешнему where к View.

Это сообщение отредактировал(а) Idsa - 20.11.2008, 19:50

Я бы использовал between в условии.


Только визуальнее. А внутри у этой функции тот же самый between 
Если бы view можно было принимать параметры - это было бы не view.  Если тебе удобнее писать так. То не кто не запрещает. 

Мне вот интересно, table-valued function можно связать join'ом например с другими таблицами? 

Можно.