[.NET System.Data.OracleClient] Bug?

[Verwijderd]

Beste tweakers,

Ik denk dat we een bug hebben gevonden in de .NET Oracle provider ( System.Data.OracleClient ). Wanneer wij een update of insert statement proberen uit te voeren naar een willekeurig veld met een karakter als "ë, è, ô, Ñ, etc", dan wordt in plaats van dit karakter een tweetal bagger- karakters weggeschreven.

Hier een stukje voorbeeld code:

code:

System.Data.OracleClient.OracleConnection myConnection = 
    new System.Data.OracleClient.OracleConnection
      ("de connectionstring");

System.Data.OracleClient.OracleCommand myCommand = 
    myConnection.CreateCommand();

myCommand.CommandText = 
    "Update tablename set fieldname = " + 
    ":myValue where id= :myID";

myCommand.Parameters.Add(":myValue", System.Data.OracleClient.OracleType.VarChar,50);

myCommand.Parameters.Add(":myID", System.Data.OracleClient.OracleType.Number);

myCommand.Parameters[":myValue"].Value = "Mijn problëëm.";
myCommand.Parameters[":myID"].Value = 10;
myCommand.ExecuteNonQuery();

De waarde "Mijn problëëm." kan nu niet goed worden weggeschreven. De enige work- around die we tot noch toe hebben gevonden is deze:

code:

System.Data.OracleClient.OracleConnection myConnection = 
new System.Data.OracleClient.OracleConnection(
    "de connectionstring");

System.Data.OracleClient.OracleCommand myCommand = 
myConnection.CreateCommand();

myCommand.CommandText = "Update tablename set fieldname = 'Mijn problëëm.' where id= 10";

myCommand.ExecuteNonQuery();

Maar als dit de enige oplossing is zou dat betekenen dat ik alle parameters moet gaan vervangen uit een gigantische lap code. Ik hoop dus dat er iemand is die meer ervaring heeft met dit probleem + een mogelijke oplossing.

[alienfruit]

Krijg zulke problemen ook als je de BDP gebruikt voor Oracle Databases?

[Verwijderd]

alienfruit schreef op 25 August 2003 @ 09:23:
Krijg zulke problemen ook als je de BDP gebruikt voor Oracle Databases?

De BDP ken ik eerlijk gezegd niet. Wij gebruiken hier de native Microsoft Oracle Provider. Tot nu toe nog nooit problemen mee gehad, totdat iemand Arnhëm had ingevuld.

Ik denk eerlijk gezegd dat het echt aan de .NET provider ligt. Als we gewoon zelf een volledige insert opbouwen ( zonder parameters ) gaat het namelijk gewoon goed. Die provider doet dus iets met het interpreteren van vreemde karakters in de parameter. Misschien heeft het wel iets met UniCode te maken maar ik heb er nog niks over kunnen vinden.

[EfBe]

Lijkt er inderdaad op dat die provider het niet erg goed doet mbt unicode characters. Er zijn echter 2 oracle providers: 1 van MS (die zit bij .NET 1.1) en 1 van Oracle zelf. Heb je die laatste al geprobeerd?

[dotcode]

Misschien kan je kijken naar welke string formatter je gebruikt, het kan namelijk uitmaken welke encoding je gebruikt.

UnicodeEncoding
UTF7Encoding
UTF8Encoding

Ik ken het probleem niet, maar ik zou hier eens naar kijken en uitproberen of het resultaat anders wordt.

[Verwijderd]

dotcode schreef op 25 August 2003 @ 09:45:
Misschien kan je kijken naar welke string formatter je gebruikt, het kan namelijk uitmaken welke encoding je gebruikt.

UnicodeEncoding
UTF7Encoding
UTF8Encoding

Ik ken het probleem niet, maar ik zou hier eens naar kijken en uitproberen of het resultaat anders wordt.

Heb je ook enig idee waar ik dat op kan geven? Zowel op de connection als op het command object zie ik geen mogelijkheid om een andere encoding aan te geven. Ik denk wel dat het probleem hier ergens in zit.

[Verwijderd]

