Not null violation: 7 FEHLER: NULL-Wert in Spalte »LoginID« verletzt Not-Null-Constra

Hallo
ich habe mit dem EnterpriseDB Migration Wizard meine MySQL DB konvertiert.
Die allerersten Hürden sind genommen :slight_smile:
Jetzt habe ich aber einen Fehler bei einem Insert:
Not null violation: 7 FEHLER: NULL-Wert in Spalte »LoginID« verletzt Not-Null-Constraint’
Bei MySQL war die Spalte LoginID ein “auto_increment”.
Ich habe mal ein wenig gegoogelt. Könnte es sein das beim migrieren etwas falsch gelaufen ist. Im PGAdmin ist diese Spalte ein “integer” und NOT NULL Bei Sequenze steht auch LoginID drin.
Was könnte die Ursache sein?
viele Grüße
Tom

Du kennst die Ursache: fängt mit My an und endet mit SQL. Dazwischen ist das Hirn von MySQL. Also nix.

Andreas

Zeig uns die komplette Definition der Tabelle (als CREATE TABLE) und das komplette INSERT Statement welches Du ausführst.

IIRC erlaubt MySQL bei solchen Spalten NULL.

Andreas

Hallo,
Danke für die Hilfe.
Hier die Definition

CREATE TABLE mydb.ir_login
(
“LoginID” integer NOT NULL,
“UserID” integer NOT NULL,
“UserLoginName” character varying(200) NOT NULL,
uin character varying(32) NOT NULL,
expire integer NOT NULL DEFAULT 0,
ip character varying(15),
browser character varying(50),
pcname character varying(100),
CONSTRAINT is_login_pkey PRIMARY KEY (“LoginID”),
CONSTRAINT uin UNIQUE (uin)
)

und hier der Insert. Sieht in meinem PHP Code etwas anders aus da ich mit PreparedStatements arbeite.

INSERT INTO mydb.ir_login (UserLoginName,uin,expire,ip,browser,pcname,UserID) VALUES (‘Testname’,‘123456’,‘123’,‘127.0.0.1’,‘www’,‘Test’,2)

So wie ich das als Anfänger sehe, wurde vom MIgration Wizard keine Sequenz angelegt.

Hi Andreas,

<<Du kennst die Ursache: fängt mit My an und endet mit SQL. Dazwischen ist das Hirn von MySQL. Also nix.

Was soll ich jetzt mit dieser Aussage anfangen?

Zumindest ist keine in Deiner Tabelle zu sehen. Ausserdem ist den Spalten kein DEFAULT Wert zugewiesen (eine Sequence alleine reicht nicht). Am einfachsten ist es, wenn Du die Spalten als serial definierst.

Ausserdem solltest Du diesem “Wizard” irgendwie mitteilen nicht alles mit Quotes anzulegen, sonst musst Du die dämlichen Quotes überall verwenden. So wie Du das INSERT gepostet hast, wird es nicht mal einen NOT NULL Fehler werfen, weil die Spaltennamen falsch geschrieben sind.

Vielleicht solltest Du Dir überlegen, das SQL des “Wizards” einfach als Grundlage für eine eigene Überarbeitung zu verwenden und das Script so anzupassen, dass es die Tabellen sauber anlegt.

Eine voll-automatische Konvertierung von DBMS eins zu DBMS zwei klappt einfach nie.

Ach, schon gut. MySQL hat eine Reihe von Macken. Ich hatte gestern z.B. den Fall, daß ein Dump beim Einspielen einen doppelten Wert im PK meldete. Den Dump gegreppt war da aber gar nix. Sehr komisch.
Jedenfalls glaube ich mich erinnern zu können, daß MySQL in einer PK-Spalte auch NULL akzeptiert oder aber, wenn man einen PK nachträglich anlegt, vorhandene NULL-Werte akzeptiert. Und ich hatte vermutet, daß Du in diese Falle gelaufen bist.

Andreas

Hallo ihr Experten,
vielen Dank für eure Hilfe.

<<Zumindest ist keine in Deiner Tabelle zu sehen. Ausserdem ist den Spalten kein DEFAULT Wert zugewiesen (eine Sequence alleine reicht nicht). Am einfachsten ist es, wenn Du die Spalten als serial definierst.

