Ich stelle mir gerade die grundsätzliche Frage ob es sinnvoll ist mit den DBedit Feldern zu arbeiten oder ob es nicht besser ist in der Eingabemaske normale EDitfelder zu benutzen und dann über eine Datenlesen und Datenschreiben Procedure die Daten dann geprüft in die Datenbank zu schreiben, bzw. zu lesen.

Natürlich kann man auch auch in den Ereignissen der DBEditfelder eine Prüfung abwickeln, aber dann ist das dann ziemlich verteilt und für jedes Feld eine eigen Abfrageprozedure, zumindest für jede Feldart (Alpha,numeric,PLZ,Phone usw.)

Wie ist Eure Erfahrung damit, was ist am Ende besser ?

Außerdem, gibt es soetwas wie eine LabeledDBEdit-Komponente, oder eine DBDateTimePicker-Komponente ?

Ich pers. verwende im Normalfall für die Ansicht der Daten DBEdit-Felder, für die Dateneingabe jedoch normale Edit-Felder.
Insbesondere wenn die Daten am Schluss in mehreren Tabellen landen sollen, ist es m.E. so am einfachsten.

Zitat:

Außerdem, gibt es soetwas wie eine LabeledDBEdit-Komponente, oder eine DBDateTimePicker-Komponente ?

Schau Dir mal die JVCL an, dort gibt es beides.

Ind Jedi-Tools habe ich schon nachgesehen, aber nur normale Komponenten gefunden, die genau das machen was ich will, jedoch keine Komponente, die direkt auf das Datenbankfeld zugreift.

Zu meiner Frage nach DBedit oder Edit-Feld:
Bei der Eingabe der Felder arbeite ich auf jeder Seite nur mit einer Tabelle, das würde nach dem was Blawen geschrieben hat für DBEdit Felder sprechen.
Hat jemand Erfahrung damit welche Probleme später auftreten können, wenn ich DBEdit-Felder benutze ?

SmileySN hat folgendes geschrieben:

Ind Jedi-Tools habe ich schon nachgesehen, aber nur normale Komponenten gefunden, die genau das machen was ich will, jedoch keine Komponente, die direkt auf das Datenbankfeld zugreift.

Schau Dir mal die Komponenten unter JvDataControls an. Dort gibt es z.B.:

- JvDBDatePickerEdit
- JvDBDateTimePicker
- JvDBDateEdit
- JvDBStatusLabel
- JvDBHTLabel

Danke Blawen, an die DataControls hab ich gar nicht gedacht, da ich mich so auf "Edit" fixiert habe.

Die DBDate-Komponenten sind ja schon in Ordnung, jedoch auch ohne eigenes Label.
Die DBEdit-Komponenten sind auch ohne eigenes Label.
Habe ich da was übersehen oder ist dem wirklich so, dass es keine Komponenten mit einem eingebauten Label so wie es bei der LabeledEdit Komponente der Fall ist.
Es ging mir nur um eine Vereinfachung beim positionieren und verschieben von Editfeldern.

Im Prinzip ist von DB-Komponenten abzuraten. Taucht irgendeine Zusatzanforderung auf, dann ist nämlich pillo und nichts geht mehr. Bei mir gibts nur noch DBEdits und DBText. Und das nur für Stammdaten, z.B. Adresse eingeben. Da reichen die. Ansonsten IMHO kaum.

Diese Überlegung hatte ich auch angestellt, dann stellte sich mir aber die Frage, ob man Sonderfälle nicht über die Ereignisse in den DBEdit-Feldern lösen kann und ob es darum nicht sinnvoller ist mit diesen zu arbeiten.
Ich hätte gern noch ein paar mehr für und wider zu diesem Thema gehört.
Das ist doch eine Prinzipfrage, die sich jeder stellen muss, der eine Datenbankapplikation schreibt.

Ich benutze beides.
Wenn ich ein kleines überschaubares Modul mit einer Tabelle habe, dann benutze ich meistens DB-sensitive Komponenenten. Sobald ich nicht mehr sicher stellen kann, dass ich eindeutige Tabellen-Verknüfungen habe (z.B. verschiedene SQL-Abfragen mit unterschiedlichen Feld-Listen, Views, etc.), kann man das meistens vergessen. Es gibt auch Grenzfälle, die von Fall zu Fall entschieden werden müssen.
Solange es keine komplizierten Abhängigkeiten und Nebenbedingungen gibt, kann es sinnvoll sein, DB-sensitive Komponenten zu verwenden. In allen anderen Fällen sollte man sich das wirklich gut überlegen.
DBGrids sind davon aber ausgenommen. Die benutze ich eigentlich bei jeder tabellarischen Darstellung. Obwohl ich auch da schon zwei Ausnahmen hatte. In den DBGrids lasse ich aber nie Änderungsfunktionen zu.

Danke Jasocul, auf Dich kann man sich immer verlassen.
Endlich mal eine klare ausführliche Aussage mit der man was anfangen kann.

Das heißt also:
Wenn ich nur mit einer Tabelle pro Form arbeite oder vieleicht auch nur dazu eine weitere Detailtabelle anzeigen lasse, dann ist es sinnvoll DB-Komponenten zu benutzen um den Programmieraufwand zu minimieren.

