DB-Grid nur für ganzeinfache Tabellen als Eingabe geeignet ?

[Hansa]

Um die geht es: :cat:

Ich habe das schon mal so ähnlich gefragt, Antworten waren aber nicht so eindeutig. Mir kommt es so vor, daß die visuellen DB-Kompos tatsächlich nichts taugen. Ich habe jetzt mit DBctrlGrid, DBgrid usw. lange experimentiert und denke, daß es nichts nützt.

Das ist nichts halbes und nichts ganzes. Irgendwo haperts immer. Dasselbe gilt für Fremdkomponenten. Sehe ich das verkehrt?

[r_kerber]

Dan will ich mal als erster auf diese doch etwas provokative :lol: Frage antworten. Bei vorgefertigten Komponenten kommt es IMHO immer darauf an, was Du damit vor hast. Die db-Kompos geben einen einfachen Einstieg in die Visualiserung von Datenbank-Inhalte. Dass die mitgelieferten Kompos nicht der Weisheit letzter Schluß sind liegt wohl daran, dass Borland kein Komponenten-Hersteller sondern eine Toolschmiede. Es gibt eine Unzahl von Datenbank für die unterschiedlichsten Zwecke. Falls für Deine Anforderungen dann bleibt Dir wohl nur, von vorhandenen Klasse neue abzuleiten und Deine eigene Funktionalität dahinein zu packen.

[Hansa]

Zitat:

Zitat von r_kerber

... Dass die mitgelieferten Kompos nicht der Weisheit letzter Schluß sind liegt wohl daran, dass Borland kein Komponenten-Hersteller sondern eine Toolschmiede...

Das dumpfe Gefühl hab ich mittlerweile auch. Dauernd hänge ich mit dem Kram irgendwo fest. Es ist schneller, einfach auf den Mist zu verzichten, weil viel zu starr.

Zitat:

Zitat von r_kerber

...Falls für Deine Anforderungen dann bleibt Dir wohl nur, von vorhandenen Klasse neue abzuleiten und Deine eigene Funktionalität dahinein zu packen.

Das ist des Pudels Kern, besser von einem StringGrid seinen Kram abzuleiten, als die DB Sachen zu benutzen. Dasselbe gilt für die anderen DB-Kompos. Vielleicht sagt ja noch jemand was zum Thema. :dancer:

[MrSpock]

Hallo Hansa,

ich kann deiner Einschätzung aus meiner Erfahrung nicht zustimmen. Seit Delphi 1.0 arbeite ich mit den Datenbank Komponenten, die Borland mitliefert. Unsere Anwendungen laufen seit Jahren stabil und ohne, dass jemals ein Kunde mit den Möglichkeiten der Datenbank Komponenten unzufrieden war. (Einzige Ausnahme ist die Verwendung der Return Taste zum Wechsel zum nächsten Feld, was aber programmtechnisch realisiert werden kann.)

Frage dich doch einmal selber, ob bestimmte Wünsche wirklich notwendig sind oder ob es sich dabei eher um Spielerei handelt.

[JoelH]

Zitat:

Zitat von Hansa

Sehe ich das verkehrt?

siehst du,

es gibt wohl nichts schnelleres um einfache übersichten zu erstellen als DBGrids, ich gebe zu, sie sind nicht der Anwenderhit aber wenn ich Übersichten brauch dann verwend ich DBGrids weil sie einfach schnell sind.

[Hansa]

Zitat:

Zitat von JoelH

...es gibt wohl nichts schnelleres um einfache übersichten zu erstellen als DBGrids,...

Als Eingabemedium scheinen sie trotzdem nichts zu taugen. Oder erkläre mir mal einer, wie ich 10 Tabellen mit Hilfe eines DBgrids, oder sonstwas aktualisiere, eventuell mit schönen Bildchen drinne, ein paar hübschen Farben, einer aussagekräftigen Beschriftung (Manko auch bei DBedits), eventuell variabler Anzeigedaten/Mengen usw.

Desweiteren liegt mir eine Aussage vor, die lautet :

Zitat:

Personally i never let users edit in DBGrids as I like to have more control over the users actions

Ob das nun stimmt, dürfte von Fall zu Fall verschieden sein. Bei einer einzigen Tabelle mit 5 Feldern ist ein DBgrid wahrscheinlich 1. Wahl.

[r_kerber]

Zunächst erst mal zu der Aussage. Ich schließe mich dieser vollinhaltlich an. Auch ich verwende dbGrids (und ganz egal welche) nur zur Anzeige (also RO). Für das Editieren/Einfügen von Daten estelle ich grundsätzlich Dialoge. Da kann ich die nach Bedarf gruppieren, bunte Bildchen anzeigen, Felder mit Standrars vorbelegen, Plausis prüfen etc. Und falls es zu viel Felder für eine Bildschirmmaske sind, dann "erschlage" ich das ganze in Form eines Wizards. Und ein dbGrid kann man via TQuery auch mit Daten aus vielen Tabellen füllen. Mit etwas Geduld gelingt sogar eine Master-Detail-Darstellung mit dbGrids!

