Доброго времени суток.
Например.
У меня в DataSet есть две таблицы между ними есть Relation.
В таблице "Товар" поле - "Единицы измерения" связано с полем EdIzmerID Таблицы "Еденицы измерения"
В XtraGrid можно настроить этот Relation, что бы в таблице "Товар" в поле "Единицы измерения" вместо идов подставлялось их наименование?
Я это делал на обыкновенном DataGrid, нужно было дописывать метод Pint.
Подскажите как с XtraGrid?
Заранее благодарю.

Просто составь запрос INNER JOIN вроде.

Есть два варианта решения этой проблемы.

Первый вариант (через дизайнер) - создать repository editor с типом LookupEdit, который настроить на таблицу "Единицы измерения" (в DataSource прописываем таблицу "Единицы измерения", DisplayMember - имя колонки с наименованием ед. измерения, ValueMember - имя колонки с Id единицы измерения),тогда грид всё сделает сам.

Второй вариант - через код. Пишем где-нибудь в OnLoad-е:



здесь myGridColumn - колонка с айдишником единицы измерения. Класс "ФорматтерЕдиницИзмерения" (да, можно и по-русски ) будет примерно такого содержания:



Можно к примеру передать в конструктор форматтера ссылку на датасет, и в Format() делать запрос к таблице датасета типа:

Добавлено @ 16:39
З.Ы. всё это есть в примерах для DevExpress.

Спасибо огромное за советы.
Буду пробовать.
Я дядя взрослый (30 лет) но только начинаю изучать SQL Server, С#. До этого и на сегодняшний день программирую на 1С.

Дуда, а зачем же так сложно-то ? Мой вариант ведь куда проще

А ты вопрос внимательней почитай...

Вопрос: Подскажите может есть в SQL Server хранимая процедура которая принимала в качестве параметра название таблицы и возвращала все её Relation? Название или номер поля и с какой таблицей(название) связано?
Я программно получаю название таблицы загружаю её в ДатаСет затем должен получить все таблицы с какими она связана и их тоже подгрузить в этот же ДатаСет.
Первая таблица будет главной и будет редактироваться все остальные таблицы которые подгрузятся в ДатаСет это таблицы с какими первая связана.
Зачем мне это нужно? Я пишу класс который бы дал возможность редактировать все справочники в базе данных.
Может есть у кого на эту тему свои соображения буду благодарен.

Такого понятия как Relation нет в SQL Server-е, вроде.

Взаимосвязи в датасете зависят от того, как построен запрос. Можно трактовать одни и те же таблицы как угодно: например, выбрать все заказы по поставщику, или всех поставщиков по заказу, получая в обоих случаях датасет с двумя таблицами, но разными связями. Это всё к тому, что взаимосвязи по данным обычно задаются отдельно, в виде метаданных (в отдельной таблице, в XSD-файле, прямо в программе или как-нибудь ещё).

P.S.
Модератор: Пожалуйста, один топик - один вопрос.

Первый вопрос был по WinForms, а этот уже в раздел по БД...

Честно говоря, я не понял, чем не подходит мой вариант . Разве что уж совсем не хочется менять структуру датасета

Так вопрос про это и был. Как имея датасет с двумя конкретными таблицами и рилейшном, вывести их на клиенте.

Похожая проблема возникала у меня по ходу работы. Вот есть конкретный датасет, в него загружаются данные через веб-сервис. Необходимо вывести датагрид с колонками, в которых отображается актуальное содержимое. Если есть колонка, связанная с другой таблицей через relation, необходимо вывести её содержимое в приемлемом виде - не ID'шник, а строку или числовое значение, связанное по relation с данной строкой основной таблицы.

Можно взять такие правила за основу: есть форма, выводящая данные. Есть датасет, из которого форма выводит данные. Есть таблица датасета, на которую отображается форма. Эта таблица называется "root table". Все остальные таблицы связаны с корневой по relation, так или иначе.

Предположим, нужно вывести поле-значение из какого-то фиксированного набора (массива). Таблица, содержащая "массив", называется "перечисление", и связана с корневой по relation "многие-к-одному" (потенциально много записей в корневой таблице ссылаются на одну запись в таблице возможных значений перечисления). В гриде выводится не поле Id, а некое другое поле, замещающее числовой айдишник. К примеру, перечисление состоит из 10-ти числовых значений, каждому из которых соответствует строковая константа. Тогда в корневой таблице достаточно завести int-поле, ссылающееся на запись с соответствующим Id в таблице перечисления. Таблица перечисления содержит 2 поля: Id и DisplayName.

