[.NET] Specifieren welke encoding een Process moet gebruiken

[whoami]

Ik heb hier een klein tooltje geschreven in C# wiens taak het is om de database die we hier voor het project gebruiken te bouwen.
Dit tooltje creeërt de 'basis-databank'; deze DB heeft een bepaalde versie en gaat dan na welke 'database-patches' er moeten uitgevoerd worden om tot de laatste versie te komen.

De patches staan ergens op een schijf, en worden door het C# programma aangeroepen dmv een call naar isql (dit gebeurt dmv de System.Diagnostic.Process class).
Tot zover geen probleem, dit werkt als een trein.

Echter, nu is het zo dat ik patches heb die data in de databank opvullen. Sommige van deze gegevens bevatten characters met accenten (é, à, è, etc...).
Deze worden echter niet goed in de DB gezet. Ik vermoed dus dat het System.Diagnostic.Process object niet de juiste codepage/encoding kan gebruiken.
(Ik heb dit probleem ook al eens gehad toen ik een file wilde uitlezen met een STreamReader, maar daar kan ik wel aangeven welke encoding er moet gebruikt worden).

Nu mijn vraag: weet er iemand hoe ik dat Process diets kan maken dat hij m'n default encoding moet gebruiken als isql het bestand gaat gaan inlezen dat ik als argument meegegeven heb?

[whoami]

Ik denk dat ik er ga rondwerken door isql niet de patch-file als argument te laten nemen, maar de inhoud van de patchfile.

Ik ga dus zelf de patchfile inlezen, en de inhoud ervan naar isql sturen; echter, ik vraag me af of dit wel zal werken.....
De patchfiles kunnen best groot zijn...

[whoami]

Kickje, dit werkt dus niet, de patchfiles zijn te groot.

Het probleem is dus dat isql gestart wordt door een System.Diagnostics.Process object, en dat dit object blijkbaar bij het inlezen van de file (patch-file) die door isql moet uitgevoerd wroden, geen rekening houdt met de codepage oid.
Characters die accenten bevatten (de niet standaard ascii char's dus), worden niet goed weergegeven.

[EfBe]

Hoe schrijf je je patches weg in de textfile? Want daar moet je de goede encoding gebruiken. isql leest simpelweg die file in en executeert de DML (of doe je het niet zo?)

[whoami]

EfBe schreef op maandag 31 januari 2005 @ 12:56:
Hoe schrijf je je patches weg in de textfile? Want daar moet je de goede encoding gebruiken. isql leest simpelweg die file in en executeert de DML (of doe je het niet zo?)

De patches worden gecreeërd dmv 'Redgate SQL Compare'.

In zo'n patch kunnen zowel DDL als DML statements staan; er kan bv. een patch zijn die 'statische' data in de DB gaat laden.
Dan staat er bv dit in de patch:

code:

INSERT INTO tabelnaam ( veldnaam ) VALUES ( 'ééééàààà' )

De characters staan dus goed in de patch-file.

Mijn tooltje die de DB gaat creeëren voert eerst een 'base-line' setup uit; deze gaat eigenlijk de DB gaan creeëren; in de DB wordt bijgehouden welk versie-nr de DB heeft.
Dan wordt gekeken welke patches er moeten uitgevoerd worden.

De patches worden uitgevoerd dmv een System.Diagnostics.Process te starten die isql aanroept. Dit werkt perfect, behalve dat 'accent characters' niet goed ingeladen worden.

[whoami]

Daarbij komt dat, als ik m'n patch via Query Analyzer uitvoer, de gegevens er correct inkomen.


Als ik de patch uitvoer via m'n tooltje (die isql aanroept) komen die é en à's er niet goed in.
Als ik de patch uitvoer via isql (vanaf de cmd line), komen die é en à er ook niet goed in (dit terwijl ik dacht dat dit vrijdag wel het geval was toen ik het testte, misschien was ik toen te suf).

Ik heb nu ook een logfile toegevoegd aan m'n call naar isql (waar alle statements inkomen die isql uitvoert), en ik zie dat die è en à characters in de logfile wel goed staan.

Het probleem ligt 'm dus bij isql, en dat is iets wat ik ook vreemd vind.
Een eerdere versie van het tooltje om de DB te bouwen was nl. een vbs-filetje die op dezelfde manier te werk ging; dat tooltje was echter te beperkt en daarom heb ik er ff een C# app voor gemaakt.
Het vbs-filetje ging ook isql aanroepen, en toen kwamen die é en à characters er wel goed in.

[MSalters]

Het is me niet helemaal duidelijk waar je stopt met het gebruik van Unicode. .NET intern is Unicode, net zoals Windows sinds NT3.1. Die patch file is zeker geen Unicode? Is het misschien een optie om die wel Unicode (UTF-16) te maken?

Je kunt nu eenmaal niet zeggen dat de "karakters goed in de patch file staan" als het 8-bits karakters zijn. Het enige wat je kunt zeggen is dat je een encoding weet waarin die karakters goed staan. Dat is dus blijkbaar niet de encoding die isql gebruikt.

Encoding is onder Windows geen proceseigenschap - logisch, voor een Unicode OS - dus het lijkt me extreem lastig om een willekeurig proces te beinvloeden. Het lijkt er wel op dat je het voor je eigen thread kunt zetten, maar om op die manier isql te hacken is Win32 voodoo.

[whoami]

Als ik bv dit doe op de commandline:

code:

isql -b -S servername -d databasename -U sa -P pwd -q "INSERT INTO persoon (naam) values('éé')

dan worden de values er goed in gezet.

Als ik diezelfde command-line uitvoer via m'n tooltje:

code:

p.StandardInput.WriteLine ( "isql .... ")

Dan krijg ik weer ongewenste karakters.

[whoami]

MSalters schreef op maandag 31 januari 2005 @ 13:37:
Het is me niet helemaal duidelijk waar je stopt met het gebruik van Unicode. .NET intern is Unicode, net zoals Windows sinds NT3.1. Die patch file is zeker geen Unicode? Is het misschien een optie om die wel Unicode (UTF-16) te maken?

Dat heb ik al eens geprobeerd; echter, als ik m'n script dan uitvoer via isql, krijg ik een 'incorrect syntax near ÿ'.

[whoami]

Hmmm, blijkbaar zou isql geen unicode files aankunnen; isql is ook een oude tool.

* whoami gaat het eens proberen met osql.

[whoami]

* whoami gaat ff z'n hoofd gaan stoten....

ezel, waarom heb ik niet gechecked dat osql de nieuwste utility was (ik wist dat één van die 2 nieuwer was), en ben ik er gewoon vanuit gegaan dat de (voormalige) DBA wel het nieuwste tooltje had gebruikt....

[whoami]

Ok, ik had het dus opgelost door al m'n patch-files te converteren naar een unicode-formaat, en gebruik te maken van de osql tool.
Allemaal geen probleem; echter, nu krijg ik de melding van een collega dat het nog steeds niet werkt bij hem.
Als ik de patch-files bekijk die hij op zijn pc heeft, zijn die gewoon allemaal vernaggeld.

De patch-files zijn opgeslagen in VSS; en blijkbaar kan VSS niet overweg met unicode-files...

[whoami]

Opgelost door alle files in ANSI in VSS te laten zitten, en een routine geschreven die, als de DB create wordt uitgevoerd, de ANSI files omzet naar een unicode encoding, en deze dan uitvoert.