PostgreSQL "PRIMARY KEY"

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 "PRIMARY KEY"

Beitrag von AUGE_OHR »

hi,

ich habe meinem DBF -> PG "Import" umgebaut und die "__"fields, welche pgDBE verwendet, übernommen.
vorher hatte ich von Edgar ein Field "id"

Code: Alles auswählen

   cQuery := "CREATE TABLE " + xtab + " (id numeric(6) NOT NULL default '0', "

   aStrut := dbStruct()
   cInser := "INSERT INTO " + xtab + " (id"
   for i = 1 to len(aStrut)
      cQuery := cQuery + aStrut[i,1]
      cInser := cInser + ", " + aStrut[i,1]
      do case
      case aStrut[i,2] = "C"
         cQuery := cQuery + " character(" + alltrim(str(aStrut[i,3])) + "), "
      case aStrut[i,2] = "N"
         cQuery := cQuery + " numeric(" + alltrim(str(aStrut[i,3])) + ',' + alltrim(str(aStrut[i,4])) + "), "
      case aStrut[i,2] = "D"
         cQuery := cQuery + " date, "
      case aStrut[i,2] = "M"
         cQuery := cQuery + " text, "
      endcase
   next     // len(aStrut)

   cQuery := cQuery + "PRIMARY KEY (id) ) "
also "vorne" als erstes das Field "id" welches der "PRIMARY KEY" sein sollte.

nun möchte ich das auf __record ändern und hab den Code so abgeändert :

Code: Alles auswählen

   cQuery := "CREATE TABLE " + xtab + " ( "

   for i = 1 to len(aStrut)
   ...
   next     // len(aStrut)
//
// from "id" change to "__record"
//
// add "internal" Fields
//
cQuery += " __deleted    boolean NOT NULL DEFAULT false"+", "
cQuery += " __record     serial  PRIMARY KEY NOT NULL"+", "
cQuery += " __rowversion integer NOT NULL DEFAULT 0"+", "
cQuery += " __keyversion integer NOT NULL DEFAULT 0"+", "
cQuery += " __lock_owner integer NOT NULL DEFAULT 0  "

cQuery += ")"                                 // NEED
*cQuery += ";"                                // hm ... nur für den Interperter statt "ENTER"
das ganze nun im Logfile
DBF : E:\Alaska\XPPYIU\DATEN\FSICHER RDD : DBFNTX -> Table : FSICHER3
use DBF E:\Alaska\XPPYIU\DATEN\FSICHER VIA DBFNTX
Create Table FSICHER3

CREATE TABLE FSICHER3 ( FKDNR character(5), FMONAT character(2), FNUMMER numeric(5,0), FARTNR character(5), FARTIKEL character(30), FANZAHL numeric(7,2),FEINH character(3), BPREIS numeric(8,2), FSTUECK character(10), FMWST numeric(2,0), MSCHL character(1), FPREIS numeric(8,2), SKONTO numeric(5,2), FJAHR character(2), FFTAG character(2), FFMONAT character(2), FFJAHR character(2), FTEXT character(40), DFLAG character(1), LIEFNR character(5), LFLAG character(1), RECHWAHL character(1), AQNR character(9),
__deleted boolean NOT NULL DEFAULT false,
__record serial PRIMARY KEY NOT NULL,
__rowversion integer NOT NULL DEFAULT 0,
__keyversion integer NOT NULL DEFAULT 0,
__lock_owner integer NOT NULL DEFAULT 0 );

finish after 774.81 Sec. for 560818 Records = 723.81
einen einzelnen Record übertrage ich so

Code: Alles auswählen

//
// add default
//
cIns += "false"+", "                        // "__deleted"
cIns += LTRIM(STR( nCount,7) )+"," // "__record"
cIns += "0"+", "                            // "__rowversion"
cIns += "0"+", "                            // "__keyversion"
cIns += "0"                                 // "__lock_owner"
cIns += ")"
Frage : darf ich __record, was Type "serial" ist so füllen ?
jedes "INSERT" sieht so aus
INSERT INTO FSICHER3 VALUES( '24415', '05', 1024, '2309E', 'Curry, Englisch', 1.00, 'Pkt', 9.95, '1kg', 7, '2', 9.95, 0.00, '12', '04', '05', '12', 'Liefer Datum vom 04.05.12', 'N', '01198', 'L', '', '201201688',false,560818,0,0,0 )
er läuft damit auch durch und ich kann mit PGu.EXE die Table öffnen/browsen/editieren/saven

