Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Nixon, Вы писали:

N>>VS 2005, Framework 2.0

N>>Плохо становится когда в БД, содержаться записи не удовлетворяющие этим ограничениям (в моем случае при переносе из другой БД).
G>А нельзя этот вопрос на уровне БД решить? Нпример не выбирать повторяющиеся записи.

Не выбирать повторяющиеся? Дело в том, что уникальность определена для отдельных колонок, т.е запись может иметь смысл (запись должна быть, она несет полезную информацию, но в ней есть ошибка), не выводить ее нельзя.

N>>Собственно вопрос: Как организовать обмен DataTable с ограничениями между двумя удаленными компонентами, таким образом чтобы они могли обмениваться данными которые не удовлетворяют этим ограничениям?
G>А клиент вообще может отправить серверу некорректные данные? Если нет, тогда все проблемы надо решать на сервере.

Ограничения нарушить клиент не может (у меня не получается создать из интерфейса такую ситуацию), но может отправить серверу данные неверные по другим критериям (например записи о приеме на работу\переводе\увольнении, в неправильном хронологическом порядке), тогда сервер примет их, проверит, откажеться записать и отправит предупреждение клиенту. Т.е клиент не может внести в БД неверные данные (в ходе моего тестирования не получилось), НО неверные данные которые попали в БД (сейчас при переносе из другой БД) либо не попадают к клиенту либо попадают без необходимых ограничений либо приходится городить весь этот огород описанный в исходном посте.

Ситуация такова, что есть данные которые не соответствуют ограничениям, но какими они должны быть алгоритм не знает. Т.е ошибку может исправить только пользователь, для этого надо его предупредить о том, что "есть такие-то ограничения и вот эти данные им не соответствуют".

Вашу фразу "все проблемы надо решать на сервере", я наверное неправильно понимаю т.к. в моей трактовке получается что СУБД сама исправляет ошибки пользователей (введенные в предыдущей БД), поэтому остается только научить ее самой вводить новые данные и выбросить пользователей вместе с клиентской частью за ненадобностью.