EfBe schreef op 25 August 2003 @ 09:44:
Lijkt er inderdaad op dat die provider het niet erg goed doet mbt unicode characters. Er zijn echter 2 oracle providers: 1 van MS (die zit bij .NET 1.1) en 1 van Oracle zelf. Heb je die laatste al geprobeerd?

We gebruiken die van MS zelf ( is ook apart te downloaden ), natuurlijk wel in combinatie met de Oracle Client ( anders gaat ie piepen dat er problemen zijn met OCI.dll etc ).

Overstappen naar de provider van Oracle kan nog moeilijk worden. Die van MS is hier bedrijf- policy . Maar als het niet anders kan moet het inderdaad maar. Ik zal dat vandaag gaan onderzoeken.

[dotcode]

Dit is maar een voorbeeld uit de documentatie, maar het geeft aan hoe het werkt:

code:

using System;
using System.Text;

class UnicodeEncodingExample {
    public static void Main() {
        // The encoding.
        UnicodeEncoding unicode = new UnicodeEncoding();
        
        // Create a string that contains Unicode characters.
        String unicodeString =
            "This Unicode string contains two characters " +
            "with codes outside the traditional ASCII code range, " +
            "Pi (\u03a0) and Sigma (\u03a3).";
        Console.WriteLine("Original string:");
        Console.WriteLine(unicodeString);

        // Encode the string.
        Byte[] encodedBytes = unicode.GetBytes(unicodeString);
        Console.WriteLine();
        Console.WriteLine("Encoded bytes:");
        foreach (Byte b in encodedBytes) {
            Console.Write("[{0}]", b);
        }
        Console.WriteLine();
        
        // Decode bytes back to string.
        // Notice Pi and Sigma characters are still present.
        String decodedString = unicode.GetString(encodedBytes);
        Console.WriteLine();
        Console.WriteLine("Decoded bytes:");
        Console.WriteLine(decodedString);
    }
}

zoek in System.Text dan kom je een heel eind

[Verwijderd]

dotcode schreef op 25 August 2003 @ 10:03:
Dit is maar een voorbeeld uit de documentatie, maar het geeft aan hoe het werkt:
...
zoek in System.Text dan kom je een heel eind

Toch begin ik nu te twijfelen of het aan unicode ligt. De ë ligt toch nog gewoon in het normale ASCII bereik? Ik ga wel meteen kijken of hier een oplossing mee te bedenken is. Bedankt!

[ Voor 60% gewijzigd door Verwijderd op 25-08-2003 10:22 ]

[Creepy]

Verwijderd schreef op 25 August 2003 @ 10:22:
[...]


Toch begin ik nu te twijfelen of het aan unicode ligt. De ë ligt toch nog gewoon in het normale ASCII bereik?

Nee.. standaard ASCII is maar 7 bits (dus 128 tekens in totaal). Daar zit de ë niet in. Extended ASCII bestaat ook nog, maar daar is meer dan 1 standaard van, dus je weet nooit zeker dat daar de ë in zit

[dotcode]

Het gaat er om hoe de chars worden gezien in de database provider, omdat je char in tweeen wordt gesplist lijkt het op een encoding probleem.

[EfBe]

De database provider zou de conversie moeten doen. het is natuurlijk wel de vraag of het veld waar de data in komt een unicoded char field is (geen idee wat het type is daarvan binnen oracle). Zo niet dan krijg je idd bagger. Wellicht dat dit de issue is? (SqlServer neemt gewoon 8bits aan in varchar's, geen idee of oracle dat ook doet, ik denk van niet)

[alienfruit]

BDP = Borland Data Providers :-)
Ik zal eens kijken of daar ook het probleem is, moet ik alleen nog een Oracle database/server hebben. Kan nog wel even duren!
Borland dus is betuuurrrrrrrrrrrrrrrrr

[ Voor 73% gewijzigd door alienfruit op 25-08-2003 15:20 ]

[Verwijderd]

Misschien heeft iemand iets aan het volgende,

Bijvoorbeeld de ë wordt door de data provider gezien als ë

Ik ben nog steeds aan het kijken of ik met de UniCode functies iets kan doen, maar voorlopig lijkt dat nog niet te werken. Het rare is ook dat

code:

System.Data.OracleClient.OracleConnection myConnection = 
    new System.Data.OracleClient.OracleConnection
      ("de connectionstring");

