Die Oracle -Abfrage gegen die SQL Server -Datenbank liefert inkonsistente Ergebnisse

Question

Wir haben mehrere Oracle 11.2.0.2 Datenbanken mit OG4ODBC -Datenbanklinks zu einer SQL Server 2008 -Datenbank. Eine bestimmte Tabelle in der SQL Server -Datenbank hat zwei Varchar (36) -Spalten. Die folgende Erklärung gibt 1292 Zeilen zurück:

select "id", "folder_id" from dbo.mediasite_presentation@ms;

Abfragen nach einem bestimmten Wert in der ersten Spalte gibt eine Zeile zurück:

select "id", "folder_id" from dbo.mediasite_presentation@ms 
   where "id"='006d815d-6e9e-4004-9104-51213a1ecd52';
id                                   folder_id
------------------------------------ ------------------------------------
006d815d-6e9e-4004-9104-51213a1ecd52 54aa9b6e-1c55-4de5-a06f-033d8b19fff0

Das Abfragen nach einem bestimmten Wert in der zweiten Spalte gibt jedoch keine Zeilen zurück:

select "id", "folder_id" from dbo.mediasite_presentation@ms 
   where "folder_id"='54aa9b6e-1c55-4de5-a06f-033d8b19fff0';
no rows selected

Verwenden der WHERE -Klausel, die funktioniert, und das Wickeln jedes Feldes in einem to_char gibt die folgenden interessanten Ergebnisse zurück:

select to_char("id"), to_char("folder_id") from dbo.mediasite_presentation@ms 
   where "id"='006d815d-6e9e-4004-9104-51213a1ecd52';
TO_CHAR("ID")                        TO_CHAR("FOLDER_ID")
------------------------------------ ------------------------------------
006d815d-6e9e-4004-9104-51213a1ecd52 ┐┐┐┐┐┐┐┐┐┐┐┐┐┐┐┐┐┐

Interessanterweise kann ich die gleichen Ergebnisse erzielen, indem ich nur eine Rownum -Klausel hinzufügt:

select "id", "folder_id" from dbo.mediasite_presentation@ms 
   where "id"='006d815d-6e9e-4004-9104-51213a1ecd52' and rownum<=1;

id                                   folder_id
------------------------------------ ------------------
006d815d-6e9e-4004-9104-51213a1ecd52 ┐┐┐┐┐┐┐┐┐┐┐┐┐┐┐┐┐┐

Selbst Fremder ist die Tatsache, dass das Erstellen einer materialisierten Ansicht für Abfrage, die keine Daten zurückgibt, tatsächlich Daten zurückgibt.

Create Materialized View TempMV as (
   select "id", "folder_id" from dbo.mediasite_presentation@ms 
      where "folder_id"='54aa9b6e-1c55-4de5-a06f-033d8b19fff0' and rownum<=1);
Materialized view created.
select * from TempMV;

id                                   folder_id
------------------------------------ ------------------------------------
006d815d-6e9e-4004-9104-51213a1ecd52 54aa9b6e-1c55-4de5-a06f-033d8b19fff0

Bitte antworten Sie auch, wenn Sie nur ein Stück dieses Puzzles erklären können.

Answer 1

Ich würde einige für das Problem der Charaktere des Charakters vermuten. Wenn Sie einen to_char machen, erhalten Sie "┐┐┐┐┐┐┐┐┐┐┐┐┐┐┐┐┐┐" (18 Zeichen) zurück. Dies deutet darauf hin, dass es eine gewisse Verwirrung darüber gibt, ob die in der Spalte enthaltenen Daten Single-Byte oder Multi-Byte sind.

"Der einzigartige Identifikator-Datentyp im SQL-Server wird als 16-Byte-Binärwert nativ gespeichert". Dies sollte idealerweise als RAW-Datentyp als RAW-Datentyp als VARCHAR2 oder char anfallen.

Wenn Sie a machen

CREATE VIEW temp_view as select  "id", "folder_id" from dbo.mediasite_presentation@ms

Was zeigt sich, wenn Sie eine Desc temp_view machen