Другой use case: если корневая таблица содержит ссылку на некую запись другой таблицы, то в корневой таблице существует поле с типом "ассоциация", содержащее числовой идентификатор записи в другой таблице того же датасета; другая таблица содержит одну или более записей, ID'шники которой соответствуют значениям полей-ассоциаций из корневой таблицы датасета. Это очень просто представить: предположим, есть таблица "заказы" и таблица "клиенты". Каждая запись в таблице "заказы" имеет ID-шник клиента. В приложении нужно показать имя, адрес и телефон клиента, имея только айдишник из корневой таблицы. Это делается элементарно, т.к. большинство современных контролов понимают соотношение "многие-к-одному", каковое и представлено в данном случае (множество заказов могут быть связаны с одним клиентом).

Наконец, допустим в корневой таблице есть поле-коллекция. Это поле связано с таблицей, каждая запись которой содержит ссылку на запись корневой таблицы. Таким образом, получаем соотношение "многие-к-одному" (множество записей из таблицы Х соответствуют одной записи из корневой таблицы). Пример: каждый заказ может иметь множество позиций заказов, где каждая позиция заказа - это отдельная строка в таблице OrderLine, со своими полями (Id товара, кол-во товара, Id клиента, единица измерения и т.п.)

Помимо всего перечисленного, существует ещё возможное отношение "многие-ко-многим", реализуемое через отдельную таблицу "ParentId -> ChildId", с relation'ами к таблицам, связываемым по отношению "м-к-м".

Вот такие вот шишки . А ты говоришь, всё так просто - написал запрос и получил плоскую таблицу, живи не хочу

Усе, понял
Добавлено @ 23:56
Кстати, невольно вспомнился пример отношения "м-к-м": сборки и пространства имен. Одна сборка может содержать много пространств имен, а одно пространство имен, в свою очередь, может быть разбито на несколько сборок

Тоже вариант. Жжош

[/OFFTOPIC]


mr.DUDA, не знаю как ты докатился до такой жизни, но действительно работает


[OFFTOPIC]

Если я правильно понял сам запрос к данным,которые будут в результирующей таблице, формируется отдельно, а связи отдельно.
mr.DUDA если можно ещё о связях, может куски кода как работать с XMLSchema1.xsd файлом ПОЖАЛУЙСТА. В исходниках по XtraGrid есть XML*.xsd файлы но для чего они нужны и как с ними работать не понимаю, хотя догадываюсь что в этом файле можно построить связи всех необходимых таблиц и эти связи будут как XML документ. На каждую таблицу свой файл с связями. Затем в программе подгружать XML*.xsd файл по названию и получать эти связи.
Я что-то такое пробовал

или

XMLSchema1.xsd документе посоздавал аналогичные таблицы с ихними связями.
но что дальше с ним делать не знаю.
Заранее благодарю.

С XSD работать гораздо проще, чем это кажется. Всё "шаманство" можно выразить в трёх действиях:
1) добавляем в проект XSD-файл
2) открыв в дизайнере, добавляем туда таблицы и тянем нужные колонки drag&drop'ом чтоб создать relation-ы
3) в том же дизайнере в контекстном меню ставим галку "Generate DataSet" - и всё, получаем типизированный датасет с именем как у XSD-файла

Что такое типизированный датасет: это наследник от датасета, в котором есть свойства с именами как у таблиц в XSD. Каждое такое свойство возвращает типизированную таблицу. Каждая типизированная таблица содержит коллекцию типизированных DataRow-ов, каждый типизированный DataRow содержит свойства с именами как у полей таблицы.

Использование типизированных датасетов: можно зачитывать в них данные полученные от датаадаптера, так же как и в обычных датасетах. Relation-ы превращаются в свойства DataRow-ов. Например, если есть таблица "Заказы" и таблица "Поставщики", и от поставщиков торчит ParentRelation в таблицу заказов (много заказов - к - одному поставщику), то в ЗаказRow будет свойство типа ПоставщикRow, вот так всё просто.