PostgreSQL OEM / ANSI / Sonderzeichen.

Hier dreht es sich um den PostGre Server

Moderator: Moderatoren

Antworten
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

PostgreSQL OEM / ANSI / Sonderzeichen.

Beitrag von AUGE_OHR »

hi,

die default "Codepage" (?) Einstellung von PostgreSQL ist ja Win1252 -> ANSI ?

deutsche "Umlaute" sind OEM (?) aber pgAdmin.EXE kann die öffen / browsen !

nun gibt es aber auch noch "Sonderzeichen" ... und da "könnte" es ein Problem geben.
mit ConvToAnsiCP(cOEM) kann man das zwar alles "lösen" ... oder wie im Help File die Strings

Code: Alles auswählen

      cAnsi := Chr(196)+Chr(228)+Chr(214)+Chr(246)+Chr(220)+Chr(252) 
      cOem  := Chr(142)+Chr(132)+Chr(153)+Chr(148)+Chr(154)+Chr(129) 
benutzen und sich "selbst" was bauen.

ich habe nun mal meine "Problem" DBF "zerlegt" und alles > CHR(128) ausgeben lassen
Chr() Treffer
----------
129 90973
132 38148
142 8
148 23426
153 8733
154 1971

213 11
225 50601
228 212
239 315
245 3
246 212

das ist nun der Teststring OEM

"üäÄöÖÜıßõ´§÷"

das ist nun der Teststring ANSI

"„Ž”™šÕáäïõö"
meine User verwenden also "Sonderzeichen" die nicht im cANSI / cOEM String enthalten sind wie z.b.
213 hat geschrieben:Glutamat teurer +0,30 ı kg !
225 hat geschrieben:Sojasoße Mushroom dunkel
239 hat geschrieben:aus Holland Lee´s Food
245 hat geschrieben:Selbstentsorger gem § 6 Abs.3
und das wurde vermutlich auf einem chinesischen OS() eingegeben
246 hat geschrieben:Soja-Kõse/Chilli÷l LAO GAN MA
mit meinem "native" PGu.EXE komme ich an "beide" importierten Table, aber pgAdmin.EXE kann nur die nach "Edgar" Style, mit allen "Sonderzeichen",öffnen.
Edgar_FS_Import.PNG
Edgar_FS_Import.PNG (16.44 KiB) 15367 mal betrachtet
Der Unterschied liegt nur im "Field" für den "PRIMARY KEY"

Code: Alles auswählen

Edgar :
cQuery := "CREATE TABLE " + xtab + " (id numeric(6) NOT NULL default '0', "
...    // hier Rest Field Definitionen
cQuery += "PRIMARY KEY (id) ) "
und meiner Umstellung auf pgDBE "__record"

Code: Alles auswählen

Jimmy :
   cQuery += " __record     serial  NOT NULL, "
...    // hier Rest Field Definitionen
   cQuery += " CONSTRAINT "+ xtab + "_pkey PRIMARY KEY (__record)"
   cQuery += " )"                                 // NEED
aber wie kann sich das auf "Sonderzeichen" und "öffnen" mit pgAdmin.EXE zum Browse auswirken ?
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL OEM / ANSI / Sonderzeichen.

Beitrag von AUGE_OHR »

Nachtrag :

ich habe nun alle OEM als CHR() versucht in eine Table ala pgDBE einzulesen und die zu Browsen. Fazit : es geht mit

Code: Alles auswählen

cQuery += " CONSTRAINT "+ xtab + "_pkey PRIMARY KEY (__record)"
keine Zeichen > 128

man muss schon ConvToAnsiCP() benutzen um dann das zu bekommen
Import_ConvToAnsiCP.PNG
Import_ConvToAnsiCP.PNG (9.83 KiB) 15364 mal betrachtet
gruss by OHR
Jimmy
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: PostgreSQL OEM / ANSI / Sonderzeichen.

Beitrag von brandelh »

