SQLite - DBGrid - PRIMARY KEY: Feld kann nicht editiert werden

Für Themen zu Datenbanken und Zugriff auf diese. Auch für Datenbankkomponenten.
Antworten
walsch.rene@web.de
Beiträge: 14
Registriert: Sa 9. Apr 2022, 09:35
OS, Lazarus, FPC: Winux (L 0.9.xy FPC 2.2.z)
CPU-Target: 64Bit
Wohnort: Köln

SQLite - DBGrid - PRIMARY KEY: Feld kann nicht editiert werden

Beitrag von walsch.rene@web.de »

Liebe Foristas,

zunächst wünsche ich ein gutes Neues Jahr! In einer SQLite-Datenbank habe ich folgende Tabelle angelegt:

CREATE TABLE STUDIESINCLUDED
(
STUDYNO INTEGER NOT NULL PRIMARY KEY,
INCLUDED VARCHAR(4) NOT NULL,
COMMENT VARCHAR(256)
);

Diese habe ich via SQLQuery (SELECT * FROM STUDIESINCLUDED ORDER BY STUDYNO;) mit einem DBGrid verknüpft und möchte in das noch leere Gitter nun Daten eingeben. Die Felder INCLUDED und COMMENT kann ich problemlos editieren, das Feld STUDYNO nicht (DBGridStudiesIncluded.Columns[0].ReadOnly:=False). Das Feld ist nicht AUTOINCREMENT, da es zwar sowohl UNIQUE als auch NOT NULL sein muss, um später zur Verknüpfung mit Fremdtabellen zu dienen, die fünfstellige STUDYNO aber individuell vergeben wird.

Die folgende Tabelle kann ich dagegen problemlos editieren (muss aber das Feld CATEGORY_ID auch nicht anfassen, im Gegensatz zur ersten Tabelle):

CREATE TABLE CATEGORIES
(
CATEGORY_ID INTEGER PRIMARY KEY AUTOINCREMENT,
CATEGORY VARCHAR(32) NOT NULL,
COMMENT VARCHAR(256)
);

Wo liegt mein Fehler?

Vielen Dank und beste Grüße,
René
Bei den meisten Computerfehlern sitzt die Fehlerquelle vor dem Rechner. Und sieht mir zum Verwechseln ähnlich.

Benutzeravatar
theo
Beiträge: 10468
Registriert: Mo 11. Sep 2006, 19:01

Re: SQLite - DBGrid - PRIMARY KEY: Feld kann nicht editiert werden

Beitrag von theo »

Ich bin wirklich kein SQL Guru, aber den Primary Key ändern zu wollen ist mMn keine gute Idee.
S. z.B. https://www.geeksforgeeks.org/differenc ... nique-key/

walsch.rene@web.de
Beiträge: 14
Registriert: Sa 9. Apr 2022, 09:35
OS, Lazarus, FPC: Winux (L 0.9.xy FPC 2.2.z)
CPU-Target: 64Bit
Wohnort: Köln

Re: SQLite - DBGrid - PRIMARY KEY: Feld kann nicht editiert werden

Beitrag von walsch.rene@web.de »

Verstanden, theo, vielen Dank! Statt PRIMARY KEY habe ich NOT NULL und UNIQUE genommen, jetzt klappt's. Offensichtlich verhindert PRIMARY KEY das Editieren.
Bei den meisten Computerfehlern sitzt die Fehlerquelle vor dem Rechner. Und sieht mir zum Verwechseln ähnlich.

Benutzeravatar
fliegermichl
Lazarusforum e. V.
Beiträge: 1432
Registriert: Do 9. Jun 2011, 09:42
OS, Lazarus, FPC: Lazarus Fixes FPC Stable
CPU-Target: 32/64Bit
Wohnort: Echzell

Re: SQLite - DBGrid - PRIMARY KEY: Feld kann nicht editiert werden

Beitrag von fliegermichl »

walsch.rene@web.de hat geschrieben:
Mo 2. Jan 2023, 14:12
Verstanden, theo, vielen Dank! Statt PRIMARY KEY habe ich NOT NULL und UNIQUE genommen, jetzt klappt's. Offensichtlich verhindert PRIMARY KEY das Editieren.
Wenn man darüber nachdenkt, dann macht das ja auch Sinn. Wenn Querverweise auf den Datensatz plötzlich nicht mehr funktionieren weil ein Anwender den Primary Key geändert hat.

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6200
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: SQLite - DBGrid - PRIMARY KEY: Feld kann nicht editiert werden

Beitrag von af0815 »

ein PK muss unique sein und not null. Das er normalerweise nicht geändert wird ist sinnvoll aber nicht unmöglich. Es wird normalerweise verunmöglicht, weil ja auch alle Abhängigkeiten mit geändert werden müssen. Und das ist meistens zu vermeiden. Aber ohne PK definition hast du keinen mehr, an was soll jetzt das DB-System die Änderungen machen :-) Daher wenn du den PK ändern musst, dann ist es kein richtiger PK und du solltest dir einen richtigen PK anlegen.

Spaltennamen die Keywörter entsprechen könnten, sind generell zu vermeiden, "INCLUDED", "COMMENT" sind nicht unbedingt zu bevorzugen, sie können zu leicht in einem SQL Dialekt schon verwendet werden. Bei manchen SQL-Systemen kann man sich das mit "[INCLUDED]" behelfen, wenn es unbedingt notwendig ist.

Generell sollte man den PK niemals dem Benutzer zum Editieren freigeben. Das sollte immer gezielt gemacht werden, vor allen wird der ja nur beim ersten Insert erstellt und später nicht mehr angegriffen. Auch ein "Select * from" ist für mich ein NoGo, dazu findet aber die Forumssuche mehr.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

