string value er forskellig i sql*plus fra insert til select
Hvis jeg indsætter en string i en tabel der indeholder et '¿' tegn og lave en query på tabellen er resultatet et '┐'
eks: SQL> insert into simple(pk,cid,s) values (900,4,'¿'); 1 rµkke er oprettet. SQL> select s from simple where pk=900 and cid=4; S -----┐ S er lavet som varchar2(4000). Jeg bruger Oracle 9.2.0.1.0 Er der noget galt med min nls opsætning.
Det ser ikke lige ud til at eksperten gider æden den char jeg taler om, men det er en char der ligner et spejlvendt L. Jeg tror ikke det er en ASCII char
select chr(129) from dual returnere den char jeg sætter ind i tabellen i første omgang, så det virker. Insert sætter også den rigtige char ind i tabellen. Problemet er at fejlen opstår i en automatisk test af et generisk DB lag ved brug af Oracles egen ODBC driver. Testen indsætter nogle chars i en tabel og ser om den kan hente dem ud igen. Det egentlige problem er så at hvis jeg indsætter en streng der indeholder char(129) vil den streng være forkert når jeg hiver den ud igen. Der er altså ikke nogen option at bruge 'insert .... char(129)' da karakteren der er problemet kan være en del af en streng.
det er muligvis det tegnsæt som databasen er installeret med som er problemet.
Du finder navnet på tegnsættet ved select nls_characterset from nls_database_parameters. Denne parameter bør stemme med indholdet af environmentvariablen NLS_LANG på din klient.
Det er normalt et symptom på forkert opsætning af tegnsættet på serveren når man indsætter en korrekt streng og select returnerer en forvasket.
Jeg tror ikke det er det der er problemet. Hvis jeg bruger sqlplus der er installeret på serveren får jeg det forkerte tegn ud. Hvis jeg bruger et ODBC query værktøj får jeg det rigtige tegn ud. Hvis jeg bruger mit DB lag får jeg igen det forkerte tegn ud. Måske det er et problem med noget ODBC connection options som ODBC værktøjet selv sætter op for mig, men som mit DB lag kofigurere forkert
Udskyld det upræcise spørgsmål. Med NLS_LANG mente jeg indholdet af environment variablen NLS_LANG på serveren. Du kan finde det på UNIX med kommandoen echo $NLS_LANG. Hvis du anvender Windows kan du finde den i registry under Software/Oracle
Det gør ikke noget :-) Jeg har prøvet med AMERICAN_AMERICA.WE8ISO8859P1 og AMERICAN_AMERICA.WE8ISO8859P15. Det giver mig to forskellige resultater, men ingen af dem er det jeg forventer.
Du får som regel det samme ud, uanset hvilket character set der anvendes inde i databasen. Problemet kommer hvis du laver noget i sql*plus, og noget i toad, og måske har et tredje program til også at høvle data ind. Jeg tror du vil opleve at være fri for problemer, hvis du overlader det til dit program/hjemmeside at sende data ind/ud. Hvis du har fået dit omvendte ? fra word eller lignende, er det ikke givet at det er samme tegnsæt som din sql*plus anvender, og den konverterer derfor om til en eller anden pudsig standard :) Prøv at lade dit program indsætte din chr(129) :) og så se hvad der kommer ud :)
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.