deutsche "Umlaute" sind OEM (?) aber pgAdmin.EXE kann die öffen / browsen !
natürlich NICHT !!!! ;-)
Deutsche Umlaute gibt es wie bekannt sein müsste in OEM und in ANSI, wobei bei ANSI noch einige Umlaute mehr enthalten sind ...
Ob die pgDBE das richtig umsetzen kann ist eventuell ein Problem, daher meine Empfehlung SET CHARSET TO ANSI und der Ärger ist weg ;-)
Zumindest mit SQLexpress, solange man den ODBC Treiber nimmt, der ANSI als Antwort liefert (bei PostgreSQL kann man sich das aussuchen, MySQL muss man beim älteren bleiben).
Im Server würde ich dennoch auf UTF8 Speicherung umstellen, denn wie wir ja alle wissen, gibt es verschiedene codepages für ANSI, UTF8 sollte alles speichern können.
Gruß
Hubert
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL OEM / ANSI / Sonderzeichen.

Beitrag von AUGE_OHR »

brandelh hat geschrieben:
deutsche "Umlaute" sind OEM (?) aber pgAdmin.EXE kann die öffen / browsen !
natürlich NICHT !!!! ;-)
diese Aussage steht am Anfang aber nachfolgend habe ich ja beschrieben das die "Einschränkung" sich scheinbar auf den "PRIMARY KEY" beschränkt wenn ich "__record" verwende. nur dann bekomme ich die 0x81 Error Meldung im Logfile !

Es mag auch auch an meiner "SELECT ..." Konstruktion liegen denn mit der Version von Edgar kann ich "alle" o.g. OEM Zeichen auch später im pgAdmin.EXE öffnen / Browsen.

ich "denke" das Alaska mit "__record" noch "irgendwo" was anstellt, aber wo ?
es gibt 2 "Trigger" für "UPDATE", "INSERT" und "DELETE" ... aber ich finde nichts mit "__record"

IMHO der Error "spricht" ja von UTF8, deshalb nehme ich an das es Alaska auf ANSI "beschränkt" hat ...
brandelh hat geschrieben:Deutsche Umlaute gibt es wie bekannt sein müsste in OEM und in ANSI, wobei bei ANSI noch einige Umlaute mehr enthalten sind ...
und was ist mit chinesisch ? Email werden doch nach UTF8 codiert/decodiert, oder ? damit ist chinesisch ja "kein Problem"
brandelh hat geschrieben:Ob die pgDBE das richtig umsetzen kann ist eventuell ein Problem, daher meine Empfehlung SET CHARSET TO ANSI und der Ärger ist weg ;-)
das wäre wohl die "beschränkte" ANSI Lösung für pgDBE ...
brandelh hat geschrieben:Im Server würde ich dennoch auf UTF8 Speicherung umstellen, denn wie wir ja alle wissen, gibt es verschiedene codepages für ANSI, UTF8 sollte alles speichern können.
Ja ... nur wird es Alaska "zulassen" mit pgDBE ?
es müsste ja alles "intern" von ANSI auf UTF8 umgestellt werden um es dann "verarbeiten" zu können.

wir sollten beim nächsten Chat mal in der Richtung "nachfragen" wie den die Pläne zu UTF8 aussehen
gruss by OHR
Jimmy
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: PostgreSQL OEM / ANSI / Sonderzeichen.

Beitrag von brandelh »

Hallo Jimmy,

ich verstehe nicht, warum du immer auf das __recno Feld gehen willst, wenn du ein SERIAL oder Primary Key Feld in einer bestimmten Form haben möchtest,
mach es selbst, auf die paar Byte kommt es bei TByte Platten nicht an und du bist unabhängig von Alaska.

Zum Thema Umlaute ... hier ist die Beschreibung von UTF8 hinterlegt:

UTF8 :arrow: http://de.wikipedia.org/wiki/Utf8
ANSI :arrow: http://de.wikipedia.org/wiki/ISO_8859

Zeichen 0-127 sind immer gleich mit dem 7-bit ASCII Zeichensatz.
Wenn am Server UTF8 als Zeichensatz eingestellt ist, muss von Ansi nach UTF8 konvertiert werden, das sollte der ANSI ODBC Treiber erledigen falls man den nutzt.
Daher habe ich mit SQLexpress vermutlich keine Probleme wenn ich ein GUI Programm in ANSI habe und der Server auf UTF8 speichert.
Vermutlich wird hierbei auch die ANSI Codepage von Windows mit berücksichtigt, somit sollte das immer stimmen.

