Primärschlüsselfehler bei insert Statement

Hi liebe Leute,

info: habe bei einer DB per select die gewünschten Daten abgefragt und in eine csv gesichert.
Habe zur Probe eine Zeile zurück schreiben wollen, dann kam das Problem mit dem Primärschlüssel

Ich muss wahrscheinlich etwas ändern damit es geht aber was???

INSERT INTO "WORK" ("UID", ...) VALUES ('C776CCAB70188444805687530AA209DB', ...);  

bei Metadata hab ich das gefunden

CONSTRAINT "PK_WORK" PRIMARY KEY ("UID")  
;

Interbase 6.0
mfG

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 264657

Url: https://administrator.de/contentid/264657

Ausgedruckt am: 18.11.2024 um 07:11 Uhr

6 Kommentare

Neuester Kommentar

UID sollte eindeutig sein.
Erneut dieselbe UID reinschreiben ist nicht zulässig.

hi @AndreasHoster

Ist mir Klar, aber wie kann ich einen neuen PS generieren ?? gibts da einen sql befehl der einen neuen PS generiert weil die DB ist Leer wo ich die Daten versuche zu kopieren (Struktur ist vorhanden).

hmm

Hallo,

in der Regel wird der Primary Key per "Autoincrement"-Generator angelegt. D.h., die Datenbank vergibt den Wert selbst beim Einfügen eines Datensatzes (s.a. hier und hier).
Versuch doch mal Deinen INSERT-Befehl ohne das Feld "UID" und den Wert (alternativ: mit Feld "UID" und Wert 0).

Gruß,
Gersen

Hi Gersten,
Hab ich Versucht ohne UID und ohne Wert -> error (noch nicht probiert UID mit wert 0 wird das funktionieren wenn Feld NOT NULL ist ) werd ich noch versuchen...

Ich hab ein wenig rekursiv gedacht und eine andere Lösung gefunden brauche aber eine Bestätigung ob es ok ist :

Idee 1 wO. : DB voll -> gebrauchte Daten speichern -> neue DB ----> Daten zurück

Idee 2 : DB voll -> nicht gebrauchte Daten löschen -> Backup -> Restore

Ist Idee 2 genau so wie eine Neue DB, da alle Daten die älter als 7 Tage gelöscht werden und durch Restore die DB optimiert wird ????

Mit freundlichen Grüßen
dax

Hallo,

Idee 1 ist n.m.M. keine Lösung, da eine DB erzeugt wird, die ebenso voll ist, oder?
Idee 2 ist für wichtige Produktiv-Daten gefährlich - geht beim Löschen etwas schief, ist Feierabend. Sicherer wäre:

DB --> Backup1 --> nicht gebrauchte Daten löschen --> Backup2 --> Restore aus Backup2. Bei Fehlern kann man immer noch Backup1 "restorieren".

Gruß,
Gersen

Hallo Gersen,

Stimmt, Idee 2 ist ein wenig gefährlich aber ich mach ja sowieso ein Backup auf Dateiebene, ohne das etwas geändert wird somit hab ich alle Daten. Bei der Weiterverarbeitung geschiet alles auf der tempDB.

Und ich bin ja auch noch da