aber ich bekomme keine Anzeige wenn ich die jetzt mit pgAdmin.EXE browse :banghead: ... ja er sagt/"zählt" 560818 Records ...

wer kann mir einen Tip geben warum pgAdmin.EXE beim Browse abbricht ?

p.s. ich habe den Import sowohl unter "middemo" (pgDBE) als auch unter "Vendas" (Edgar) durchgeführt
gruss by OHR
Jimmy
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: PostgreSQL "PRIMARY KEY"

Beitrag von Tom »

Hallo, Jimmy.

Wenn ich das richtig verstehe, wird über eine implizite "Sequence" beim Datentyp "SERIAL" dafür gesorgt, dass es inhaltliche Konsistenz gibt:

http://ulf.zeitform.de/en/documents/pos ... ml#sec-2-1

Das besagt auch dieses Dokument:

http://cornelia-boenigk.de/pg/pg-datentypen.pdf (Seite 3)

Setzt man also eine beliebigen Wert für einen Datentypen "SERIAL" ein, sorgt der Server dafür, dass die Strecke dorthin abgedeckt ist. Wie gesagt, das ist mein Verständnis, aber ausprobiert habe ich's noch nicht.
Herzlich,
Tom
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 "PRIMARY KEY"

Beitrag von brandelh »

Hi,

ich denke, dass man ein SERIAL Feld nicht selbst setzen darf, das macht der Server selbständig.

Code: Alles auswählen

      ...
      recno serial PRIMARY KEY NOT NULL,
      ...
      oStmt:SQLString := "INSERT INTO UVCD (recno,UZTP, UNF_NR) VALUES (1000,'Manuell','1000 als Startwert') "
      if oStmt:Execute() = SQL_XPP_ERROR
         ? "Fehler bei INSERT  UVCD in RECNO"
         msgbox( "Fehler aufgetreten bei recno Zuweisung, Abbruch" )
         quit
      endif
erzeugt bei mir eine Fehlermeldung, wenn ich recno nicht zuweise, wird dies automatisch hochgezählt.
Gelöschte Zeilen und ein "pack" (vacuum) ändern das serial (recno) feld nicht !

Schau mal im Schema unter Sequenzen nach, dort wird die Regel für das serial Feld gespeichert.
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 "PRIMARY KEY"

Beitrag von AUGE_OHR »

hi,

hab noch was entdeckt
Sequenzen__record.PNG
Sequenzen__record.PNG (22.74 KiB) 9436 mal betrachtet
auch wenn da nun > 500000 Records sind zeigt er 1 an ?
auch habe ich nichts unter "Sequenzen" angelegt und vorher (Edgar) hat er da nichts angelegt ...
Sequenzen2__record.PNG
Sequenzen2__record.PNG (21.21 KiB) 9436 mal betrachtet
dort wird Menge +1 angezeigt.
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 "PRIMARY KEY"

Beitrag von brandelh »

Die Sequenz legt PostGre beim CREATE TABLE an, wenn man ein SERIAL Feld definiert !
Ein DROP TABLE (löscht auch den Eintrag) und ein neues CREATE TABLE und man ist wieder bei 1 ... refresh nicht vergessen ;-)
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 "PRIMARY KEY"

Beitrag von AUGE_OHR »

brandelh hat geschrieben:ich denke, dass man ein SERIAL Feld nicht selbst setzen darf, das macht der Server selbständig.

Code: Alles auswählen

      ...
erzeugt bei mir eine Fehlermeldung, wenn ich recno nicht zuweise, wird dies automatisch hochgezählt.
Gelöschte Zeilen und ein "pack" (vacuum) ändern das serial (recno) feld nicht !
ok ...
brandelh hat geschrieben:Schau mal im Schema unter Sequenzen nach, dort wird die Regel für das serial Feld gespeichert.
hm ... meinst du das hier ?