Wenn nun die (aktuelle) pgDBE Ansi (oder 8-bit ASCII) liefert und nicht auf UTF8 umsetzt und das die API Funktion auch nicht automatisch erledigt,
dann passiert es, dass ein ANSI Zeichen gemeint ist, aber in UTF8 anders interpretiert wird. In UTF8 sind einige Byte an bestimmten Positionen verboten,
das könnte die 0x81 Fehlermeldung erklären, wobei damit NICHT das eigentliche Umlautzeichen gemeint ist, sondern lediglich die aktuelle Position nicht passt,
da es eine Art von Steuerzeichen (Bytefolgeneinleitung) ist.

Die Erklärung dazu steht in Wikipedia UTF8 (verbotene Zeichen ...)

Wie auch immer, wir können hier nur raten, frag das doch einfach genauer in der dafür vorgesehenen Alaska Newsgroup, eventuell musst du nur einen Schalter anders stellen ... ;-)
Gruß
Hubert
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL OEM / ANSI / Sonderzeichen.

Beitrag von AUGE_OHR »

brandelh hat geschrieben:ich verstehe nicht, warum du immer auf das __recno Feld gehen willst, wenn du ein SERIAL oder Primary Key Feld in einer bestimmten Form haben möchtest,
mach es selbst, auf die paar Byte kommt es bei TByte Platten nicht an und du bist unabhängig von Alaska.
wenn wir pgDBE bekommen bin ich ja an das vorgegebene Format in manchen Fällen "gebunden".
das es ja anders geht, wenn ich nicht " PRIMARY KEY (__record)" verwende, hab ich ja raus bekommen.
brandelh hat geschrieben:Wie auch immer, wir können hier nur raten, frag das doch einfach genauer in der dafür vorgesehenen Alaska Newsgroup, eventuell musst du nur einen Schalter anders stellen ... ;-)
YUP ... ich musste bloss erst mal paar Beispiele zusammenbauen die ich dem Support dann schicken kann.
den "Bug", das man mittels pgDBE, keine "Umlaute" im MDIDEMO "abspeichern" kann hab ich ja schon gemeldet ( bestätigt ),
also hoffe ich mal das dass jetzige Problem mit der nächsten CTP "gelöst" wird.
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL OEM / ANSI / Sonderzeichen.

Beitrag von AUGE_OHR »

hi,

hier ein kleines Tool um die Felder Type "C" einer DBF nach CHR() > 128 zu analysieren.
Check4PG.PNG
Check4PG.PNG (17.87 KiB) 15335 mal betrachtet
Dateianhänge
checkoem.zip
need ot4xb ( Progressbar DXE2012A.DLL )
(234.71 KiB) 504-mal heruntergeladen
gruss by OHR
Jimmy
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: PostgreSQL OEM / ANSI / Sonderzeichen.

Beitrag von brandelh »

AUGE_OHR hat geschrieben:
brandelh hat geschrieben:ich verstehe nicht, warum du immer auf das __recno Feld gehen willst, wenn du ein SERIAL oder Primary Key Feld in einer bestimmten Form haben möchtest,
mach es selbst, auf die paar Byte kommt es bei TByte Platten nicht an und du bist unabhängig von Alaska.
wenn wir pgDBE bekommen bin ich ja an das vorgegebene Format in manchen Fällen "gebunden".
NEIN, wir sind an nichts gebunden.
Wer UPSIZE nutzt, hat einige zusätzliche Felder die als intern (=> für Alaska) gekennzeichnet sind und die uns nichts angehen.
Alle anderen Felder können wir anlegen wie wir das brauchen.
Man kann doch mehrere primary key Felder anlegen oder :?
z.B. KundenNummer bei einer Kundendatei oder Lieferantennummer bei einer Lieferantendatei, beide dürfen keine doppelten Sätze erlauben,
die interne __recno ist mir dann erst mal egal, solange man nicht mit der pgDBE einen Browse bastelt, der nicht weiß, dass er auf einer SQL Tabelle browst.
Gruß
Hubert
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2823
Registriert: Fr, 08. Feb 2008 21:29
Hat sich bedankt: 95 Mal
Danksagung erhalten: 13 Mal

