PostgreSQL v8.3 vs v9.1

Alles zum SQL-Dialekt

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 v8.3 vs v9.1

Beitrag von AUGE_OHR »

hi,

ich habe von v8.3 auf v9.1 umgestellt.

gute Nachricht : DbfUpSize.EXE sowie PGu.EXE laufen

aber ich hab ein anderes "Problem" : Die Reihenfolge der Fields ist jetzt "verkehrt rum" ...

Code: Alles auswählen

METHOD PGSql:dbStruct( cTable )                             // Edgar

LOCAL aStruct := {}
LOCAL oStruct, i, iMax
LOCAL cField, cType, nLen, nDec
LOCAL cWhere  := ""

   ::exec( "SELECT column_name, data_type, character_maximum_length, numeric_precision, numeric_scale " + ;
           "FROM information_schema.columns WHERE table_name='" + cTable + "'" )

   oStruct := ::result

   iMax := oStruct:rows                                     // add    by Jimmy (debug)
   FOR i = 1 TO iMax                                        // change by Jimmy

      cField := oStruct:GetValue( i - 1, 0 )
      cType := UPPER( SUBSTR( oStruct:GetValue( i - 1, 1 ), 1, 1 ) )
      DO CASE
         CASE cType = "C"
            nLen := oStruct:FieldGet( i - 1, 2 )
            nDec := 0
         CASE cType = "D"
            nLen := 10
            nDec := 0
         CASE cType = "T"
            cType := "M"
            nLen := oStruct:FieldGet( i - 1, 2 )
            nDec := 0
         CASE cType = "N"
            nLen := oStruct:FieldGet( i - 1, 3 )
            nDec := oStruct:FieldGet( i - 1, 4 )

         CASE cType = "I"                                   // Jimmy
            nLen := oStruct:FieldGet( i - 1, 3 )
            nDec := oStruct:FieldGet( i - 1, 4 )
         CASE cType = "B"                                   // Jimmy
            nLen := 1
            nDec := 0

      ENDCASE

      AADD( aStruct, { cField, cType, nLen, nDec } )
   NEXT

RETURN ( aStruct )
das ist zwar kein Problem die FOR / NEXT mit STEP -1 laufen zu lassen aber es stellt sich natürlich die Frage ob es nur hier "reverse" ist.
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 v8.3 vs v9.1

Beitrag von AUGE_OHR »

hi,

ich muss ja erst im "Catalog" eine Datenbank "mdidemo" erstellen bevor DbfUpSize.EXE funktioniert.
in der v9.14 Version gibt er mir nun das aus :

Code: Alles auswählen

CREATE DATABASE mdidemo
  WITH OWNER = postgres
       ENCODING = 'UTF8'
       TABLESPACE = pg_default
       LC_COLLATE = 'German_Germany.1252'
       LC_CTYPE = 'German_Germany.1252'
       CONNECTION LIMIT = -1;

COMMENT ON DATABASE mdidemo
  IS 'muss manuell angelegt werden';
wie man sieht sind jetzt die LC_* Konstanten vorhanden und ich bin mir nicht sicher was 'German_Germany.1252' jetzt bedeutet.