Wenn ich meherer Tabellen auf einer Form anzeigen will, deren Felder auch noch unterschiedlich miteinander verknüpft sind, dann sollte ich besser mit den normalen Edit-Komponenten arbeiten.

Das halten sehr viele sehr unterschiedlich.
Hansa ist da sehr konsequent in der nicht-Benutzung von DB-Komponenten. Und er fährt nicht schlecht damit. Wenn man sich für ein Verfahren entschieden hat, hat das den Vorteil, dass man immer gleich programmiert. Der Source wird also transparenter. Er arbeitet auch sehr viel über Stored-Procedures und lässt die Daten darüber verarbeiten. Auch das hat Vorteile, sowie Nachtteile
Nur weil ich es anders mache, muss das nicht immer besser sein. Es ist oft eine Philosophie-Frage. Auch wenn mehrere im selben Source arbeiten, bietet sich eine konsequent einheitliche Programmierung an. Du solltest meine Aussage also mit Vorsicht genießen, da man vieles von der speziellen Situation abhängig machen muss.

Du willst es ausführlicher haben ? Na gut. Es fing so an : Eingabemaske für Artikel, z.B. Inventur. Habe DBGrid verwendet. Die Artikel haben allerdings aussagekräftige Bezeichnungen. Das sind momentan 3 Zeilen für Bez. Mit Standardmitteln fast unmöglich.Diese Erkenntnis hat mich 4 Wochen gkostet. Dann hat MrSpock gesagt ich solle es mit einem DBCtrlGrid mal testen. Gut. Gesagt, getan. Nach 2 Wochen die nächste Erkenntnis. Es müssen auch Bondrucker verwendet werden. D.h. die 3 Artikelzeilen sind zwar da, aber abgekürzt. Also sind es 6 DB-Felder, von denen 3 verwendet werden müssen. Sind einige leer, dann eventuell die langen Bez. abschneiden und trotzdem anzeigen / drucken. Bringe das alles mal einer einem DBGrid bei. Das DBCtrlGrid wäre in der Richtung zwar hinzubiegen, aber dadurch waren alle Vorteile davon auch schon weg. Dann hätte ich nämlich normale Labels/Edits verwenden müssen statt DBText/DBEdit. Das sah auch etwas seltsam aus alles. Dann ein echter Sonderfall und der bedeutete das Aus für DB-aware : Sonderpreise sollten gesondert gekennzeichnet werden, aber sehr klein, daß derjenige, der eventuell hinter dem der eingibt steht, es eventuell nicht sieht zumindest nicht versteht. Die Zelle mit der Artikelnr. sollte deshalb einen kleinen Punkt erhalten, sofern Sonderpreis. War mir schon klar wie das geht : mit der Eigenschaft Objects, OnDrawCell usw. Die gibts nun zwar ab TStrings, also auch für TStringgrid, aber eben nicht für DBgrid usw. weil nicht davon abgeleitet Als auch das klar war habe ich das Götz von Berlichingen-Zitat an das DBGrid geschickt.

Das Schlimme für den Fragesteller ist nun, daß sich das alles auf eine einzige Tabelle bezieht, nämlich die Artikel. Selbst da bringt DB-Zeugs keinen Vorteil. Wie wäre es mit Adressen (Stringlänge 30 x 4) mit Telefonnr., Fax, email und noch 3 Feldern ? Horizontal scrollen ohne Ende ? Im normalen Stringgrid habe ich Cells, Rows und Cols, die genau das machen, was ich will.

Ja, Fremdkomponenten gibts ja auch noch. Habe ich auch gedacht und mir einige angesehen. Die Beispielgrids sehen echt Klasse aus. Aber da gings genauso weiter wie vorher auch. Der Kram ist immer noch zu schwach und der Einarbeitungsaufwand trotzdem beträchtlich.

Ganz frisch noch zu DB-Edits :

www.delphipraxis.net...icht+editierbar.html

Solche Probleme damit habe ich zwar nicht, aber es ist mir noch nicht gelungen eine Form nur damit hinzukriegen. Angenommen ich ordne einem Artikel eine Warengruppe zu. Also die ID aus einer anderen Tabelle als Fremdschlüssel. Die ID der Warengruppe muß ich ja hinter den Kulissen dem Artikel zuweisen und der User soll die Nr. der Warengruppe eingeben können. Er kann das nun aber nicht in einem DBEdit machen, weil er sonst eventuell die Warengruppe editiert, obwohl er sie nur lesen will. Und ein DBText kann ich auch nicht verwenden, weil ja schon das WG-Feld eingegeben werden soll. Also ist in solchen Fällen sogar das DBEdit ausgeschieden.

Da hast Du Dir ja ganz schön Arbeit gemacht mit Deinem Kommentar Hansa, aber das bringt mir jetzt auch was.
Für meine kleine Applikation mit ein paar Edits und 2 DateTimePicker und einem Grid, das nur eine MasterDetail Info anzeigt ist das warscheinlich zwar kein Problem, aber oft wächst ein Programm auch mal weiter und dann kann es schon mal zu Problemen kommen.
Wollte nur wissen ob ich mir den Aufwand mit dem separaten wegschreiben und lesen ganz umsonst mache, oder ob es schon sinnvoll ist sich die Arbeit zu machen.