Re: PostgreSQL OEM / ANSI / Sonderzeichen.

Beitrag von georg »

Hallo,


ich entführe die Diskussion mal.

Grundsätzlich gilt, dass eine Tabelle auf einem SQL Server mehr als eine PRIMARY KEY Definition (!) haben kann.

Ist aber Unsinn, denn es kann keine zwei PRIMARY KEYs geben, da PRIMARY das (zumindest von der Sprachlogik her) ausschliesst.

Ich verwende PRIMARY KEY auf das Feld (die Felder), mit denen ein Datensatz in einer Datei EINDEUTIG beschrieben bzw. identifiziert wird. Das bedeutet auch, dass der Inhalt des PRIMARY KEY Feldes normalerweise (Ausnahmen bestätigen auch diese Regel) nicht verändert wird.

Für alle anderen Zugriffe, bei denen Werte innerhalb einer Spalte nur einmal vorkommen dürfen/sollen, erzeugt man einen Index mit dem Attribut UNIQUE. Hat den gleichen Effekt wie PRIMARY KEY, von der "Dokumentation" her zeigt man ganz klar: der Index mit PRIMARY KEY hat diese Funktion (z.B. auch um als FOREIGN KEY zu fungieren), dass andere (selbst mit UNIQUE) sind nur Zugriffsbeschreibungen, die der Geschwindigkeit dienen.

Kommen wir jetzt zu den internen Feldern, die Alaska hinzugefügt hat. Alaska hat in der Vergangenheit bereits gezeigt, dass sie in ihren Betas Dinge ausprobieren (siehe Xbase/2, wo zuerst mit Resource Dateien gearbeitet wurde, ehe die Entscheidung revidiert wurde und Xbase-Parts eingeführt wurden), die später eventuell geändert werden. (Diese Fähigkeit zur Veränderung empfinde ich als positiv: die Bereitschaft, Fehler oder unvorteilhafte Entscheidungen zu erkennen und zu korrigieren.)

Ich würde die Finger von internen Feldern lassen, selbst (oder gerade) wenn sie von Alaska kommen: hier kann es jederzeit Änderungen geben. Einen PRIMARY KEY verwende ich, um zwei (oder mehrere) Tabellen zu verknüpfen. Dazu muss der PRIMARY KEY der ersten Tabelle aber in der anderen Tabelle abgebildet sein. Ändert ein Mechanismus (z.B. ein Trigger) den PRIMARY KEY in der ersten Tabelle, so ist der korrespondierende Satz aus der zweiten Tabelle

- verwaist oder
- zeigt auf den falschen Satz in der ersten Datei

(Klar, man kann das über Trigger und Constraints abfangen, aber will man diesen Overhead wirklich betreiben?)

Dieses Risiko würde ich nicht eingehen wollen.

Nochmals: wer nach Paradigma sucht, findet u.a. einen Beitrag aus 2007 über die Ankündigung der SQL Erweiterung für Xbase - fünf Jahre ist das her, und ich habe einfach keine Lust (und keine Zeit) bestimmte Schritte länger hinauszuzögern. Lieber schreibe ich meine Programme um, so dass sie mit SQL laufen, anstelle noch länger zu warten.

Das gibt mir aber auch die Freiheit, selbst über die Inhalte meiner Dateien zu entscheiden und mich nicht mit zusätzlichen Triggern, Feldern, Constraints etc. herumzuschlagen, die Alaska einbauen muss, um die DBF-Logik erhalten zu können.


Gruss,

Georg
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL OEM / ANSI / Sonderzeichen.

Beitrag von AUGE_OHR »

brandelh hat geschrieben:NEIN, wir sind an nichts gebunden.
Wer UPSIZE nutzt, hat einige zusätzliche Felder die als intern (=> für Alaska) gekennzeichnet sind und die uns nichts angehen.
das "intern" sehe ich nicht wenn es meinem Server geschied.
klar ist mir schon das es ein Teil des Konzept von Alaska ist und "das" macht auch den Unterschied
brandelh hat geschrieben:Alle anderen Felder können wir anlegen wie wir das brauchen.
wenn ich auf dem, mit DbfUpsize.EXE behandelten, PG Server "selbst" ein Feld "__record" anlege "dann" tritt der Unterschied ein.
nenne ich statt "__record" das Field "id" nenne ich keine Problem, egal was in den Fields ist, mit PgAdmin.EXE