dazu kommt das nun mein Import Modul wieder meckert ...
2012-08-12 01:46:26 CEST FEHLER: ungültige Byte-Sequenz für Kodierung »UTF8«: 0xe4686e
2012-08-12 01:46:43 CEST FEHLER: ungültige Byte-Sequenz für Kodierung »UTF8«: 0xe47474
2012-08-12 01:46:45 CEST FEHLER: ungültige Byte-Sequenz für Kodierung »UTF8«: 0xe4686e
2012-08-12 01:46:46 CEST FEHLER: ungültige Byte-Sequenz für Kodierung »UTF8«: 0xd66c
2012-08-12 01:46:47 CEST FEHLER: ungültige Byte-Sequenz für Kodierung »UTF8«: 0xfc
2012-08-12 01:46:47 CEST FEHLER: ungültige Byte-Sequenz für Kodierung »UTF8«: 0xe4686e
2012-08-12 01:46:48 CEST FEHLER: ungültige Byte-Sequenz für Kodierung »UTF8«: 0xd66c
2012-08-12 01:46:48 CEST FEHLER: ungültige Byte-Sequenz für Kodierung »UTF8«: 0xe4686e
2012-08-12 01:46:49 CEST FEHLER: ungültige Byte-Sequenz für Kodierung »UTF8«: 0xfc
2012-08-12 01:46:49 CEST FEHLER: ungültige Byte-Sequenz für Kodierung »UTF8«: 0xf6746368
2012-08-12 01:46:50 CEST FEHLER: ungültige Byte-Sequenz für Kodierung »UTF8«: 0xfc
2012-08-12 01:46:50 CEST FEHLER: ungültige Byte-Sequenz für Kodierung »UTF8«: 0xd66c
2012-08-12 01:46:51 CEST FEHLER: ungültige Byte-Sequenz für Kodierung »UTF8«: 0xf6746368
2012-08-12 01:46:51 CEST FEHLER: ungültige Byte-Sequenz für Kodierung »UTF8«: 0xfc
2012-08-12 01:46:52 CEST FEHLER: ungültige Byte-Sequenz für Kodierung »UTF8«: 0xe4686e
2012-08-12 01:46:52 CEST FEHLER: ungültige Byte-Sequenz für Kodierung »UTF8«: 0xfc
2012-08-12 01:46:53 CEST FEHLER: ungültige Byte-Sequenz für Kodierung »UTF8«: 0xf6746368
2012-08-12 01:46:53 CEST FEHLER: ungültige Byte-Sequenz für Kodierung »UTF8«: 0xe4686e
2012-08-12 01:46:54 CEST FEHLER: ungültige Byte-Sequenz für Kodierung »UTF8«: 0xfc
2012-08-12 01:46:54 CEST FEHLER: ungültige Byte-Sequenz für Kodierung »UTF8«: 0xfc
...
es scheinen wieder die "Umlaute" zu sein ... :banghead:
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 v8.3 vs v9.1

Beitrag von AUGE_OHR »

hi,

also mit 'German_Germany.1252' hab ich tatsächlich wieder "Umlaut" Probleme.

hiermit erzeuge ich eine Test DBF und versuche die zu importieren ... mit / ohne "konvertieren"

Code: Alles auswählen

PROCEDURE MAIN
   C_MAKERROR( "MAKERROR.DBF" )
RETURN


FUNCTION C_MAKERROR( datei, alias, id )
LOCAL p, field_list := {}
   IF VALTYPE( datei ) != "C"
      datei = "MAKERROR.DBF"
   ENDIF
   IF VALTYPE( alias ) != "C"
      p = AT( ".", datei )
      alias = IF( p > 0, SUBSTR( datei, 1, p - 1 ), datei )
   ENDIF
   IF VALTYPE( id ) != "N"
      id = 0
   ENDIF
   SELECT( id )
   IF !FILE( datei )
      AADD( field_list, { "MYSIGN", "C", 1, 0 } )
      AADD( field_list, { "MYNUM", "N", 3, 0 } )
      DBCREATE( datei, field_list, "DBFNTX" )
   ENDIF
   USE (datei) ALIAS (alias) VIA "DBFNTX" EXCLUSIVE

// cOem  := Chr(142)+Chr(132)+Chr(153)+Chr(148)+Chr(154)+Chr(129)

   APPEND BLANK
   REPLACE MYSIGN WITH CHR( 129 )  // 
   REPLACE MYNUM WITH      129
   APPEND BLANK
   REPLACE MYSIGN WITH CHR( 132 )  // „
   REPLACE MYNUM WITH      132
   APPEND BLANK
   REPLACE MYSIGN WITH CHR( 142 )  // Ž
   REPLACE MYNUM WITH      142
   APPEND BLANK
   REPLACE MYSIGN WITH CHR( 148 )  // ”
   REPLACE MYNUM WITH      148
   APPEND BLANK
   REPLACE MYSIGN WITH CHR( 153 )  // ™
   REPLACE MYNUM WITH      153
   APPEND BLANK
   REPLACE MYSIGN WITH CHR( 154 )  // š
   REPLACE MYNUM WITH      154


