| Autor |
Beitrag |
hansa
      
Beiträge: 3079
Erhaltene Danke: 9
|
Verfasst: Fr 28.02.03 10:16
Hi,
ich bin hier etwas am Grübeln. Die etwas komplexeren DB-Komponenten (DBcomboBox, DBlistBox, DBgrid usw.) kommen mir irgendwie zu unflexibel vor. Ich schildere das mal an zwei Beispielen : 1. In einer DBlistbox will ich jede zweite Zeile anders färben 2. In einem DBgrid will ich Art.Nr. Art.Bez. und Menge anzeigen, aber es gibt einige wenige Artikel, die eine zweite Zeile für eine längere Bezeichnung haben.
Letzteres fällt schon mal sofort raus. Das Grid ist fest mit der zugrunde liegenden Datenmenge verknüpft. Das geht so einfach wohl nicht. Mit der Farbe gibt es Ärger, da hier und da das OnDrawItem nicht bereitsteht usw. Es wäre zu viel alle mir noch aufgefallenen Einzelheiten hier zu erzählen. Die ganze Woche bin ich schon dabei mir für solche Fälle etwas einfallen zu lassen. Aber mittlerweile denke ich daran, auf diese Dinger zu verzichten und mit den äquivalenten nicht-DB Komponenten zu arbeiten. Mir kommt es so vor, daß ich dann eine bessere Kontrolle über mein eigenes Programm behalte und flexibler bin. Es ist zwar mehr Schreibarbeit, aber im Endeffekt bin ich doppelt so schnell, als die Unzulänglichkeiten der DB-Kompos auszubügeln. Mache ich irgendwas verkehrt oder ist dem wirklich so ? Dann würde ich nämlich lediglich noch DBtext und DBedit verwenden (es geht hier um die visuellen Kompos und nicht um DataSet, DataSource etc.). Ah, noch was, im Handbuch steht sogar irgendwo, daß die DBkompos wesentlich mehr Ressourcen verbrauchen, als die "normalen". Wer weiß zu der Thematik was zu sagen ?
_________________ Gruß
Hansa
|
|
Lubberer
Hält's aus hier
Beiträge: 7
|
Verfasst: Fr 28.02.03 11:36
Hi!
Also dem kann ich nur zustimmen. Auch ich habe mich schon oft über die Unflexibilität der DB Komponenten aufgeregt. Seien es die Datensteuerungskomponenten oder die Zugriffskomponenten (UpdateSQL, StoredProcedures etc.). Daher bin ich dazu übergegangen wirklich nur die aller notwendigsten Komponenten (bei mir im Allgemeinen Datasource und Query) zu verwenden. Alles andere mach ich über die Nicht-DB-Komponenten. Das ist zwar in der Tat mehr Schreibaufwand, aber man hat viel mehr Möglichkeiten und ist sein eigener Herr und Meister. Daher kann ich jedem nur empfehlen, sich die Mühe zu machen und die DB Komponenten soweit wie möglich zu verdrängen. Ähnliches gilt übrigens auch für den Quickreport und dessen Komponenten.
|
|
Lemmy
      
Beiträge: 792
Erhaltene Danke: 49
Windows 7 / 10; CentOS 7; LinuxMint
Delphi 7-XE10.1, VS 2015
|
Verfasst: Fr 28.02.03 11:42
Hi Hansa,
Du bist nicht auf dem falschen Weg, zumindest was IB/FB betrifft.
Das Problem bei IB/FB ist ja, dass eine Aktion nur in einer Transaktion ausgeführt werden darf. Bei den Transaktionen ist es nun von Vorteil, wenn die so kurz wie nur möglich offen stehen, da es sonst zu Deadlocks kommen kann.
Hier www.h-k.de/oop/ hat Holger Klemt einen Artikel online gestellt, der so auch im Entwickler erschienen ist. Darin geht es um den objektorientierten Zugriff auf DB's, d.h. es wird eine Klasse (z.B. Adresse) erzeugt, die für den Zugriff auf die Daten sowie die Visualisierung in Standard-Kompos zuständig ist. Der Artikel ist wirklich gut. Schau ihn dir mal an!
Man kann diesen Zugriff auch dazu verwenden, die zugrundeliegende Datenbank zu wechseln. Je nach verwendeter Datenbank nimmt man die entsprechende Klasse.... (die natürlich vorher programmiert werden muss)
Wenn Du diesen Weg einschlägst (Verzicht der DB-Kompos) dann versuche den Weg von Holger Klemt zu benutzen, denn der ist sicherlich der bessere (anstelle das ohne Klassen zu machen).
Grüße
Lemmy
|
|
hansa 
      
Beiträge: 3079
Erhaltene Danke: 9
|
Verfasst: Fr 28.02.03 12:05
Wie es aussieht habe ich mich schon viel zu lange mit dem Mist befaßt. Heute morgen ist mir endgültig der Kragen geplatzt.  Wollte mal wissen, ob mein Gespür da richtig ist. Das das auf Dauer nichts ist, habe ich gestern schon geahnt, habe mir sämtliche verfügbaren Borland-Handbücher angesehen. Immer wenn etwas dabei war, wo ich nicht richtig weiter kam, war eine Lösung von Borland zu sehen, die das Problem in etwa lösen würde, aber nichts von irgendwelchen DB-kompos.
| Lubberer hat folgendes geschrieben: | | Ähnliches gilt übrigens auch für den Quickreport und dessen Komponenten. |
Das hat ja gerade noch gefehlt, war mir fast klar. Aber in dieser Richtung, wo ist da die Alternative ?
@Lemmy: den Artikel habe ich schon mehrmals durchgelesen, verstehe nicht richtig worauf er da hinaus will.
Als vorläufiges Fazit (z.B. für die Nachwuchs-Künstler) : ein größeres Programm nur mit vorgefertigten Sachen zusammenklicken, das geht leider irgendwann schief. Ich werde auf jeden Fall in Zukunft lieber meine Zeit in eigene Programmierung stecken, anstatt irgendein vermeintlich gutes Feature zu verwenden, wo sich zum Schluß dann rausstellt, daß es nichts taugt.
_________________ Gruß
Hansa
|
|
Lemmy
      