wir können also anscheint nicht auf einem solchen PG Server das machen was wir wollen. ( KeyWord )
brandelh hat geschrieben:Man kann doch mehrere primary key Felder anlegen oder :?
z.B. KundenNummer bei einer Kundendatei oder Lieferantennummer bei einer Lieferantendatei, beide dürfen keine doppelten Sätze erlauben,
soweit bin ich noch gar nicht. "__record" als "PRIMARY KEY" erstmal zu übernehmen hatte sich "angeboten"
brandelh hat geschrieben:die interne __recno ist mir dann erst mal egal, solange man nicht mit der pgDBE einen Browse bastelt, der nicht weiß, dass er auf einer SQL Tabelle browst.
dem Browse ist das doch "egal" ;)

ich werde einen neune Thread mit LIMIT / OFFSET starten
gruss by OHR
Jimmy
bgl
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 43
Registriert: Di, 30. Aug 2011 20:45

Re: PostgreSQL OEM / ANSI / Sonderzeichen.

Beitrag von bgl »

So lange der Client und der Server für Zugriff und Speicherung immer den gleichen Datentyp benutzen ist die Codepage eigentlich fast egal.

Warum? Ganz einfach: ich kann in eine OEM-DB durchaus UTF-8 Inhalte schreiben, auch wenn sie dann aus der Konsole nicht sinnvoll abzurufen sind, so kann ich sie doch mit dem gleichen Client wieder abrufen und ausgeben.

Sinnvoll ist es natürlich, wenn alles mit dem gleichen Zeichensatz arbeitet, aber so lange alle Clients mit dem gleichen Zeichensatz arbeiten und man die Bezeichner nicht mit Umlauten versieht (wer tut sowas denn auch?!) sollte das eigentlich wenig Auswirkungen haben.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL OEM / ANSI / Sonderzeichen.

Beitrag von AUGE_OHR »

hi,
bgl hat geschrieben:und man die Bezeichner nicht mit Umlauten versieht (wer tut sowas denn auch?!) sollte das eigentlich wenig Auswirkungen haben.
ich bezog mich nicht auf "Field" Namen sondern auf den "Inhalt" eines Field Type "C" der keine OEM -> deutsche "Umlaute" enthalten darf mit WIN1252
gruss by OHR
Jimmy
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2828
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Hat sich bedankt: 259 Mal
Danksagung erhalten: 12 Mal
Kontaktdaten:

Re: PostgreSQL OEM / ANSI / Sonderzeichen.

Beitrag von UliTs »

AUGE_OHR hat geschrieben:ich bezog mich nicht auf "Field" Namen sondern auf den "Inhalt" eines Field Type "C" der keine OEM -> deutsche "Umlaute" enthalten darf mit WIN1252
Aber die Antwort von bgi hast Du sicher verstanden :shock: :? :) .
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL OEM / ANSI / Sonderzeichen.

Beitrag von AUGE_OHR »

UliTs hat geschrieben:
AUGE_OHR hat geschrieben:ich bezog mich nicht auf "Field" Namen sondern auf den "Inhalt" eines Field Type "C" der keine OEM -> deutsche "Umlaute" enthalten darf mit WIN1252
Aber die Antwort von bgi hast Du sicher verstanden :shock: :? :) .
nö ... erkläre es doch ;)
gruss by OHR
Jimmy
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2828
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Hat sich bedankt: 259 Mal
Danksagung erhalten: 12 Mal
Kontaktdaten:

Re: PostgreSQL OEM / ANSI / Sonderzeichen.

Beitrag von UliTs »

AUGE_OHR hat geschrieben:nö ... erkläre es doch ;)
Was ist los, Jimmy :?:
Zeichensätze sind doch eigentlich Dein Steckenpferd :D .
So lang es 8-Bit-Zeichensätze sind, ist es egal, was der Server "denkt" 8) .
Aber ob das auch für die Sortierung gilt, wage ich zu bezweifelnt 8) 8) .

Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL OEM / ANSI / Sonderzeichen.

Beitrag von AUGE_OHR »

