Мое приложение взаимодействует с обеими базами данных Oracle и SQL Server с помощью пользовательского уровня доступа к данным, записанного в использовании ADO.NET DataReaders. Прямо сейчас у меня есть проблема с преобразованием между GUID (который мы используем для первичных ключей), и тип данных СЫРЫХ ДАННЫХ Oracle. Вставляет в оракула, прекрасны (я просто использую ToByteArray () метод в Системе. Гуид). Проблема преобразовывает назад в Систему. Гуид, когда я загружаю записи из базы данных. В настоящее время я использую массив байтов, который я получаю из ADO.NET для передачи в конструктора для System. Гуид. Это, кажется, работает, но Гуиды, которые появляются в базе данных, не соответствуют Гуидам, которые я генерирую этим способом.
Я не могу изменить схему базы данных или запрос (так как это снова используется для SQL Server). Я должен кодировать для преобразования массива байтов из Oracle в корректный Гуид.
Оказывается, проблема заключалась в порядке байтов в Guid.ToByteArray ()
, а не в самом Oracle. Если взять Guid « 11223344-5566-7788-9900-aabbccddeeff
» и вызвать на нем ToByteArray ()
, то получится « 44332211665588779900AABBCCDDEEFF
. Если затем передать этот массив байтов обратно в конструктор Guid, вы получите исходный Guid. Моя ошибка заключалась в попытке запросить базу данных Oracle в исходном формате Guid (с удаленными дефисами) вместо результата вызова ToByteArray ()
.
Я до сих пор не понимаю, почему байты упорядочены таким образом, но, по-видимому, это не имеет ничего общего с Oracle.
У меня есть смутные воспоминания о том, что идентификаторы GUID от Oracle фактически перевернуты по сравнению с порядком, ожидаемым .NET.
Попробуйте перевернуть массив перед вызовом конструктора Guid
.
Это может быть не совсем так же просто, как реверсирование, однако вам может потребоваться более детальная подкачка. Я предлагаю вам создать GUID, в котором каждый байт легко идентифицировать (используйте 0x01, 0x23, 0x45 и т. Д.) И работать оттуда.