// cAnsi := Chr(196)+Chr(228)+Chr(214)+Chr(246)+Chr(220)+Chr(252)

   APPEND BLANK
   REPLACE MYSIGN WITH CHR( 252 )  // 
   REPLACE MYNUM WITH      252
   APPEND BLANK
   REPLACE MYSIGN WITH CHR( 228 )  // „
   REPLACE MYNUM WITH      228
   APPEND BLANK
   REPLACE MYSIGN WITH CHR( 196 )  // Ž
   REPLACE MYNUM WITH      196
   APPEND BLANK
   REPLACE MYSIGN WITH CHR( 246 )  // ”
   REPLACE MYNUM WITH      246
   APPEND BLANK
   REPLACE MYSIGN WITH CHR( 214 )  // ™
   REPLACE MYNUM WITH      214
   APPEND BLANK
   REPLACE MYSIGN WITH CHR( 220 )  // š
   REPLACE MYNUM WITH      220


// some other

   APPEND BLANK
   REPLACE MYSIGN WITH CHR( 213 )  // i
   REPLACE MYNUM WITH      213
   APPEND BLANK
   REPLACE MYSIGN WITH CHR( 225 )  // á
   REPLACE MYNUM WITH      225
   APPEND BLANK
   REPLACE MYSIGN WITH CHR( 228 )  // ä
   REPLACE MYNUM WITH      228
   APPEND BLANK
   REPLACE MYSIGN WITH CHR( 239 )  // ï
   REPLACE MYNUM WITH      239
   APPEND BLANK
   REPLACE MYSIGN WITH CHR( 245 )  // õ
   REPLACE MYNUM WITH      245
   APPEND BLANK
   REPLACE MYSIGN WITH CHR( 246 )  // ö
   REPLACE MYNUM WITH      246

   CLOSE

RETURN ( .t. )
nun habe ich zunächst "ohne alles" versucht ... Table wird angelegt aber kein einziger gelungener "Import"***

dann also mit ConvToAnsiCP() aber nur 3 Zeichen (196,220,213) kamen durch***

was nun gar nicht gehen sollte ist ConvToOemCP() ... aber da bekomme ich noch die meisten "importiert"***

nur leider hat das gar nichts mit dem zu tun was ich möchte
PG91_OEM_ANSI.PNG
PG91_OEM_ANSI.PNG (18.02 KiB) 5362 mal betrachtet
was ist den nun für 'German_Germany.1252' nun notwendig um "Umlaute" zu bekommen ???

*** als Logfile als Attachment
Dateianhänge
PG_OEM_ANSI.ZIP
Logfile mit PostgreSQL Error Meldungen
(2.5 KiB) 361-mal heruntergeladen
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 v8.3 vs v9.1

Beitrag von AUGE_OHR »

hi,

Code: Alles auswählen

-- Database: mdidemo

-- DROP DATABASE mdidemo;

CREATE DATABASE mdidemo
  WITH OWNER = postgres
       ENCODING = 'WIN1252'
       TABLESPACE = pg_default
       LC_COLLATE = 'German_Germany.1252'
       LC_CTYPE = 'German_Germany.1252'
       CONNECTION LIMIT = -1;

COMMENT ON DATABASE mdidemo
  IS 'manuelle
win1512';
ich habe mir die v8.3 angesehen und bei der Erstellung von "mdidemo" die Parameter angepasst. Damit läuft der Import wieder ;)

wenn man also PostgreSQL v9.x installiert sollte man NICHT default UTF-8 verwenden sondern muss auf WIN1252 umstellen sonst bekommt man mit den "Umlauten" dann Probleme.
gruss by OHR
Jimmy
Antworten