Ситуация:
Есть типизированный DataSet, в нем таблица, в качестве Primary Key в таблице используется столбец с типом данных RAW(16).
При попытке добавить ВТОРУЮ строку в таблицу получаем:
"Exception : Column 'MYID' is constrained to be unique. Value 'System.Byte[]' is already present."

Для .NET Framework тип данных RAW(16) - это System.Byte[], а преобразование (System.Byte[]).ToString() = "System.Byte[]"...

Конечно удаление Primary Key в таблице позволяет добавлять и удалять строки, но как-то это мне кажется неправильно...

Кто-нибудь знает как обойти данную проблему ?

Спасибо

Нет, не пользуюсь и, если честно, не знаю как это мне должно помочь.
Не расскажете куда "копать" ?

Проблема, как мне думается, не в Oracle, а в .NET Framework'e

Проблем с добавлением новых записей в Oracle нет - есть проблема добавления записей в таблицу DataSet'a если Primary Key столбец имеет тип "base64Binary", при добавлении 2-ой строки в таблицу DataSet'a (!).

До добавления записей собственно в Oracle дело не доходит.

см. выше

Итак по порядку:

1. Есть таблица в БД Oracle, в качестве первичного ключа столбец "ID" типа RAW (16) - массив байт;

2. Есть DataSet со сгенеренной таблицей из БД Oracle, в качестве первичного ключа столбец "ID" типа base64Binary (так сгенерила сама студия);

3. Значения "по умолчанию" для "ID" нет - все значения генерю руками.

4. Добавляем 1-ую строку в таблицу:
- первичный ключ уникальный: - заполняем остальные столбцы данными;
- добавляем строку в таблицу - все ОК ;

5. Добавляем 2-ую строку:
- первичный ключ тоже УНИКАЛЬНЫЙ
- заполняем остальные столбцы данными;
- при добавлении строки в таблицу получаем

Exception : Column 'ID' is constrained to be unique. Value 'System.Byte[]' is already present.

Мои предположения :
при проверке уникальности первичного ключа таблицы в DataSet'e, Framework приводит его (значение ключа) к строке (ToString()), а преобразование выдает " System.Byte[] "
Т.е. т.к. значение второго ключа после преобразования к строке тоже равно "System.Byte[]" - срабатывает ограничение на уникальность первичного ключа в таблице.

WorobjoffПопробуй так:
To_Char (Поле RAW) AS Псевдоним
в SelectCommand.CommandText
Народ, ну почитайте внимательнее - ругается на нарушение уникальности первичного ключа в таблице DataSet 'e.

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

Если я выключу проверку:

то ошибка исчезает, и я могу добавлять сколько угодно строк, а потом сделать:

и все данные обновятся, если не было повторяющихся значений в "ID".

WorobjoffХотел облегчить жизнь тем, чтобы преобразовать в Sting и не парится с Byte[15], но не преобразует его Oracle
Преобразовывает :)

Решение, которое мне подходит:

1. В DataSet подставляем "виртуальный" столбец, например "_ID", тип String
и "переносим" на него Primary Key.

2. В SelectCommand добавляем "SELECT RAWTOHEX(ID) AS "_ID", ..."

Теперь при добавлении новой строки в таблицу DataSet'a нужно добавлять также значение для столбца "_ID"


Тогда при добавлении новой строки сравниваться будут значения типа String, который поддерживает IComparable (спасибо кузе ).

Если есть еще варианты - готов поэкспериментировать :)

WorobjoffКак ведут себя запросы с Join-ами где в качестве PK и FK используется RAW. И как себя ведет Relation в DataSet. Напишите пожалуйста свой опыт.

JOIN'ны в ORACLE с данным типом данных ведут себя корректно и проблем с этим нет.

А вот Relation в DataSet'e не работают (как и Primary Key), если поле типа base64Binary.

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

Сергей