Primary key nicht vorhanden

[TurboMagic]

Zitat von Jasocul:

Zitat von haentschman:

Zitat:

Für Multi-User und/oder parallelen Zugriff ist ein PK für eine Tabelle nicht erforderlich.

...aber JEDE Tabelle muß grundsätzlich einen haben. Wenn nicht, hat der Datenbankfuzzi den Beruf verfehlt...

Ich habe die Frage im Sinne des Problems beantwortet.
Und wie Himitsu bereits schrieb, ist auch bei gutem DB-Design nicht immer ein Key/Primary Key erfoderlich oder sinnvoll.

Richtig, da gebe ich euch recht. Gerade für Fälle wo jemand nur die zuletzt eingegebenen Ortsnamen oder so
in der DB speichern will um beim nächsten Aufruf des DIalogs gleich Vorschlagswerte für den Ort anzubieten
muss man keinen PK haben.

Aber meiner Meinung nach betrifft das so ca. <= 1% der Anwendungsfälle von Tabellen.

[joachimd]

Zitat von TurboMagic:

Richtig, da gebe ich euch recht. Gerade für Fälle wo jemand nur die zuletzt eingegebenen Ortsnamen oder so
in der DB speichern will um beim nächsten Aufruf des DIalogs gleich Vorschlagswerte für den Ort anzubieten
muss man keinen PK haben.

...und spätestens bei der Löschung von Dubletten hast du wieder ein Problem...

[TurboMagic]

Zitat von joachimd:

Zitat von TurboMagic:

Richtig, da gebe ich euch recht. Gerade für Fälle wo jemand nur die zuletzt eingegebenen Ortsnamen oder so
in der DB speichern will um beim nächsten Aufruf des DIalogs gleich Vorschlagswerte für den Ort anzubieten
muss man keinen PK haben.

...und spätestens bei der Löschung von Dubletten hast du wieder ein Problem...

Ja, aber: man baut so eine Lookup Liste ja auch so auf, dass es nicht zu Doubletten kommt
Vorher prüfen, ob der Vorschlagswert schon vorhanden ist und nur wenn nicht dann speichern

Wie gesagt: in > 99,5% der Fälle sollte man einen key haben.

[Uwe Raabe]

Zitat von TurboMagic:

Ja, aber: man baut so eine Lookup Liste ja auch so auf, dass es nicht zu Doubletten kommt
Vorher prüfen, ob der Vorschlagswert schon vorhanden ist und nur wenn nicht dann speichern

Na ja, das kann bei Multi-User-Zugriff schon mal daneben gehen - es sei denn man legt einen Unique Key auf das entsprechende Feld.

[Frickler]

Zitat von Uwe Raabe:

Zitat von TurboMagic:

Ja, aber: man baut so eine Lookup Liste ja auch so auf, dass es nicht zu Doubletten kommt
Vorher prüfen, ob der Vorschlagswert schon vorhanden ist und nur wenn nicht dann speichern

Na ja, das kann bei Multi-User-Zugriff schon mal daneben gehen - es sei denn man legt einen Unique Key auf das entsprechende Feld.

Für den Multi User Zugriff gibt es eine Spalte mit dem Usernamen - jeder User sieht nur "seine" Eingaben. Angenommen, der eine gibt Ortsnamen in Norddeutschland ein und der andere in Süddeutschland, dann sind bei einem gemeinsamen Pool die zuletzt eingegebenen nicht zwingend die, die man haben wollte.

[bernhard_LA]

anbei die Fehlermeldung welche 2 User auf meiner DB nicht zulässt

( noch die alten SQL scripte , keine PK vorhanden )

[bernhard_LA]

Ich kann in meinem Code FireDAC und ADO Datenbank-Komponenten über eine Compiler Einstellung tauschen (Factory Pattern),
wird TADOQuery im Code eingebaut läuft alles prima, bei FireDAC bekomme ich obige Fehlermeldung.

Bin weiterhin für Inputs dankbar, will mir gerne die Option für bei DB Komponenten offenhalten, weil wenn's von WINx64 auf UNIX geht brauche ich ja FireDAC.

[Blup]

Wenn die Komponenten unbedingt einen Primärkey erfordern, warum nicht einfach einen PK für die betreffende Tabelle anlegen? Wenn sich kein eindeutiger natürlicher Schlüssel anbietet, einfach ein ID-Feld erzeugen.