Kein Bearbeiten-Button

Alle Fragen, Probleme, ... zu phpPGAdmin gehören hier rein.
Antworten
jth
Neuer Benutzer
Beiträge: 23
Registriert: Mo 10. Jan 2011, 10:25
Wohnort: Freiberg/Sachsen
Kontaktdaten:

Kein Bearbeiten-Button

Beitrag von jth » Do 20. Jan 2011, 08:12

Hi,

ich habe mir gestern eine Tabelle in phpPgAdmin angelegt:


CREATE TABLE blog (
title character varying(100) NOT NULL,
content character varying(5000) NOT NULL,
wdate date NOT NULL
);

und gleich 2 Datensätze damit eingefügt. Interessanterweise kriege ich für diese Tabelle keine "Bearbeiten"-Buttons angezeigt. Die Datensatzzahl wird auch mit "0" angezeigt, aber das habe ich bei einer anderen, mit phpPgAdmin angelegten Tabelle mit 2 Datensätzen auch. Da gibt es aber "Bearbeiten"-Buttons.
Komischerweise haben Tabellen, die ich mit sql-Befehlen angelegt und gefüllt habe, auch bei wenigen Datensätzen eine korrekte Satzanzahl und immer "Bearbeiten"-Buttons.

Kennt jemand das, ist es ein Bug...

Ach ja - hier läuft psql 8.3 auf Opensuse 11.1, phpPgAdmin ist Version 4.2

Thx für jeden Tipp
--
Jörg Thümmler
- unsere Wälder schützen -
http://www.teddylinx.de/prowald

akretschmer
Erfahrener Benutzer
Beiträge: 7480
Registriert: So 29. Okt 2006, 13:35
Wohnort: Kaufbach, Sachsen, Germany, Germany
Kontaktdaten:

Beitrag von akretschmer » Do 20. Jan 2011, 08:18

jth hat geschrieben:Hi,

ich habe mir gestern eine Tabelle in phpPgAdmin angelegt:


CREATE TABLE blog (
title character varying(100) NOT NULL,
content character varying(5000) NOT NULL,
wdate date NOT NULL
);

und gleich 2 Datensätze damit eingefügt. Interessanterweise kriege ich für diese Tabelle keine "Bearbeiten"-Buttons angezeigt. Die Datensatzzahl wird auch mit "0" angezeigt, aber das habe ich bei einer anderen, mit phpPgAdmin angelegten Tabelle mit 2 Datensätzen auch. Da gibt es aber "Bearbeiten"-Buttons.
Komischerweise haben Tabellen, die ich mit sql-Befehlen angelegt und gefüllt habe, auch bei wenigen Datensätzen eine korrekte Satzanzahl und immer "Bearbeiten"-Buttons.

Kennt jemand das, ist es ein Bug...

Ach ja - hier läuft psql 8.3 auf Opensuse 11.1, phpPgAdmin ist Version 4.2

Thx für jeden Tipp


1. ist PhpPgAdmin Müll
2. die Tabelle hat keinen Primary Key, daher kein Bearbeiten ;-)


Andreas
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

jth
Neuer Benutzer
Beiträge: 23
Registriert: Mo 10. Jan 2011, 10:25
Wohnort: Freiberg/Sachsen
Kontaktdaten:

Beitrag von jth » Do 20. Jan 2011, 08:45

Hi,

1. kann ich in keiner Weise bestätigen. Es mag seine Grenzen haben, aber gerade in Testphasen ist es ein gutes Werkzeug, das Überblick verschafft.

2. ja, phpPgAdmin scheint genau daran zu scheitern, denn nun stimmt auch die Datensatzzahl. Bei den aus einer anderen Datenbank generierten SQL-Dateien hatte ich den Primärindex automatisch mit erstellen lassen, wenn es dort einen eindeutigen Schlüssel gab. Auf meine Testdateien traf das alle zu. Ist ein Primärindex eigentlich zwingend nötig? Ich meine, sinnvoll sind Indices ja eh, aber ist es ein "Muss", dessen Fehlen Quelle von Inkonsistenzen o.ä. sein kann?

Thx & cu
--
Jörg Thümmler
- unsere Wälder schützen -
http://www.teddylinx.de/prowald

akretschmer
Erfahrener Benutzer
Beiträge: 7480
Registriert: So 29. Okt 2006, 13:35
Wohnort: Kaufbach, Sachsen, Germany, Germany
Kontaktdaten:

Beitrag von akretschmer » Do 20. Jan 2011, 08:52

jth hat geschrieben:Hi,

1. kann ich in keiner Weise bestätigen. Es mag seine Grenzen haben, aber gerade in Testphasen ist es ein gutes Werkzeug, das Überblick verschafft.



Nun ja. Für unsere Kunden im Shared-Hosting-Bereich ist es mehr oder weniger der einzigste Weg, mit ihrer DB zu reden. Ich selber meide es und bevorzuge psql.

2. ja, phpPgAdmin scheint genau daran zu scheitern, denn nun stimmt auch die Datensatzzahl. Bei den aus einer anderen Datenbank generierten SQL-Dateien hatte ich den Primärindex automatisch mit erstellen lassen, wenn es dort einen eindeutigen Schlüssel gab. Auf meine Testdateien traf das alle zu. Ist ein Primärindex eigentlich zwingend nötig? Ich meine, sinnvoll sind Indices ja eh, aber ist es ein "Muss", dessen Fehlen Quelle von Inkonsistenzen o.ä. sein kann?

Thx & cu


Man sollte eigentlich immer einen PK haben, das macht z.B. das Editieren einzelner Datensätze einfacher (select for update), ein "Muss" ist es aber nicht und ein fehlender PK führt nicht zu Problemen wie z.B. Inkonsistenzen.

Andreas
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

jth
Neuer Benutzer
Beiträge: 23
Registriert: Mo 10. Jan 2011, 10:25
Wohnort: Freiberg/Sachsen
Kontaktdaten:

Beitrag von jth » Do 20. Jan 2011, 09:02

Hi,

Danke, wieder was gelernt...

cu jth
--
Jörg Thümmler
- unsere Wälder schützen -
http://www.teddylinx.de/prowald

Antworten