Beiträge: 792
Erhaltene Danke: 49
Windows 7 / 10; CentOS 7; LinuxMint
Delphi 7-XE10.1, VS 2015
|
Verfasst: Fr 28.02.03 13:04
| hansa hat folgendes geschrieben: |
@Lemmy: den Artikel habe ich schon mehrmals durchgelesen, verstehe nicht richtig worauf er da hinaus will.
|
Wenn ich etwas Zeit habe, werde ich dazu noch was schreiben....
|
|
bis11
      
Beiträge: 1247
Erhaltene Danke: 2
Apple Mac OSX 10.11
|
Verfasst: Fr 28.02.03 13:09
Frage, wenn ich das in den Unterschiedlichen Foren gelesen habe, kannst Du das einfärben jeder zweiten Zeile in einer Listbox oder sonstiges mit den normalen Komponenten doch machen oder liege ich da verkehrt ?
Wenn ja, dann benutze diese und gehe her über die Query die Felder einzeln auszulesen und dann in die Kompo reinzuschreiben, so mache ich das zumindestens gerade bei einer Userverwaltung für ein Programm, wo das Passwort verschlüsselt in der Datenbank abgespeichert wird.
|
|
hansa 
      
Beiträge: 3079
Erhaltene Danke: 9
|
Verfasst: Fr 28.02.03 13:27
| bis11 hat folgendes geschrieben: | | ...kannst Du das einfärben jeder zweiten Zeile in einer Listbox oder sonstiges mit den normalen Komponenten doch machen oder liege ich da verkehrt ?... |
Ja, schon das war mit den DBkompos ein Problem.
| Zitat: | | ...und gehe her über die Query die Felder einzeln auszulesen und dann in die Kompo reinzuschreiben |
Also ich mach das ungefähr so :
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34:
| procedure TForm1.Button1Click(Sender: TObject); var st : string; begin // hier SelectString grob zusammenbauen IF Auswahl.ItemIndex = 0 THEN // Sortierung wählen RecDS.SelectSQL.Text := RecDS.SelectSQL.Text + 'ORDER BY NR' ELSE RecDS.SelectSQL.Text := RecDS.SelectSQL.Text + 'ORDER BY BEZ'; RecDS.Active := true; RecDS.First; WHILE NOT RecDS.Eof DO WITH RecDS DO BEGIN st := rb (FieldByName ('NR').AsString,5) + ' '; st := st + lb (FieldByName ('BEZ').AsString,30) + ' '; st := st + rb (FieldByName ('MENGE').AsString,8); lboZeigeRecPos.Items.Add(st); RecDS.Next; END; end;
procedure TForm1.lboZeigeRecPosDrawItem(Control: TWinControl; Index: Integer; Rect: TRect; State: TOwnerDrawState); var i : Integer; begin for i := 0 to lboZeigeRecPos.Items.Count do begin if Index mod 2 = 0 then begin lboZeigeRecPos.Canvas.Brush.Color := $C7FFE0; lboZeigeRecPos.Canvas.FillRect(Rect); lboZeigeRecPos.Canvas.TextOut(Rect.Left, Rect.Top, lboZeigeRecPos.Items[Index]); end else lboZeigeRecPos.Canvas.TextOut(Rect.Left, Rect.Top, lboZeigeRecPos.Items[Index]); end; end; |
Das dürfte ein klassisches Beispiel sein, wie es ohne DBkompos geht, nur mit DataSet und einer Listbox. Wobei mir da noch eine Frage einfällt : es gibt ja zumindest bei FIBplus die Funktion "generate SQL" In letzter Zeit benutze ich die nicht mehr, ich lege nur ein entsprechendes DataSet auf die Form lasse active auf false, baue mir (siehe oben) den passenden SQL-String zusammen. Fertig! Das funktioniert einwandfrei, aber irgendwie ist es mir doch unheimlich wenig. Allerdings muß ich dazu sagen, daß es sich in diesen Fällen nur um reine Select-Statements ! handelt!
Moderiert von Klabautermann: Tippfehler im Quote-Tag behoben.
_________________ Gruß
Hansa
|
|
bis11
      
Beiträge: 1247
Erhaltene Danke: 2
Apple Mac OSX 10.11
|
Verfasst: Fr 28.02.03 14:19
Mir ist ist schon klar, was Dein Code macht, aber ich stehe im Moment ein wenig auf dem Schlauch, wo Dein Problem liegt ?
|
|
hansa 
      
Beiträge: 3079
Erhaltene Danke: 9
|
Verfasst: Fr 28.02.03 18:13
siehe Titel :
Auf DB-Komponenten lieber verzichten ?
Natürlich kann ich auch die WinAPI oder gleich Delphi neu schreiben.  Es sind Meinungen gefragt, nicht Problemlösungen zu einem konkreten Problem. Viele Wege führen nach Rom.
_________________ Gruß
Hansa
|
|
|