Problem mit Umlauten

Hallo!

In eine bestehende IB-Datenbank, die mit DEFAULT CHARACTER SET ISO8859_1 definiert ist, habe ich eine neue einfache Tabelle eingefügt (NrA,NrB, Bezeichnung,TextBlob).

In den bisherigen Tabellenfeldern ist es nach wie vor kein Problem mit Umlauten zu arbeiten. Doch bei der neuen Tabelle funktioniert das nicht mehr. Dabei habe ich auch auf bereits vorher angelegte Domains zurückgegriffen.

An der BDE kann es auch nicht liegen, da im Alias die Eigenschaft LANGDRIVER auf 'WEurope'ANSI angelegt ist und die übrigen Tabellen ja ausgezeichnet funktionieren.

Beim Versuch, im Tool Interbase Windows ISQL über SELECT einen Umlaut in die Tabelle einzufügen, erscheint die Fehlermeldung:

Statement failed SQLCODE -802: (...) cannot transliterate character between character sets

Wo liegt mein Fehler?

[Andreas Kosch]

Hallo,

was passiert, wenn eine neu angelegte Tabelle nur CHAR bzw. VARCHAR-Felder (ohne eigenen Domain-Typ) verwendet? Wurde beim Versuch über Windows ISQL auch vor dem Connect zur Datenbank der Zeichensatz für WISQL im Dialog geändert?

Wenn der Fehler immer noch auftritt, würde ich zum Test ein vollständiges Backup/Restore machen (d.h. die Datenbank beim Restore neu erzeugen lassen). Eventuell sind die System-Tabellen der aktuellen Datenbank in diesem Punkt inkonsistent?

P.S. Wird ein UDF-Funktion verwendet bzw. wurde vor kurzem die InterBase-Version gewechselt?
&#10

Hallo!

Erstmal Danke für die Tipps!! Bin inzwischen auch schon weitergekommen, aber so richtig klappt es noch immer nicht...

An den Domain-Typen liegt es nicht - bei Varchar erhalte ich die gleiche Fehlermeldung. Doch als ich per Dialog in WISQL den Zeichensatz auf Win1252 setzte, klappte der Zugriff. Zumindest aus WISQL und aus dem SQL-Explorer, aber nicht aus meinem Delphi-Programm...

