Hallo zusammen,
ich habe ein kleines Problem.
Ich habe eine Datenbank in Access gebaut und möchte wenn ich auf denn Button Speichern drücke das er
1 . schaut ob alle Felder gefüllt sind und
2. ob es denn Eintrag schon in der Datenbank gibt.

wer kann mir dabei Helfen ich bin für jede Tip und Hilfe Dankebar.

Hi,

da kommen nun einige Sachen zusammen, die Probleme bereiten könnten. Access : kein Kommentar. Delphi DB-Controls : dto. Lasse besser die Finger von solchem Kram.

@hansa: Na? Pawlovreflexartiger MS-Hasser? Wie undifferenziert. Na egal. Access ist schon ok, sofern man das Teil wörtlich nimmt: Desktop-DB. Also nicht im Netz und nicht mit mehreren Nutern gleichzeitig arbeiten. Dann kann ich es empfehlen. Und Millionen anderer User auch. Aber, wie gesagt, *nie* als Mehrbenutzersystem konzipieren.

Zurück zum Thema:
Ich würde in dem OnBeforePost-Event des TDataset die Vollständigkeit und Korrektheit der eingegebenen Werte prüfen. Um sicherzustellen, das ein Datensatz nur einmal in der Tabelle vorkommt, musst Du dir erstmal im Klaren sein, was das heisst (z.B. Name eindeutig, Kundennummer, etc. etc.). Dann kannst Du Access das Problem lösen lassen, indem Du einen eindeutigen Index auf den Schlüsselfeldern (s.o., also Name, KundenNr.. etc) erstellst. Wenn Du dann einen Datensatz doppelt eintragen willst, meckert Access (oder jede andere DB).
Wenn Dir das zu hoch ist, dann schau halt selbst in der DB nach: Öffne eine zweite Tabelle und such per Locate, ob der neue Datensatz schon vorhanden ist.

Nicht noch ein Soziologe. Access ist mir ziemlich egal. Problematisch ist hauptsächlich, daß ich immer daran denken muß, es nicht zu installieren. Worauf ich hinweisen wollte sind auch eher die DB-Komponenten und daß es besser ist die normalen zu verwenden. Zumindest auf längere Sicht.

hansa hat folgendes geschrieben:

Access ist mir ziemlich egal.

Nach deiner ersten Aussage legst du aber genauso viel Gewicht drauf, wie auf die DB-Komponenten.

hansa hat folgendes geschrieben:

Worauf ich hinweisen wollte sind auch eher die DB-Komponenten und daß es besser ist die normalen zu verwenden. Zumindest auf längere Sicht.

Ebenso undifferenziert. Es ist eine Frage des Einsatzgebietes. Bei einer Single-User-Anwendung ist das überhaupt kein Problem. Und es gibt durchaus Bereiche in Multi-User-Anwendungen, wo der Einsatz sinnvoll ist. Also stelle doch bitte nicht solche Pauschal-Behauptungen auf, die du mit nichts begründest. Außerdem kennst du den Einsatzzweck nicht und kannst das nicht beurteilen.

@NTM:
Der Einsatz von DB-Komponenten ist durchaus in Ordnung. Es gibt aber auch Problemstellungen, bei denen man mit Einsatz der anderen Komponenten besser an sein Ziel kommt. Bei deinem aktuellen Problem solltest du tatsächlich keine DB-Komponenten verwenden.

Wir haben hier gerade ein (hallo hansa, Soziologie ) Projekt am laufen, bei dem wir mal auf TDBEdits verzichtet haben. Mag ja toll sein und flott, aber man bricht sich echt einen ab. Fazit:

Wir haben ein Formular (Auftragsannahme für ein Callcenter), bei dem sehr viele Geschichten in Abhängigkeit vom Inhalt eines Edit-Controls geschehen. Es darf keinerlei Verzögerungen geben. Da werden Gruppen angezeigt / versteckt, andere optionale Edits eingeblendet, Datengitter verwurschtelt etc. DAS ist die einzige Ausnahme von der Doktrin:"Projekt hat TDataset -> Benutze TDBEdits".

Ich persönlich würde prinzipiell mit TDBEdits arbeiten und dann, im schlimmsten Fall, mal ein Formular ohne TDBEdits abbilden.

@hansa: Ich muss doch Access nicht auf dem Zielrechner installieren. Die Jet-Engine ist doch bei Windows sowieso immer dabei, oder hab ich mal wieder einen meiner Senilitätsaussetzer?

@jasocul: Warum, meinst Du, sollte hier auf TDBEdits verzichtet werden? Interessiert mich wirklich.

Allgemein zu Access: Aus gutunterrichteten Kreisen wurde mir die Zahl "5" als "Maximale Anzahl von Benutzern, bei denen Access nicht stündlich Probleme bereitet" zuegspielt. Ich kann das m.E. bestätigen. Ein Callcenter mit 30 Arbeitsplätzen darf täglich ihre Access-DB reparieren, indizieren oder den Backup von gestern hervorkramen. Sixt-Berlin arbeitet mit 4 PC, wobei eigentlich nie 2 gleichzeitig auf die DB zugreifen und kennen Probleme dieser Art *überhaupt* nicht. Ich habe mit Access auch weniger Probleme (Stromausfall oder PC einfach ausschalten) als mit Paradox. Bei einer Anwendung mit Paradox-Tabellen musste ich beim Programmstart die obligatorische Reparatur der TUTIL32.DLL einbauen, damit die Anwendung überhaupt einsatzfähig war. Aber das ist Thema eines anderen Threads.

Es geht auch mit DBEdit.
Aber!:
Du willst in einer Tabelle prüfen, ob deine Eingaben schon vorhanden sind. Du erfasst aber gerade in dieser Tabelle. Wenn du ein AutoPost hast, würden die Daten sofort gespeichert werden (weil du den Datensatzzeiger veränderst). Es kann auch passieren, dass du die Daten verlierst (Cancel on Exit). Das hängt alles von deinen Einstellungen und der DB ab, die du einsetzt.
Wenn du so arbeiten willst, musst du ein weiteres DataSet (TQuery/TTable) für die Suche verwenden. Und ab da wird es philosophisch. Die Einen meinen, dass das i.O. ist, die Anderen meinen, dass man dann doch besser keine DBEdit verwenden sollte. Spart einen Cursor auf der Datenbank.
Es gibt noch weitere Probleme:
Durch deine Art, wird ein Cursor auf der DB offen gehalten (mit Locks,etc.). Im anderen Fall ist der Cursor nur kurz für die Prüfung und Erfassung offen. Im Multi-User-Betrieb sind das wichtige Gesichtspunkte (Performanz, Ressourcen,...).

Ich verwende ADO, und dafür gibt es die "Clone" Methode des Recordsets.
Cursoren (äh, Cursors?) sollten eigentlich *nie* serverseitig eingesetzt werden, weil dann die Mehrbenutzer-DB ad absurdum geführt wird. ADO unterstüzt die clientseitigen Cursors. Desweiteren würde man in einer Multiuser-DB die Suche in die DB per Stored Procedure verlagern.

Wobei hier die 'SP_CheckData' eine Stored Procedure ist, die auf dem Server prüft, ob die beiden Werte 'Foo' und 'Bar' korrekt sind und im Parameter @ResultCode das Überprüfungsergebnis zurückliefert.

Aber, wie jasocul schon sagte: Alle Wege führen nach Rom.

Hallo alzaimar,
Danke es Funktioniert.