Ok, wenn ich mit pgAdmin eine neue Spalte von Hand anlege ist dies kein Problem. Hier gibt es als Auswahl den Typ Serial. Es wird automatisch eine Sequence und ein Default Wert angelegt.
Nachträglich aber eine Spalte von Integer in Serial zu wandeln geht so nicht. Hier gibt es keine Auswahl Serial.
Ich habe es jetzt hinbekommen indem ich manuell zuerst eine Sequence anlege und danach einen Default Wert angebe.

<<Ausserdem solltest Du diesem “Wizard” irgendwie mitteilen nicht alles mit Quotes anzulegen, sonst musst Du die dämlichen Quotes überall verwenden. So wie Du das INSERT gepostet hast, wird es nicht mal einen <<NOT NULL Fehler werfen, weil die Spaltennamen falsch geschrieben sind.

Hier sprichst du etwas an das mich schon tagelang beschäftigt und wo ich einfach nicht recht weiter komme.
Ich kann einfach keine Spalten in der Groß/Klein Schreibweise anlegen und auf Quotes verzichten.
Selbst wenn ich im pgAdmin eine Tabelle als Test anlege und eine Spalte wie
MySuperID
Dann kommt bei einem Select MySuperID from test
eine Fehlermeldung das er die Spalte mysuperid nicht kennt.
Ich muss also in meinem Select die Spalte mit “” quoten weil PG automatisch aus MySuperID => “MySuperID” gemacht hat. Zumindest sehe ich dies so im pgAdmin.

Die andere Möglichkeit wäre das ich alle Spaltennamen in Kleinbuchstaben migriere. Das habe ich auch schon versucht.
Hier kann ich dann meinen bisherigen PHP SQL Code nahezu unverändert lassen.
Aber auch hier habe ich dann Probleme.

ich kann dann zwar im Select die Spalten ohne Quotes lassen.

$dbSelect = $DBO->prepare("SELECT MySuperID FROM test WHERE KeyName = ‘Test’ ");
$found = $dbSelect->fetch(PDO::FETCH_ASSOC);
return $found[‘MySuperID’];

und hier habe ich dann einen leeren Return Wert da PG die Spalte MySuperID nicht kennt. Ich müsste als ändern in;
return $found[‘mysuperid’];

und dies müsste ich dann für alle Spaltennamen im gesamten PHP Code machen.

Gruss
hawk

(Könntest Du bitte das Forum feature für’s Quoting verwenden und nicht diese komischen << Zeichen? Wenn Du statt auf Antworten auf “Zitieren” klickst siehst Du auch wie das gemacht wird)

Wie gesagt: Nimm das SQL Script welches der “Wizard” erzeugt hat und ändere das so ab, das etwas rauskommt, dass passt. Produktiv-Datenbanken sollten grundsätzlich nicht über pgAdmin (ad-hoc) angelegt werden sondern über ein Script.


Ich kann einfach keine Spalten in der Groß/Klein Schreibweise anlegen und auf Quotes verzichten.
Selbst wenn ich im pgAdmin eine Tabelle als Test anlege und eine Spalte wie MySuperID. Dann kommt bei einem Select MySuperID from test
eine Fehlermeldung das er die Spalte mysuperid nicht kennt.

SQL ist grundsätzlich nicht case-sensitiv.
Der SQL Standard schreibt vor, dass die Namen von Tabellen (und Spalten) die nicht gequotet werden in Großbuchstaben umgewandelt werden (PG macht zwar Kleinbuchstaben daraus, das ändert aber am Verhalten nichts). Wenn Du also darauf bestehst, dass die Spalte MySuperID auch genauso in der Datenbank angelegt werden soll, dann musst Du unbedingt Quotes verwenden. Aber dann musst Du das immer (Meine Erfahrung ist aber, dass das im Regelfall eine schlechte Methode ist).

Das sich MySQL da anders vehält liegt einfach daran, dass MySQL sich nicht um den Standard schert. Im Übrigen es auch davon ab, ob MySQL auf Windows oder Linux läuft und wie bestimmte Konfigurationsparameter gesetzt wurden (PostgreSQL entspricht im wesentlichen der Einstellung lower_case_table_names = 1)


und dies müsste ich dann für alle Spaltennamen im gesamten PHP Code machen.

In einen sauren Apfel wirst Du beissen müssen (entweder immer Quotes, oder PHP code ändern).
Wobei ich eher den PHP Code ändern würde.
Der hätte nämlich mit einer MySQL Installation bei der lower_case_table_names z.B. auf 0 oder 2 steht auch nicht mehr funktioniert.