Code: Alles auswählen

  __deleted boolean NOT NULL DEFAULT false,
  __record serial NOT NULL,
  __rowversion integer NOT NULL DEFAULT 0,
  __keyversion integer NOT NULL DEFAULT 0,
  __lock_owner integer NOT NULL DEFAULT 0,
  __order_custa_custa character(17),
  __order_custb_custb character(51),
  CONSTRAINT customer_pkey PRIMARY KEY (__record)
)
ich sehe da was mit

Code: Alles auswählen

CONSTRAINT customer_pkey PRIMARY KEY (__record)
hm ... :-k ... :idea:




ich habe es wohl raus :)
also mit ", ," bei "serial" geht es nicht und mit ",0," bekomme ich 1 Record ... mit "0"

nun hab ich mit CONSTRAINT das ganze so am laufen

Code: Alles auswählen

DBF : D:\ALASKA\PG\MWSTFIBU.DBF RDD : DBFNTX -> Table : MW3                     
use DBF D:\ALASKA\PG\MWSTFIBU.DBF VIA DBFNTX                                    
Create Table MW3                                                                

CREATE TABLE MW3 ( MWSTVON date, MWSTBIS date, 
...
__deleted    boolean NOT NULL DEFAULT false,
__record     serial  NOT NULL,
__rowversion integer NOT NULL DEFAULT 0,  
__keyversion integer NOT NULL DEFAULT 0,  
__lock_owner integer NOT NULL DEFAULT 0,           
CONSTRAINT MW3_pkey PRIMARY KEY (__record) )
wohl geschafft und pgAdmin.EXE zeigt mir die 3 Record an wenn ich "serial" normal "hoch-zähle" :)
ein einzelnes "UPDATE" sieht dabei so aus

Code: Alles auswählen

INSERT INTO MW3 VALUES( '01.01.08', '31.12.99', 7.00, '08300', 19.00, '08400', 16.00, '08341', '08125', '08125', '08770', '08730', '08600', '08600', '08405', '', '', '08780', '08731', '08790', '08735', '0085403', '19011', 1.955830, 743, 2012, 'C:\\YIUIMEX\\',false,3,0,0,0 )
wofür es dann diese Warnung gibt
2012-07-12 10:13:38 CEST WARNING: nonstandard use of \\ in a string literal at character 244
2012-07-12 10:13:38 CEST HINT: Use the escape string syntax for backslashes, e.g., E'\\'.
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 "PRIMARY KEY"

Beitrag von AUGE_OHR »

bei der "kleinen" DBF mit 3 Records funktioniert es ... mit der "grossen" geht der Import ebenfalls ohne Logfile Eintrag...

aber sie "grosse" lässt sich wieder nicht öffnen ???
2012-07-12 10:57:02 CEST LOG: loaded library "$libdir/plugins/plugin_debugger.dll"
2012-07-12 10:57:35 CEST NOTICE: CREATE TABLE will create implicit sequence "fs3___record_seq" for serial column "fs3.__record"
2012-07-12 10:57:35 CEST NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "fs3_pkey" for table "fs3"
2012-07-12 11:11:22 CEST LOG: loaded library "$libdir/plugins/plugin_debugger.dll"
2012-07-12 11:11:26 CEST LOG: loaded library "$libdir/plugins/plugin_debugger.dll"
2012-07-12 11:11:36 CEST LOG: loaded library "$libdir/plugins/plugin_debugger.dll"
2012-07-12 11:11:36 CEST ERROR: character 0x81 of encoding "WIN1252" has no equivalent in "UTF8"
2012-07-12 11:11:36 CEST STATEMENT: SELECT * FROM public.fs3
ORDER BY __record ASC
was soll "character 0x81" bedeuten wenn pgAdmin.EXE darauf zugreifen will und bei der "grossen" abbricht ?
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 "PRIMARY KEY"

Beitrag von brandelh »

0x81 ist HEX 81 -> 16*8+1 = chr(129) und wenn ich mit DOS Zeichensatz ALT 129 eingebe, zeigt mein MED 0x81 als Zeichen an: ü

