Edit oder DBedit?

[plautzer]

Hi,

es ist zwar ne ziehmlich banale frage, aber ich würde gern mal wissen, was für edits und dbedits in verbindung mit datenbanken (Interbase) spricht.
Ich weiß das dbedits speziell für den Gebrauch mit datenbanken gedacht sind, gibt es aber nachteile und wären so edits geeigneter?

Thx,

plautzer

[Hansa]

Zitat:

Zitat von plautzer

es ist zwar ne ziehmlich banale frage...

Diese Frage ist ganz und gar nicht banal. 8) Bei größeren Sachen sind DBedits ziemlich ungeeignet, weil zu unflexibel.

[urs.liska]

Der Nachteil an Edits ist, dass Du alles selber machen musst (Daten einlesen, prüfen, anzeigen).
Der Nachteil an DBEdits ist, dass sie alles für Dich machen (Du also in bestimmten Fällen keinen Einfluss mehr hast).

Es kommt auf den Zusammenhang an...

[Hansa]

Stop ! Es geht nur um DBEdits ? Na ja, die kann man noch verwenden, aber DBGrid, DBChart usw. nicht wirklich. Dann lieber selber Arbeit reinstecken. Mit einem OOP-Ansatz wird das dann auch was gutes, ohne die eingebauten Nachteile.

[Jelly]

Vorteil von DBEdit liegt auf der Hand. 2 Properties ausfüllen, schon hast du die korrekten Daten drin, kannst diese problemlos ändern usw. Nachteil ist allerdings, sobald du was in ein Editfeld tippst, dieser Datensatz für andere User gesperrt wird, und zwar solange du ein Post oder Cancel aufrufst. Handelt es sich um viele Datenbankfelder, oder du vergisst das Post und gehst in die Mittagspause, kann der Datensatz unter Umsatänden sehr lange gesperrt sein. In kleinen Netzwerken sicherlich nicht dramatisch. Greifen aber viele User auf die DB zu, sollte schon ein Gedanke an die Datensatzsperre verschwendet werden.

Gruß,
Tom

[plautzer]

Also sind dbedits klar zu empfehlen.
Mein Programm soll vorerst sowieso nicht mit Netzwerk laufen.
Mit dbgrids, dbcomboboxen hatte ich schon mal probleme, also nutze ich da lieber auf stinggrid, CB ua. Ich war mir jetzt bloß noch im unklaren, ob dbedits besser/ eigneter als edits wären.

Ich danke,

Plautzer

[Bernhard Geyer]

Zitat:

Zitat von plautzer

Also sind dbedits klar zu empfehlen.

Würde ich nicht sagen.

Um schnelle Ergebnisse zu bekommen oder für Prototypen - Klares Ja.
Für komplexere Programme sind datenbankgebundene Grundsätzlich mit Vorsicht zu verwenden. Vor allem wenn man sein Programm über eine mehrschichtige Architektur betreibt bzw. einfach alle in intelligentere Objekte verpackt ist eh Schluß mit DB-Bindung von Controls.

[urs.liska]

@Bernhard Geyer
@Hansa

Verstehe ich das richtig: Ihr (das sind in diesem Fall die Leute mit Erfahrung bei größeren DB-Projekten) empfehlt für eine komplexere Datenbankanwendung folgendes Vorgehen:
- Formular mit normalen Steuerelementen aufbauen.
- Eine Klasse für den Datensatz entwickeln.
- Den Datensatz aus der DB in das Datensatz-Objekt einlesen und von diesem anzeigen lassen.
(- Transaktion beenden)
- Daten bearbeiten, nur im Formular
- Daten im Kontext einer neuen Transaktion durch das Datensatz-Objekt in die DB schreiben lassen und dabei, evtl. in der Zwischenzeit durch andere Benutzer entstandene, Konflikte auflösen

Ich stehe gerade vor Beginn meines ersten „größeren“ DB-Projekts und wage noch nicht, mich für einen Ansatz zu entscheiden...
(größer bedeutet: ca. 40 Tabellen (Firebird), davon viele Nachschlage- und Interselektionstabellen. In den Hauptformularen der Anwendung werden sicher jeweils die Hälfte bis zwei Drittel der Tabellen verwendet).

Danke für die Meinung
Urs

[Sharky]

Hai Urs,

