Entwickler-Ecke :: Thema anzeigen - DBEDit Eingabe überprüfen

alzaimar - Mo 16.05.05 20:30

@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.

jasocul - Di 17.05.05 08:26

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.

alzaimar - Di 17.05.05 12:28

Wir haben hier gerade ein (hallo hansa, Soziologie :lol:) 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:

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:

Function DatenSensitivOderNich (aProject : TDelphiProject) : TDecision;
Begin
  If NeedsADataBase (aProject) Then
    If VeryComplexInput (aProject) Then
      If ImeanVeryVeryComplexInput (aProject) Then
         Result :=  dcUseDBEditsAlmostAlways
      else
         Result = dcUseDBEdits 
    Else
      Result := dcUseDBEdits
  Else
    Result := dcStandardEdits
End;

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.

jasocul - Di 17.05.05 12:50

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,...).

alzaimar - Di 17.05.05 16:44

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.

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:

Procedure TDatamodule.OnBeforePost (Dataset : TDataset);
Begin
  With SP_CheckData, Prameters Do Begin
     ParamValues['@Foo'] := DataSet['Foo'];
     ParamValues['@Bar'] := DataSet['Bar'];
     ExecProc;
     If ParamValues['@ResultCode'] <> rcNoError Then
       Raise Exception.Create('Nee, Daten stimmen nicht');
    End;
End;

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.

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!