[Jens Schumann]

Hallo,
ich halte solche Diskussionen für müßig.
Solche Fragestellungen beinhalten implizit die Frage nach dem einzig wahren Weg. Aber diesen Weg gibt es nicht. Genau so wenig wie es DIE Datenbank gibt. Oder die DIE Komponenten gibt.

!!! Einzig und allein der Kunde entscheidet !!!
D.h. wenn der Kunde die Daten über ein Grid eingeben möchte, dann wird das realisiert.

[Hansa]

Zitat:

Zitat von Jens Schumann

...D.h. wenn der Kunde die Daten über ein Grid eingeben möchte, dann wird das realisiert.

Klaro, der Kunde ist König. :mrgreen: Wenn es ihm aber egal ist, was machen ? Die Aufgabe ist folgende: Es müssen Eingaben gemacht werden, viele auf einmal, wobei man noch sehen muß, was man vorher gemacht hat. Z.B. Inventureingabe, Lieferscheine also in Listenform. Einfach nur Art.Nr. und Menge eingeben, mit der Möglichkeit zurückzuscrollen. Das ganze muß dann so 5-20 Tabellen aktualisieren. Mir kommt es so vor, daß das für DBctrlGrid, DBGrid etc. schon zu viel ist, wenn irgendwas noch angepaßt werden muß.

[Jens Schumann]

Hallo Hansa,
interessante Aufgabe.
Möchtest evt. 5-20 Tabellen gleichzeitig sehen können ?

[Hansa]

nix sehen, Insert/Update ! Zu sehen muß nicht viel sein. Daten aus 2-3 Tables. Habe gerade abgezählt : 7 Felder. Aber hinter den Kulissen müssen so 20 Tabellen bearbeitet werden.

[r_kerber]

Wie gesagt: Separate Editier-Maske (nicht unbedingt mit datensensitiven Elementen). Alles andere läuft unter der "Haube" ab mit UPDATE/INSERT-Statements.

[JoelH]

ich halte auch nix davon etwas im Grid selbst editieren zu können.
Wenn schon dann darf man eine Row oder Cell markieren und dann wird via Sialog dass ganze realisiert. Und was deine 20 Tabellen angeht, wo ist das Problem ? Wenn nur 7 Spalten angezeigt weren ist der Rest wohl nicht so wichtig für die Ansicht. Und wenn man dann was dabei editieren will => s.o. (via Dialog).

Ich sehe dein Problem noch immer nicht :(

Ich glaube du willst aus dem DBGrid mehr rausholen als drin ist und beschwerst dich dann dass nicht dass drin ist was du brauchst. Das ist IMHO ein wenig naiv gedacht.

[Hansa]

Zitat:

Zitat von JoelH

...ich glaube du willst aus dem DBGrid mehr rausholen als drin ist und beschwerst dich dann dass nicht dass drin ist was du brauchst. Das ist IMHO ein wenig naiv gedacht...

Von wegen naiv, ich muß halt alles rausholen, was irgendwie geht. Anscheinend ist es wirklich naiv zu glauben, da würde alles gehen, wie von Borland vorgegaukelt. Desweiteren sollte man den Beitrag von Jens Schumann beachten, "wenn der Kunde es so will kriegt er es eben so". Will der in einem Grid noch eine Endsumme, dann kriegt er die, notfalls in hellgrün mit Karos gemustert. Und bei sowas ist das DBgrid anscheinend total überfordert.

P.S.: ich ändere mal den Titel!

[JoelH]

Zitat:

Zitat von Hansa

Und bei sowas ist das DBgrid anscheinend total überfordert.

jupp, dafür ist es auch gar nicht da. Mach es halt mit einem Stringgrid oder schreib die eine eigene Klasse . ausserdem kan ein DBGrid eben nicht alles zusammenzählen, weil es eben gar nicht alles auf einmal einliest !

[Hansa]

Zitat:

Zitat von JoelH

...oder schreib die eine eigene Klasse...

Wenn Du so was schon gemacht hast, dann erzähle mal wie

[r_kerber]

Zitat:

Zitat von JoelH

ausserdem kan ein DBGrid eben nicht alles zusammenzählen, weil es eben gar nicht alles auf einmal einliest !

Ein DBGrid liest überhaupt nichts ein sondern zeigt nur das result-Set einer Datenbankabfrage an. Und wenn der Datenbank vernünftig arbeitet, dann werden auch nicht alle Datensätze auf einmal vom Datenbank-Server geholt sondern nur eine kleine Portion. Und beim Scrollen im DBGrid werden halt weitere Datensätze angefordert. Wenn Du dann irgendwelche Summen ermiteln willst, dann mußt Du eben ein entsprechendes SQL-Select an die Datenbank schicken. z.B.:

SQL-Code:

SELECT sum(spalte) FROM tabelle WHERE bedingung.

[Hansa]

Hi Rainer,

ja, so ist das, aber wie kriege ich so was dem DBgrid beigebracht ?

[r_kerber]

Gar nicht. :?