auch ich verwende nach möglichkeit keine Visuellen DB-Komponenten mehr. Es ist zwar mehr arbeit aber dafür habe ich dann auch volle Kontrolle über alles was passiert. Meiner Meinung nach rechtfertig dies den Aufwand.

[urs.liska]

Und wie sieht es mit Detaildatensätzen aus?
Eine array-eigenschaft im hauptdatensatz, die wiederum objekte für die detaildatensätze enthält?
Oder gar eine Collection?

Und Nachschlagefelder?
Normale Combobox und bei OnDropDown eine hintergrundquery?

Urs

[Hansa]

Sharky hat offensichtlich dieselben Erfahrungen mit DB-Komponentanen gemacht wie ich. Zumindest bei mir sind sie ziemlich schnell an ihre Grenzen gestoßen. Die sind ganz einfach zu starr. 3 Beispiele :

DBGrid :

ich brauche manchmal bei Artikeln 2 Zeilen für die Bezeichnung. Die sollen untereinander stehen, nicht nebeneinander. Das betrifft aber nur eine Spalte. Es ging einfach nicht wie gewünscht. Besser gesagt, habe ich es nach 2 Wochen Handbuch lesten, testen usw. aufgegeben. In einem Tag habe ich es mit einem Stringgrid hingekriegt. DBCtrlGrid war auch nicht zufriedenstellend.

DBComboBox :

Hier war die Anforderung, daß die Auswahl auch durch Eingabe der Nr. möglich sein sollte. Ich bekam die Nr. und die Bezeichnung zwar in die Box, nicht aber in das Auswahlfeld, damit war allerdings nach 1 Tag schon Schluß.

TDBchart :

dem habe ich gerade mal eine Stunde gegeben, um eine gute Dasrtellung zu präsentieren. Ging nicht. Mit TChart ging es aber in der Zeit.

Eine Ausnahme stellt in dem Projekt allerdings das DBEdit und DBText dar. Die verwende ich schon. Sind ja auch die einfachsten von allen. Aber die wiederum sind zu einfach. :mrgreen: Deshalb habe ich sie erweitert. Ich habe also ein DBIntEdit, DBRealEdit usw. und wenn ich die auf die Form lege, dann ist schon mal geklärt, daß nur Zahlen oder auch nur ein Komma usw. eingegeben werden können. Der Nachteil hierbei war, daß man für so was schon tief in die Komponentenentwicklung einsteigen muß. Aber es war ziemlich klar, daß man da nicht komplett drumrum kommt.

Und noch eines zum Schluß : das "Allheilmittel" Fremdkomponenten. Habe mir da auch welche angesehen. Die waren zwar besser als die Standard-Delphi Sachen, aber immer noch nicht so gut, daß es sich gelohnt hätte dafür Geld zu investieren, denn wenn die 40% der abgedeckten Anforderungen von Delphi schon zu wenig sind, dann sind die 80% einer Fremdkomponente eben immer noch zu wenig.

[GuenterS]

Ich habe mal eine Anwendung ziemlich schnell entwickeln müssen und es wurde darauf gedrängt, dass ich die DB Editoren verwende.

Das hat sich aber schlußendlich als ein Schuss nach hinten herausgestellt, da man wirklich vieles nicht mehr kontrollieren kann. So zum Beispiel passiert ein implizites post wenn Du in einer DBLookupbox den Eintrag wechselst.

[GuenterS]

Zitat:

Zitat von Hansa

Eine Ausnahme stellt in dem Projekt allerdings das DBEdit und DBText dar. Die verwende ich schon. Sind ja auch die einfachsten von allen. Aber die wiederum sind zu einfach. :mrgreen: Deshalb habe ich sie erweitert. Ich habe also ein DBIntEdit, DBRealEdit usw. und wenn ich die auf die Form lege, dann ist schon mal geklärt, daß nur Zahlen oder auch nur ein Komma usw. eingegeben werden können. Der Nachteil hierbei war, daß man für so was schon tief in die Komponentenentwicklung einsteigen muß. Aber es war ziemlich klar, daß man da nicht komplett drumrum kommt.

Und noch eines zum Schluß : das "Allheilmittel" Fremdkomponenten. Habe mir da auch welche angesehen. Die waren zwar besser als die Standard-Delphi Sachen, aber immer noch nicht so gut, daß es sich gelohnt hätte dafür Geld zu investieren, denn wenn die 40% der abgedeckten Anforderungen von Delphi schon zu wenig sind, dann sind die 80% einer Fremdkomponente eben immer noch zu wenig.