Da die Datenbank insgesamt noch in der Entwurfphase ist und nur unwesentliche Testdaten enthält, habe ich (wie schon oft) statt Backup/Restore einfach per SQL-Script die Datenbank neu angelegt (Erste Zeile: SET NAMES ISO8859_1.

UDF-Funktionen verwende ich (noch) keine und ich arbeite von Anfang an mit Interbase 5.6.

In Delphi habe ich eine TDatabase-Komponente, in der die Eigenschaft LANGDRIVER auf DBWINWE0 ('WEurope' ANSI) voreingestellt ist.

Alle Datenmengenkomponenten verweisen über DatabaseName auf die TDatabase-Komponente.

Bei connected=TRUE kann ich mir im SQL-Explorer den Inhalt der DB über den temporären TDatabase-Alias ansehen und auch hier klappt das Arbeiten mit Umlauten einwandfrei, also auch in meiner "Problem"-Tabelle.

Fehlt etwa noch was in meinem Delphi-Source-Code? Das komische ist ja, dass die Umlaute in den anderen Tabellen nach wie vor keine Schwierigkeiten darstellen. Und das, obwohl ich die Datenbank gerade erst wieder komplett neu angelegt habe...

Gruß, Heik

[Andreas Kosch]

Hallo,

das hört sich doch schon deutlich besser an. Wenn der Zugriff über WISQL nach dem Aktivieren des Zeichensatzes WIN1252 funktioniert und auch im SQL-Explorer über den angelegten BDE-Alias alles OK ist, kann der Fehler nur noch im TDatabase-Teil liegen. Ich würde daher folgendes machen:

1. Zum Test neue TDatabase-Instanz einbinden.

2. Doppelklick auf TDatabase; den funktionierenden Alias-Name für diese InterBase-Datenbank auswählen. Einen neuen Namen für diese TDatabase-Instanz vergeben.

3. Button <b>Vorgaben</b> anklicken, Delphi überträgt nun alle Alias-Einstellungen als Parameter in diese TDatabase-Instanz.

4. Die anderen Datenzugriffskomponenten auf die neue TDatabase-Instanz schalten und TDatabase öffnen.

Jetzt sollte sich das Programm exakt genauso verhalten wie der SQL-Explorer (da beide nun exakt die gleichen Einstellungen verwenden)

Hallo!

Das mit der TDatabase-Instanz hatte ich in der Zwischenzeit auch schon ausprobiert, klappt aber leider nicht!! Verrückterweise kann ich wirklich NUR in dem EINEN Feld KEINE Umlaute erfassen!!

Nach TDatabase habe ich eine neue TTable /TDatasource angelegt, die vorherigen gelöscht, die neuen eingebunden. Klappt auch nicht.

Habe auch schon die DB-Tabelle um Test-Felder erweitert. Klappt alles tadellos. Dann habe ich das Problemfeld aus der Tabelle entfernt und eins der neu angelegten Felder umbenannt. Auch die TFields habe ich von dem Testfeld eingebunden und die ursprünglichen gelöscht. Aber sowie der ursprüngliche Feldname (=KEYBEZ) verwendet wird, klappt es nicht mehr!!!

Irgendwo werden anscheinend feldspezifische Eigenschaften abgelegt, die nicht richtig zurückgesetzt werden. Aber WO??

Auf alle Fälle noch mal Danke für die Hilfe!!

Sich allein als Einsteiger durch dieses Wirrwarr zu kämpfen, ist manchmal ganz schön frustrierend. Und da, wo es immer spannend wird, kann einem die Online-Hilfe eh nicht mehr weiterhelfen...

Gruß, Heike!!

[Andreas Kosch]

Hallo,

am besten wird es sein, wenn das Ganze (SQL-Script für das Generieren der Datenbank bzw. die entladenen Schemadaten sowie ein kurzer Delphi-Testprogramm als Sourcecode) zum Reproduzieren des Effekts als ZIP-Anhang einer eMail an <i>[email protected]</i> abgeschickt wird. Ich werde dann spätestens am Wochenende einmal einen Blick drauf werfen -mittlerweise ist die Neugier geweckt ;-

Hallo Andreas Kosch,

Danke für das Angebot! Habe das Problem gerade weiter eingegrenzt - vielleicht wird nun vieles klarer:

Neben der TTable für meine Problem-Tabelle habe ich auch eine TQuery mit folgendem SQL-Text:

SELECT KEYNR, KEYNR || ' : ' || KEYBEZ AS SUCHKEY FROM TABELLE;

Lösche ich nun das Problemfeld KEYBEZ aus dieser Query raus, kann ich in der Tabelle auch Umlaute erfassen...

Komisch ist nun aber - wieso klappt es hier nicht? Auch bei anderen Tabellen habe ich ähnliche Queries - ohne Probleme...

Falls dennoch Interesse an einer Test-Source besteht, maile ich sie rüber.

Gruß, Heike :

[Andreas Kosch]

Hallo Heike,

ich habe mir Dein Beispiel näher angeschaut und die folgende Lösung gefunden, bei der keine Exception wegen der Zeichensatzkonvertierung erscheint:

1. Q_Probem.SQL ändern auf "Select KEYNR, KEYBEZ from FRAGENKEYS"

2. Neues berechnetes Feld anlegen: Q_ProblemSuche
<pre>
object Q_Problem: TQuery
OnCalcFields = Q_ProblemCalcFields
DatabaseName = 'XQ_Datenbank'
SQL.Strings = (
'Select KEYNR, KEYBEZ from FRAGENKEYS')
Left = 616
Top = 32
object Q_ProblemKEYNR: TIntegerField
FieldName = 'KEYNR'
Origin = 'XQ_DATENBANK.FRAGENKEYS.KEYNR'
end
object Q_ProblemKEYBEZ: TStringField
FieldName = 'KEYBEZ'
Origin = 'XQ_DATENBANK.FRAGENKEYS.KEYBEZ'
Size = 80
end
object Q_ProblemSuche: TStringField
FieldKind = fkCalculated
FieldName = 'Suche'
Calculated = True
end
end
</pre>
3. Ereignisbehandlungsmethode für das berechnete Feld ermittelt die Zusammensetzung:
<pre>
procedure TForm1.Q_ProblemCalcFields(DataSet: TDataSet);
begin
Q_ProblemSuche.Value := Format('%d : %s',
[Q_ProblemKEYNR.Value, Q_ProblemKEYBEZ.Value]);
end;
</pre>

3. DBLookupComboBox1 verwendet zur Anzeige das neue berechnete Feld:
<pre>
object DBLookupComboBox1: TDBLookupComboBox
Left = 8
Top = 40
Width = 201
Height = 21
DataField = 'KEYNR'
DataSource = DSc_Problem
KeyField = 'KEYNR'
ListField = 'Suche'
ListSource = DSQ_Problem
TabOrder = 4
end
</pre>

Somit können auch Umlaute in der Datenbanktabelle angelegt werden. Da die Umlaute auch im alten Programm trotz Exception in der InterBase-Tabelle eingetragen wurden, löst vermutlich die implizite Konvertierung (SELECT KEYNR, KEYNR || ' : ' || KEYBEZ AS SUCHKEY FROM Tabelle) das Problem aus. Das INTEGER-Feld KEYNR und das VARCHAR-Feld KEYBEZ werden verkettet, so das KEYNR umgewandelt werden muss. Vermutlich hat diese interne Funktion beim InterBase Probleme mit deutschen Umlauten. Durch das Auslagern in ein berechnete Feld (TField-Instanz) sorgt der Format-Aufruf dafür, das INTEGER und STRING verkettet werden.

In der Query Q_NoProblem werden über "SELECT PersNr, Nachname || ', ' || Vorname as Suchname from mitarbeiter;" zwei VARCHAR-Felder verkettet, so das keine implizite Konvertierung notwendig wird