SqlConnection und Autotranslate

[bigpoint]

Ist es überhaupt möglich bei SqlConnection Autotranslate zu setzen??

[Andreas Kosch]

Hallo,

diese Option spielt nur beim Zugriff über einen ODBC-Treiber oder OLE DB-Provider eine Rolle:

a) OLE DB: Eintrag AutoTranslate oder Auto Translate
b) ODBC: Eintrag AutoTranslate

Die nativen Treiber des SQL Servers regeln das selbst.

[bigpoint]

Hallo Herr Kosch,

......
Die nativen Treiber des SQL Servers regeln das selbst.

wie soll ich es verstehen??


Folgendes Problem, es gibt ein SQL Server mit der Sortierreihenfolge-ID 42
(SQL_Latin1_General_CP850_CI_AS) in dem SQL Server gibt es jede menge Datensätzen die umlaute beinhalten, alle die ds sind falsch (die umlaute) gespeichert. Auf das DB greift eine Anwendung mit ODBC Einstellungen (Autotranslate=No), so werden auch die umlaute in dem Anwendung richtig interpretiert. Jetzt muss ich ein .NET Programm schreiben der auf das DB zugreift. Sobald das .NET Programm die Daten in den DB rein schreib werden die umlaute richtig gespeichert allerdings von dem ODBC Programm falsch gelesen usw.

Nach dem SqlConnection Autotranslate nicht unterstützt fehlt mit nur eins, alle die Daten die bisher "falsch" gespeichert sind updaten (es handelt sich leider aber um sehr vielle ds) und dann bei dem ODBC Prog. Autotranslate auf YES setzen.

Was wurden Sie mir in so eine Situation raten, kann man es vielleicht geschickter lösen??

[Andreas Kosch]

Hallo,

>>Die nativen Treiber des SQL Servers regeln das selbst.
>...wie soll ich es verstehen??

angenommen, man arbeitet die folgenden Schritte ab:

1. CREATE DATABASE erzeugt eine neue Datenbank, die die Option COLLATE SQL_Latin1_General_CP850_CI_AS verwendet.

2. Es wird eine Tabelle mit einer VARCHAR-Spalte erstellt, die implizit die Datenbankeinstellung übernimmt (... [umlaut] [varchar](9) COLLATE SQL_Latin1_General_CP850_CI_AS NOT NULL).

2. Über SQL werden Umlautdaten dort eingefügt.

3. In VS2005 wird ein TableAdapter (nativer SqlClient) für diese Tabelle angelegt und mit einem DataGridView verbunden.

4. Das Programm wird gestartet, der Umlautdatensatz wird richtig angezeigt. Neue Umlaut-Datensätze können auch erfolgreich in der Datenbank gespeichert werden.

...kann man es vielleicht geschickter lösen??

Die Daten aus einer CHAR/VARCHAR-Spalte der Datenbanktabelle werden vom .NET Framework mit dem Datentyp System.String gespeichert. Die "Krücke" eines eigenen Zeichensatzes ist Heute angesichts der Unicode-Fähigkeit nicht mehr notwendig.

Wenn die Altdatensätze in der Datenbank nicht angefasst werden sollen, kann die Zeichensatztransformation auch erst beim SELECT-Aufruf erfolgen:

SELECT umlaut COLLATE Latin1_General_CI_AS  AS Umlaut
FROM  dbo.TestTbl

SELECT umlaut COLLATE SQL_Latin1_General_CP850_CI_AS  AS Umlaut
FROM  dbo.TestTbl

[bigpoint]

Hallo,

Wenn die Altdatensätze in der Datenbank nicht angefasst werden sollen, kann die Zeichensatztransformation auch erst beim SELECT-Aufruf erfolgen:

Angenommen die darf man anfassen?!

Ich habe in der Tabelle Zeichenfolge 'Geb³hr'
So funktioniert es doch gar nicht:

select 'Geb³hr' COLLATE Latin1_General_CI_AS
select 'Geb³hr' COLLATE SQL_Latin1_General_CP850_CI_AS

Obwohl so man es konvertieren kann
SELECT NCHAR(ASCII('³'))

[Andreas Kosch]

Hallo,

wenn die Altdaten "angefasst" werden dürfen, würde ich eine neue Datenbank mit dem "richtigen" Zeichensatz (Standardzeichensatz vom SQL Server) anlegen und die Datensätze mit dtswizard.exe umkopieren. In diesem Fall ist die Transformation ein einmaliger Vorgang.

Auf dem SQL-Weg ist für das Transformieren der Umweg über das VARBINARY-Zwischenergebnis notwendig, wie das folgende Beispiel zeigt:

<div style="font-family: Courier New; font-size: 10pt; color: black; background: white; border-top: windowtext 1pt solid; padding-top: 0pt; border-left: windowtext 1pt solid; padding-left: 0pt; border-right: windowtext 1pt solid; padding-right: 0pt; border-bottom: windowtext 1pt solid; padding-bottom: 0pt;"><p style="margin: 0px;"><span style="color: green;">-- 'Geb&#179;hr' nach 'Geb&#252;hr' &#228;ndern</span></p><p style="margin: 0px;"><span style="color: blue;">SELECT CAST</span>(<span style="color: blue;">CAST</span>(<span style="color: #a31515;">'Geb&#179;hr' </span><span style="color: blue;">COLLATE </span>SQL_Latin1_General_CP850_CI_AS <span style="color: blue;">AS VARBINARY</span>) <span style="color: blue;">AS VARCHAR</span>)</p></div>