Könnte es sein, dass du OEM nach Ansi wandeln mußt, bevor du nach UTF8 wandelst ?

PS: Die Anzahl der gefundenen Datensätze muss man begrenzen, dafür gibt es in der Mitte eine Schaltfläche.
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 "PRIMARY KEY"

Beitrag von AUGE_OHR »

2012-07-12 11:11:36 CEST ERROR: character 0x81 of encoding "WIN1252" has no equivalent in "UTF8"
irgendwie hätte ich meinem PGu.EXE nicht "trauen" sollen als er mir "äöüÄAÜß" anzeigte ...

PostgreSQL ist ja auf "WIN1252" default eingestell was ANSI ist :!:
also muss ich meine OEM DBF Felder ( Type "C") per ConvToAnsiCP() nach ANSI konvertieren damit pgAdmin.EXE nicht meckert.

so nachdem die Hürde geschafft ist kann pgAdmin.EXE die Table öffnen (ca. 39 Sec.***.) und anzeigen.

als "Vergleich" hier nun PGu.EXE
Send Query :
SELECT table_name FROM information_schema.tables WHERE table_schema = 'public'
9 Tables:
alaska-software.isam.tables
alaska-software.isam.orders
alaska-software.system.connections
artikel
customer
parts
mwstfibu
umsatz
fsicher

select Table : fsicher AS a
Send Query :
SELECT * FROM fsicher AS a LIMIT 1
Answer Result :

fkdnr C 5
...
aqnr C 9

28 Fields :

used Fields for Column :

a.fkdnr
...
a.__deleted
a.__record
a.__rowversion
a.__keyversion
a.__lock_owner

now browse

SELECT a.fkdnr ...
a.__deleted,a.__record,a.__rowversion,a.__keyversion,a.__lock_owner FROM fsicher AS a

Start request :
finsh request after 12.97 Sec.
create Browse :
Browse Pop-Up after 0.69 Sec.
man sieht das die "Anzeige" kaum Zeit braucht und PGu.EXE bei "der" Table um einiges schneller ist bis man was sieht :)

*** P4 , 3Ghz HT, HD 7200rpm, 12ms

es gibt wohl eine Einstellung
SQL_ASCII means "no encoding".
was ich wohl für chinesisch benötigen werde ...
On 11/09/2010 02:31 AM, Carlos Henrique Reimer wrote:
...
PostgreSQL doesn't support the cp850 encoding
also braucht man "cp850" wohl nicht zu probieren.
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 "PRIMARY KEY"

Beitrag von AUGE_OHR »

brandelh hat geschrieben:Könnte es sein, dass du OEM nach Ansi wandeln mußt, bevor du nach UTF8 wandelst ?
YUP ... ich hatte mich "täuschen" lassen von anderen Test Ergebnissen #-o
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 "PRIMARY KEY"

Beitrag von AUGE_OHR »

verdammt nochmal ... ganz "so" stimmt es auch nicht mit ANSI
ich hab die Umsatz.DBF ohne ConvToAnsiCP() in die PG Table geschoben und über "München","Schwäbisch Hall" oder "Donauwörth" meckert pgAdmin.EXE nicht ...

grundsätzlich ist aber ConvToAnsiCP() schon richtig ... und "Umlaute" gehen wohl doch mit ...

:banghead: also was ist dann ... muss wohl weiter suchen ...
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 "PRIMARY KEY"

Beitrag von brandelh »

Hi,

wenn dein Anwendungsprogramm in ANSI ist, dann wird automatisch konvertiert (so ist das bei mir bei allen neueren GUI Anwendungen).
Seit ich das mache hatte ich keine Probleme mehr mit falschen Zeichen (z.b. ® <=> (c), bei CGI, PDF etc.).
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 "PRIMARY KEY"

Beitrag von AUGE_OHR »

hi,

ich werde diesen Thread auf [erledigt] setzten und einen neuen Thread mit OEM / ANSI / Sonderzeichen aufmachen.
gruss by OHR
Jimmy
Antworten