du hast meine "Einschränkung" bei der Antwort auf "Fieldname" übersehen das es doch wohl klar sein sollte,
wie bei DBF Dateien, dass der "Feldname" keine "Umlaute" enthalten sollte.

weiterhin habe ich es auf Codepage Win1252 bezogen die ich sicherlich nicht für meine chinesischen OEM DBF verwenden werde.

die "normalen" deutschen "Umlaute" kann man ja mit ConvToAnsiCP() behandeln.

Frage : was ist mit dem "ß" CHR(225) ?

Problem : Feld Länge wenn man STRTRAN(cText,"ß", 2x"s" ) ausführt

Frage : was ist mit dem € Euro Zeichen ?
gruss by OHR
Jimmy
bgl
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 43
Registriert: Di, 30. Aug 2011 20:45

Re: PostgreSQL OEM / ANSI / Sonderzeichen.

Beitrag von bgl »

Nochmal: der Zeichensatz sollte eigentlich nur dann ins Gewicht fallen, wenn a) unterschiedliche Clients mit variablen Charsets zugreifen, oder b) das Feld zum durchsuchen/sortieren "in der Datenkbank" genutzt werden soll.

Ansonsten gilt, dass du rauskriegen solltest, was du reinkippst - unabhängig davon, ob die Datenbank es jetzt versteht, oder nicht.

Problematischer wirds natürlich, wenn der Treiber deine Zeichen zerlegt... und während ich dir raussuchen könnte, wie du den vom PostgreSQL-Server verwendeten Zeichensatz änderst wird das mit dem Treiber leider etwas schwieriger (sorry, mein Fachgebiet ist halt SQL, nicht XBase++).



Um das zu verdeutlichen: wenn du einen Editor hast, in dem sich der Zeichensatz eines offenen Dokuments einstellen lässt (ich empfehle SciTE, das Programm ist einfach toll), dann probier doch mal folgendes aus:

Leg eine neue Datei an (keine Speicherung notwendig) und gib folgendes dort ein:

"Kachelöfen im Angebot für € 500,-"

Das ist dein Feldinhalt, wenn du ihn in die Datenbank eingibt - in einem beliebigen Format.

Jetzt stell den Dokument-Zeichensatz auf ANSI um.

Das ist dein Feldinhalt, wie ihn der Server sieht. Der wird vermutlich ein wenig defekt sein, aber so lange der Server ihn nicht verstehen muss ist das ziemlich egal.

Jetzt stell das ganze wieder auf den ursprünglichen Zeichensatz zurück:

So sieht es ein Client, der den gleichen Zeichensatz benutzt, wie der, mit dem das ganze eingegeben wurde.

Du wirst feststellen, dass nur der Server die Daten nicht "richtig" sehen kann. Selbst UTF-8 wird lediglich in einigen Fällen als 2 Zeichen gespeichert, ist aber sauber aus einem ISO-Zeichensatz in der Datenbank wieder auszulesen.

Bleibt die Frage, wie der Treiber das handhabt. Da habe ich aber immer noch keine Antwort.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL OEM / ANSI / Sonderzeichen.

Beitrag von AUGE_OHR »

hi,

wenn ich die Table erst mal habe bekomme kann ich "alles mögliche" eingetippt...
die Fehlermeldung 0x81 UTF-8 kommt aber beim "Import" mit "INSERT"

nun muss man immer dazu anmerken das ich auf dem von "DbfUpSize.EXE"
behandelten Server arbeite und das macht, so Edgar der ja kein Teilnehmer war,
in einigen Dingen einen Unterschied.

wir haben heute gerade das Devcon Material erhalten und ich habe eine Datei "northwind.postgresql.sql" gefunden.
--
-- Northwind SQL Datbase for PostgreSQL, adaption by Alaska Software
-- original sources at Google code project: http://code.google.com/p/northwindextended/
--
SET statement_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = on;
SET check_function_bodies = false;
SET client_min_messages = warning;
wer Lust hat kann sich die restlichen Zeilen selbst ansehen.

ich "denke" das die "Beschränkung" Teil von Alaska sind und wir deshalb unsere DBF Dateien überprüfen sollten bevor man einen Import versucht.
gruss by OHR
Jimmy
Antworten