[bigpoint]

Hallo Herr Kosch,

werden die Daten bzw. umlaute dann automatisch "richtig" gesetzt??
In dem DB ist es so dass, nur par Tabellen betroffen sind die die falsche umlaute beinhalten, denn Rest ist ohne umlaute Problemen, wehre dann in solchem fall nicht meine Lösung mit dem update günstiger.

Vielen Dank

[Andreas Kosch]

Hallo,

wenn nur einige Tabellen (genauer gesagt, Spalten von Tabellen) betroffen sind, könnte man das Umkopieren über eine temporäre Hilfsspalte in der "alten" Datenbanktabelle erledigen. Dies setzt voraus, dass nicht die Regeln der deklarativen referenziellen Integrität in die Quere kommen (d.h. die betroffene Spalte darf kein Fremdschlüssel einer anderen Tabelle sein). Die Schritte könnten dann so aussehen:

1. ALTER TABLE legt in der Tabelle eine neue Spalte mit dem neuen Zeichensatz an.

2. Die doppelte CAST-Umwandlung über den VARBINARY-Zwischenwert (siehe vorheriges Beispiel) kopiert die Daten von der alten in die neue Spalte.

3. Wenn die abschließenden Tests keine Beeinträchtigung finden, kann die originale Spalte gelöscht und die neue Spalte umbenannt werden. Der Client "sieht" dann nur die neuen Daten, wenn der "alte" Spaltenname in der SELECT-Anweisung abgefragt wird.

[bigpoint]

Ich habe versucht Ihren weg zu gehen, leider
dieses SQL Beispiel funktioniert nicht auf dem SQL Server mit Sortierungsnamen
SQL_Latin1_General_CP850_CI_AS

SELECT CAST(CAST('Geb³hr' COLLATE SQL_Latin1_General_CP850_CI_AS AS VARBINARY)AS VARCHAR) 

Es wird noch wie vor 'Geb³hr' angezeigt

[Andreas Kosch]

Hallo,

welches Ergebnis liefert der folgende Test:

USE tempdb
GO

CREATE TABLE Test
(
  id    INT         NOT NULL IDENTITY PRIMARY KEY,
  wert1 VARCHAR(9)  COLLATE Latin1_General_CI_AS,
  wert2 VARCHAR(9)  COLLATE SQL_Latin1_General_CP850_CI_AS,
  wert3 NVARCHAR(9)
)
GO

INSERT INTO dbo.Test (wert1,wert2,wert3)
 SELECT CAST(CAST('Geb³hr' COLLATE SQL_Latin1_General_CP850_CI_AS AS VARBINARY)AS VARCHAR), 
        'Geb³hr' COLLATE SQL_Latin1_General_CP850_CI_AS,
        CAST(CAST('Geb³hr' COLLATE SQL_Latin1_General_CP850_CI_AS AS VARBINARY)AS VARCHAR) 
 
SELECT * FROM dbo.Test

[bigpoint]

Hallo,
welches Ergebnis liefert der folgende Test:

id          wert1     wert2     wert3     
----------- --------- --------- --------- 
1           Geb³hr    Geb³hr    Geb³hr

[bigpoint]

Hallo Herr Kosch

hätten Sie vielleicht noch eine Idee bzw. was haben Sie bei dem SQL erwartet?

[Andreas Kosch]

Hallo,

da das Beispiel zur tempdb-Systemdatenbank wechselt und dort die Tabelle anlegt, müssten die Spalten wert1 und wert3 die Umlaute korrekt anzeigen. Dies gilt jedenfalls immer dann, wenn die SQL Server-Instanz für die Eigenschaft Server Collation den Wert Latin1_General_CI_AS verwendet (weil dann auch die Datenbankverbindung diesen Zeichensatz nutzt).

[bigpoint]

Dies gilt jedenfalls immer dann, wenn die SQL Server-Instanz für die Eigenschaft Server Collation den Wert Latin1_General_CI_AS verwendet (weil dann auch die Datenbankverbindung diesen Zeichensatz nutzt).

dh. die DB Eingeschaften Collation sind egal, wichtig sind die von dem Server?

[Andreas Kosch]

Hallo,

..dh. die DB Eingeschaften Collation sind egal, wichtig sind die von dem Server?

alle beteiligten Stellen spielen zusammen. Bei meinem Experiment ist ja auch das SQL Management Studio über den Query Editor beteiligt, der für die bestehende Datenbanksitzung ebenfalls einen Zeichensatz für die Interpretation meiner Texteingaben unterstellt. Wenn das Experiment mit den 3 unterschiedlichen Zeichendatentypen auf einem anderen Rechner zu einem anderen Ergebnis führt, bedeutet dies nur, dass sich dort die Konfiguration unterscheidet (d.h. die Testbedingungen sind nicht identisch). Nur die Gegenprobe (d.h. das Experiment wird mit einer zweiten Standard-Installation des SQL Servers wiederholt, bei der der voreingestellte Zeichensatz nicht geändert wird) würde beweisen, dass tatsächlich die Zeichensatzvoreinstellung die Ursache der Probleme ist.