doppelter eintrag in db vergleichen

[missi]

Zitat:

Zitat von Luckie

Dann übernimmt der Datenbanktreiber, die Prüfung, ob der Wert schon mal in der Spalte existiert oder nicht.

crashed es dann nicht wenn ich versuche nen doppelten eindrag dann in die db zu speichern?

:wiejetzt:

[Jelly]

Ja, es löst eine Exception aus, die du in Delphi auswerten kannst und entprechend drauf reagieren kannst.

[Treffnix]

Zitat:

Zitat von missi

Zitat:

Zitat von Luckie

Dann übernimmt der Datenbanktreiber, die Prüfung, ob der Wert schon mal in der Spalte existiert oder nicht.

crashed es dann nicht wenn ich versuche nen doppelten eindrag dann in die db zu speichern?

:wiejetzt:

Jau. Aber soweit sollte es ja im Idealfall nicht kommen. Dazu baut man dann sowas wie shmia. Aber falls das aus irgendwelchen Gründen mal schiefgeht ist zumindest Datenbankseitig 100% sichergestellt, dass es keine Doubletten gibt.

//edit
*sing* wo sind all die roten Kästchen hin?.... */sing*

[missi]

Zitat:

Zitat von Jelly

Ja, es löst eine Exception aus, die du in Delphi auswerten kannst und entprechend drauf reagieren kannst.

das tu ich ja schon mit locate bevor ich es in die db schreibe *verwirrt ist*

warum sollte es besser sein erst in die db zu schreiben auf ne exception zu warten und dann sagen das sie bereits vorhanden ist?

ausserdem lesne wir ja den chip aus und wenn er in der db vorhanden ist springt er gleich zu diesem datensatz. also ist es unmöglich den chip zweimal darein zu schreiben. und ein chip hat eine eindeutige id.

[shmia]

Zitat:

Zitat von Jelly

Zitat:

Zitat von shmia

Diese Vorgehensweise hat mehrere Vorteile:
* man braucht nicht mit INSERT und UPDATE Anweisungen zuschreiben, die manchmal 50 Parameter benötigen

Wenn du 50 Felder hast, musst du auch so über deine Methode die einzelnen Felder füllen. Kürzer wird das nicht

Man braucht aber keine 50 Parameter hinschreiben, sondern kann bequem über die "Collection" TFields arbeiten.
Also kann man auch eine Schleife von 0 bis Fields.Count-1 durchlaufen, um die Felder zu füllen.
Da man die Daten über TField schreibt, kann man auch vom OnSetText profitieren.

Zitat:

Zitat von Jelly

Zitat:

Zitat von shmia

kleiner Nachteil:
* es werden Daten abgefragt, die meistens gar nicht benötigt werden (aber nur ein Datensatz, macht ja nix)

Das gilt aber nur bei einem

SQL-Code:

select * from...

Du musst doch aber nicht alle Felder einbeziehen. Statt dem * wählst du nur die du brauchst.

Es müssen alle Felder, die die Eigenschaft NOT NULL besitzen, in der Feldliste aufgeführt werden, da sonst das Einfügen nicht funktioniert. Diese Felder werden also auch dann gelesen, obwohl man diese nur zum einfügen braucht. (da würde ich mir aber nur Gedanken drum machen, wenn Tausende Datensätze eingefügt/updatet werden sollen)
Aber du hast recht, wenn es Felder gibt, die nicht befüllt werden, kann man sparen, indem man alle benötigten Felder bei SELECT auflistet.

[Sharky]

Zitat:

Zitat von missi

... das tu ich ja schon mit locate bevor ich es in die db schreibe *verwirrt ist*

Hai,

das alles entscheidende "Zauberwort" ist -> Multiuserfähigkeit.

Mit deiner Methode und auch der von shima wird nur gepüft ob es in diesem Moment noch keinen Datensatz mit der selben Seriennummer gibt. Es kann aber Clientseitig nie geprüft werden ob nicht 1 Taktzyklus nach eurer "Prüfung" von einem anderen User diese Seriennummer erfasst wurde.

Solch eine Prüfung kann nur vom DB-Server durchgeführt werden.

Darum legt man auf ein Feld deren Inhalt einmalig sein soll einen Unique Key. Wenn nun ein zweiter Datensatz mit dem selben Inhalt eingefügt werden soll wird vom DB-Server ein entsprechender Fehler erzeugt.