DBEdit prüft doch eigentlich eh schon was für ein Datenfeld dahinter steckt, also kann man in ein Zahlenfeld eh auch keine Strings eingeben (außer Hexzahlen).

Es gibt schon auch gute (teure) Fremdkomponenten, wenn ich da an das QuantumGrid von DevExpress denke. Tabellen inherhalb anderer Tabellen bis zur x-ten Ebene, mit Gruppier und Sortiermöglichkeit, eingebauten Filtern, etc. Da würde man schon lange brauchen um das selber in der Art zu programmieren.

[Bernhard Geyer]

Zitat:

Zitat von GuenterS

Es gibt schon auch gute (teure) Fremdkomponenten, wenn ich da an das QuantumGrid von DevExpress denke. Tabellen inherhalb anderer Tabellen bis zur x-ten Ebene, mit Gruppier und Sortiermöglichkeit, eingebauten Filtern, etc. Da würde man schon lange brauchen um das selber in der Art zu programmieren.

Zur reinen Darstellung mag das einen Vorteil bringen. Aber wenn es ins Detail geht ist man ohne DB-Bindung besser dran.

[Schuster]

Also ich muß allen zustimmen die ein reines Editfeld nehmen denn
ich hab nur ein kleines DB Projekt und bin auch schon auf die grenzen
eine DB-Editfeldes gestoßen. :?

Ist zwar mehr arbeit, da alles manuel befüllt werden muß aber man
hat eben die voll Kontrolle. :-D

[Hansa]

Zitat:

Zitat von GuenterS

DBEdit prüft doch eigentlich eh schon was für ein Datenfeld dahinter steckt, also kann man in ein Zahlenfeld eh auch keine Strings eingeben (außer Hexzahlen).

Es gibt ja noch viel mehr. Rechtsbündige Zahlendarstellung wie bei Taschenrechner ? Label gleich mit dabei ? 2 Kommas unterbinden, Tausender-Trennzeichen ? usw. Geht das mit Standard DB-Edits ? Hex geht sogar ? :shock: Bei mir leider nicht. :mrgreen: Da ich so was auch brauche für nicht-DB Komponenten habe ich kurzerhand eben das für DBEdits gleich mit übernommen und somit einheitlich gemacht.

Aber wie gesagt, das sind eigene Komponenten und die kann man nicht einfach so nebenbei in 5 Min. ohne Vorkenntnisse schnell machen. Basieren tun sie aber tatsächlich auf dem Standard DBEdit.

[GuenterS]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von GuenterS

Es gibt schon auch gute (teure) Fremdkomponenten, wenn ich da an das QuantumGrid von DevExpress denke. Tabellen inherhalb anderer Tabellen bis zur x-ten Ebene, mit Gruppier und Sortiermöglichkeit, eingebauten Filtern, etc. Da würde man schon lange brauchen um das selber in der Art zu programmieren.

Zur reinen Darstellung mag das einen Vorteil bringen. Aber wenn es ins Detail geht ist man ohne DB-Bindung besser dran.

Du scheinst diese Fremdkomponente nicht zu kennen, sonst würdest mir zustimmen. Aber es gibt von allem gut und böse bzw. schlecht.

[plautzer]

HI leute,

ich habe noch mal ein paar fragen zu StringGrids und Dbgrids.

DAs grid soll mit abrechnungsdaten gefüllt werden, also nichts kompliziertes.
Es soll nur bei erstellen eines neuen datensatzes, 2 daten automatisch eingefügt werden (IDs).

Das habe ich bis jetzt alles mit StoredProcs gelöst. Kann ich diese auch in Verbindung mit dbgrids verwenden, oder sollte man da eher ibdatasets verwenden?

Ich nehme an, das es ziehmlich kompliziert und aufwendig ist mit einen Stringgrid zu arbeiten (d.h. daten hinzufügen, aktualisieren und löschen).

Welche erfahrung habt ihr bisher gemacht?

Plautzer

[Hansa]

Zitat:

Zitat von plautzer

...Das habe ich bis jetzt alles mit StoredProcs gelöst. Kann ich diese auch in Verbindung mit dbgrids verwenden, oder sollte man da eher ibdatasets verwenden?
...

Plautzer was soll das ? Du vermischst visuelle Delphi-Komponenten mit Sachen der DB. 8)