charlytango
Beiträge: 843
Registriert: Sa 12. Sep 2015, 12:10
OS, Lazarus, FPC: Laz stable (2.2.6, 3.x)
CPU-Target: Win 32/64, Linux64
Wohnort: Wien

Re: SQLite - DBGrid - PRIMARY KEY: Feld kann nicht editiert werden

Beitrag von charlytango »

walsch.rene@web.de hat geschrieben:
Mo 2. Jan 2023, 12:44
die fünfstellige STUDYNO aber individuell vergeben wird.

Wo liegt mein Fehler?
Zuerst solltest du verstehen dass Datenbanken nicht nur Tabellen verwalten sondern viel mehr an Funktionen bieten. Und die sollte man ihnen auch nicht wieder abtrainieren. Einen Sportwagen fährt man ja auch nicht mit angezogener Handbremse im ersten Gang.

Ein System von Primary Keys um das sich ausschließlich die Datenbank kümmert macht in den allermeisten Fällen mehr Sinn als selbst daran rumzubasteln.

Jede meiner Tabellen hat einen von der DB vergebenen PK. Und der Name des PK ist DB-weit eindeutig und wird in seiner Bedeutung eben nur als PK in der Tabelle und als Foreign key in ggfs verbundenen Tabellen verwendet. Das erleichtert schonmal das Verstehen einer DB und ggfs auch reverse engineering durch irgendwelche Programme etwa um die DB zu dokumentieren.

Wenn du tatsächlich in die Verlegenheit kommst dass der Benutzer eine externe ID (also deine 5stellige STUDYNO eintragen soll würde ich auch in diesem Fall so vorgehen:

Code: Alles auswählen

CREATE TABLE "studiosincluded" (
	"studioid" INTEGER NOT NULL AUTO_INCREMENT,
	"studyno" INTEGER NOT NULL DEFAULT '0',
	PRIMARY KEY ("studioid")
)
;
Auf studyno noch einen unique index setzen und die Sache sollte klappen.
Intern würde ich immer mit den PKs arbeiten und damit nichts dem Zufall überlassen.
Der Benutzer kann also irgendeine Nummer als studyno eingeben ohne dir die Datenbankstruktur zu zerschießen. Deren Uniqueness ist mit dem Index ausreichend abgesichert.


Die Vergabe der PKs ist bei den Datenbanken über Sessions gesichert und auch bei realtiver Gleichzeitigkeit korrekt. (was bei SQLite ohnehin keine Rolle spielt)
Solltest du den von der DB erstellten PK für andere Tabellen als FK benötigen kannst du dazu unmittelbar nach dem INSERT die DB befragen

Code: Alles auswählen

SELECT last_insert_rowid()
ermittelt dir den letzten benutzen neuen PK.
Mit so einem System kommen auch die DataControls und SQLdb gut zurecht

walsch.rene@web.de
Beiträge: 14
Registriert: Sa 9. Apr 2022, 09:35
OS, Lazarus, FPC: Winux (L 0.9.xy FPC 2.2.z)
CPU-Target: 64Bit
Wohnort: Köln

[Gelöst] Re: SQLite - DBGrid - PRIMARY KEY: Feld kann nicht editiert werden

Beitrag von walsch.rene@web.de »

1) Die Nähe von INCLUDED und COMMENT zu in SQLITE und/oder FPC reservierten Wörtern ist zufällig, und Lazarus hat nicht geschimpft :wink: . Ich habe das dennoch geändert (INVOLVED, REMARKS). Vielen Dank für die Warnung.
2) Die Funktion und Bedeutung des PRIMARY KEY sind mir bekannt. In meinem forschenden Unternehmen erhält jede neue Studie eine Studiennummer (sechstellige Zahl), die eineindeutig (UNIQUE) ist. Sämtliche im Unternehmen kursierenden Informationen zu diesen Studien sind zwingend (NOT NULL) mit dieser Nummer verbunden, sie ist de facto also ein Primary Key. Daher habe ich mich verleiten lassen, sie auch in meiner DB als solchen zu benutzen. Ich habe es jetzt so gemacht wie von Euch vorgeschlagen. Auch dafür vielen Dank.
Bei den meisten Computerfehlern sitzt die Fehlerquelle vor dem Rechner. Und sieht mir zum Verwechseln ähnlich.

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6200
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: [Gelöst] Re: SQLite - DBGrid - PRIMARY KEY: Feld kann nicht editiert werden

Beitrag von af0815 »

walsch.rene@web.de hat geschrieben:
Di 3. Jan 2023, 11:04
Sämtliche im Unternehmen kursierenden Informationen zu diesen Studien sind zwingend (NOT NULL) mit dieser Nummer verbunden, sie ist de facto also ein Primary Key. Daher habe ich mich verleiten lassen, sie auch in meiner DB als solchen zu benutzen.
Ich habe in einem großen internationalen Konzern gearbeitet, beim DB Design für ein größere Applikation wurde mir definitiv gesagt, alle Personalnummern weltweit sind 10 stellig und absolut eindeutig. Nachdem das so von der Zentrale bestätigt wurde, habe ich mich dazu entschlossen, das Feld zu einen varchar(255) zu machen. ... Es kam, wie es kommt, unser Bereich wurde verkauft und plötzlich mussten die Personalnummern auch länger sein und Buchstaben/Zeichen beinhalten, weil asiatische Fabriken dazugekommen waren. Mir war es egal, den Frontend umstricken und in der DB war es sowieso kein Problem. Wehe ich hätte da ein anderes Design gewählt. Nein, man sollte sich bei so Sachen die Arbeit machen und das Design etwas defensiver anlegen, besonders wenn man den Job einige Jahre in derselben Firma machen will. Ansonsten ist es ja egal :-)
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

Antworten