System.Data.OracleClient.OracleCommand myCommand = 
    myConnection.CreateCommand();

myCommand.CommandText = 
    "Update tablename set fieldname = " + 
    ":myValue where id= :myID";

myCommand.Parameters.Add(":myValue", System.Data.OracleClient.OracleType.VarChar,50);

myCommand.Parameters.Add(":myID", System.Data.OracleClient.OracleType.Number);

myCommand.Parameters[":myValue"].Value = "Mijn problëëm.";
myCommand.Parameters[":myID"].Value = 10;

Als je hier myCommand.Parameters[":myValue"].Value zou bekijken in debug, er doodleuk nog een problëëm staat.

code:

myCommand.ExecuteNonQuery();

Pas hierna zie je in de database de verpeste waarde. Ik snap dus nog niet hoe ik hier die encoding aan moet kunnen passen

Zie dik gedrukte...

[ Voor 74% gewijzigd door Verwijderd op 25-08-2003 15:31 ]

[dotcode]

Kijk eens wat voor soort string de database verwacht? Kan je deze onderscheppen op het moment dat hij daar aankomt?

[EfBe]

Verwijderd schreef op 25 augustus 2003 @ 15:22:
myCommand.Parameters.Add(":myValue", System.Data.OracleClient.OracleType.VarChar,50);

Mja, dat gaat niet werken natuurlijk. Je moet NVarChar gebruiken, ook in je field in de database, immers je werkt met unicoded characters. Zoals ik hierboven al zei: waarschijnlijk wil Oracle in een varchar louter 7 bits ascii en alle andere ascii moet in een n(var)char... (denk ik)

[Verwijderd]

EfBe schreef op 25 August 2003 @ 16:56:
[...]

Mja, dat gaat niet werken natuurlijk. Je moet NVarChar gebruiken, ook in je field in de database, immers je werkt met unicoded characters. Zoals ik hierboven al zei: waarschijnlijk wil Oracle in een varchar louter 7 bits ascii en alle andere ascii moet in een n(var)char... (denk ik)

Dat maakt helaas geen drol uit. De System.Data.OracleClient.OracleType geeft de volgende opties:

Bfile, Blob, Byte, Char, Clob, Cursor, DateTime, Double, Float, Int16, Int32, IntervalDayToSecond, IntervalYearToMonth, LongRaw, LongVarChar, NChar, NClob, Number, NVarChar, Raw, RowID, SByte, TimeStamp, TimeStampLocal, TimeStampWithTZ, UInt16, UInt32 en Varchar.

Zowel met VarChar als NVarChar worden de karakters boven de standaard ASCII tabel om zeep geholpen. Verder zie ik geen type die in staat is mijn stringwaarde netjes in het veld op te slaan.In Oracle is het veld overigens gedeclareerd als VARCHAR2(200).

[dotcode]

Wat is dan het type van het veld wat je in de database wilt gaan vullen? Als dit ascii is dan kan je alles proberen maar dan lukt het natuurlijk niet.

[EfBe]

Dat zegt ie net, VARCHAR2(200)

[Verwijderd]

Het is waarschijnlijk toch echt een BUG in de .NET provider voor Oracle. Ik ben meer mensen tegengekomen met het probleem.

De provider is er nu uitgesloopt en we gebruiken nu een OleDB verbinding. Dit geeft geen enkel probleem. Het ombouwen was redelijk snel te doen, alleen in plaats van named parameters moesten overal '?'- tjes komen te staan... dat was wel FF irritant.

Snelheid lijkt er niet eens op achteruit te zijn gegaan.

[Patser]

In je myCommand.CommandText waar de update wel wrkt gebruik je 'enkele quotes'.

Werkt je originele myCommand wel als je daar ook de 'enkele quotes' in zet?

code:

myCommand.CommandText = 
    "Update tablename set fieldname = '" + 
    ":myValue' where id= :myID";

In de tweede regel achter fieldname = staat dus eerst een enkele ' en dan een dubbele "
en achter :myValue de sluitende enkele weer.

edit:

je laatste antwoord ging ook over de enkele quotes.
Niet gezien.

[ Voor 18% gewijzigd door Patser op 07-09-2003 18:07 ]