DBGRID und Daten laden

[Andy Nightingale]

BTW. Lazarus friert meistens nicht ein, sondern er wartet oft auf eine Quelle von Daten. Wenn ich ein verunglücktes SQL Statement in die Query schreibe, wo der Server 10 Minuten braucht um Daten zu liefern, das erscheint Lazarus tot ( scheinbar). Habe ich auch schon geschafft, kein Problem. Dann muss ich mich aber auch selbst fragen, was ich als letztes gemacht habe.

Solche Sachen sind durchaus normal und gehören zur Lernkurve oft dazu.

Ja das dachte ich auch.- ich ging etwas essen und mit dem Hund raus.-aber war immernoch so (2 Stunden)

Die Frage ist, was war die letzte Aktion vorher ?
Wenn du sagst, nichts, dannwürde ich Lazarus von der Kommandozeile aus starten, weil oft gibt es dann einen Hinweis. Weitere Eskalation setzten gibt es auch noch, aber erst dann wenn an nicht weiter kommt.

Aber zumindest der Hund und du haben was für die Gesundheit gemacht.

Ja das mit dem Hund ist wirklich so.-bringt viel.-wie meinst du das Lazarus von der Kommandozeile starten?

[kralle]

Moin,

ich verstehe das so, das Du dir überlegst, wie viele Spalten und Zeilen Du anzeigen willst,
wenn die Verbindung zur Datenbank noch nicht besteht und erstellst im FormCreate mit z.B. zwei verschachtelten Schleifen, Zellen in den z.B. nur ein Leerzeichen enthalten ist.
Dann baust Du die Verbindung auf und überschreibst die Leerzeichen mit den realen Daten.
Da ich zur Zeit nicht am Rechner bin, kann ich das jetzt nicht selber testen.
Interessant wäre, ob das Grid beim Verbinden, vielleicht wieder gelöscht wird.

Gruß Heiko

[Andy Nightingale]

Moin,

ich verstehe das so, das Du dir überlegst, wie viele Spalten und Zeilen Du anzeigen willst,
wenn die Verbindung zur Datenbank noch nicht besteht und erstellst im FormCreate mit z.B. zwei verschachtelten Schleifen, Zellen in den z.B. nur ein Leerzeichen enthalten ist.
Dann baust Du die Verbindung auf und überschreibst die Leerzeichen mit den realen Daten.
Da ich zur Zeit nicht am Rechner bin, kann ich das jetzt nicht selber testen.
Interessant wäre, ob das Grid beim Verbinden, vielleicht wieder gelöscht wird.

Gruß Heiko

Hallo Heiko,
verstehe.-das ist ein logischer Ansatz.-Danke dir.- den werde ich heute noch testen. Mal sehen ob ichs hinbekomme

[charlytango]

irgendwie lässt es mir keine Ruhe:

ich frage einfach mal nach:
Warum besteht zum Zeitpunkt des Öffnens des gegenständlichen Forms keine Datenbankverbindung?

Warum braucht man beim Öffnen des Formulars Daten im Grid ?
(Zusatzüberlegung - die Datenmenge würde man ja ohnehin mit den angesprochenen Buttons einschränken - da würde ein Button "hole alle Daten" das Kraut auch nicht fett machen.)

Sorry dass ich da insistiere -- Auch wenn der Kunde "das so will" - meinetwegen -- aber ich müsste zumindestens verstehen WARUM der Kunde das so will, sonst könnte ich das nicht adäquat und optimiert umsetzen.

Den Fortschrittsbalken der angedacht wurde kann man meiner Meinung nach nicht sauber einsetzen selbst wenn man den Weg von @Zvoni geht.
Die DB kennt erst die Anzahl der Records wenn sie sie gelesen hat. Oder in einem extra Statement gezählt hat.
Soweit so gut, irgendwie bekommt man heraus wieviele records es sind, aber ich kenne kein Event bei dem die DB den Fortschritt einer Datenübertragung signalisiert. Weder in SQLDB noch in ZEO und auch nicht im Datasource.
Also käme als Ausweichstrategie nur ein Balken mit Marquee in Frage, der zeigt an dass sich etwas tut aber nicht was wann wieviel oder wielange.

Wenn eine Datenbankverbindung besteht und man quasi eine Leere Zeile im Grid sehen will, ginge das über ein SQL SELECT

Code: Alles auswählen

SELECT '' as Feldname1, '' as Feldname2 from tablename WHERE 1

Andere Variante: du hängst das DataSource zuerst an ein TBufDataset oder eine TMemdataset in dessen Felddefinitionen genau die Feldnamen und Datentypen angelegt sind die dein SELECT liefert.
Und wann immer ein echtes SELECT startet(also vorher), setzt du das TDataset auf die richtige TQuery um.

Das geht dann auch ohne DB-Verbindung

[charlytango]

gelöscht

[Andy Nightingale]

irgendwie lässt es mir keine Ruhe:

ich frage einfach mal nach:
Warum besteht zum Zeitpunkt des Öffnens des gegenständlichen Forms keine Datenbankverbindung?

Warum braucht man beim Öffnen des Formulars Daten im Grid ?

Sorry dass ich da insistiere -- Auch wenn der Kunde "das so will" - meinetwegen -- aber ich müsste zumindestens verstehen WARUM der Kunde das so will, sonst könnte ich das nicht adäquat und optimiert umsetzen.

Den Fortschrittsbalken der angedacht wurde kann man meiner Meinung nach nicht sauber einsetzen selbst wenn man den Weg von @Zvoni geht.
Die DB kennt erst die Anzahl der Records wenn sie sie gelesen hat. Oder in einem extra Statement gezählt hat.
Soweit so gut, irgendwie bekommt man heraus wieviele records es sind, aber ich kenne kein Event bei dem die DB den Fortschritt einer Datenübertragung signalisiert. Weder in SQLDB noch in ZEO und auch nicht im Datasource.
Also käme als Ausweichstrategie nur ein Balken mit Marquee in Frage, der zeigt an dass sich etwas tut aber nicht was wann wieviel oder wielange.

Wenn eine Datenbankverbindung besteht und man quasi eine Leere Zeile im Grid sehen will, ginge das über ein SQL SELECT

Code: Alles auswählen

SELECT '' as Feldname1, '' as Feldname2 from tablename WHERE 1

Andere Variante: du hängst das DataSource zuerst an ein TBufDataset oder eine TMemdataset in dessen Felddefinitionen genau die Feldnamen und Datentypen angelegt sind die dein SELECT liefert.
Und wann immer ein echtes SELECT startet(also vorher), setzt du das TDataset auf die richtige TQuery um.

Das geht dann auch ohne DB-Verbindung

Hallo charlytango,
was du alles wissen möchtest. Ich kopiere die Fragen hierher und antworte dahinter.

Warum besteht zum Zeitpunkt des Öffnens des gegenständlichen Forms keine Datenbankverbindung?
Wie kommst du darauf das dies nicht so ist? Natürlich besteht eine Datenverbindung.-der Kunde meldet sich am Anfang mit der Form Mitarbeiteranmeldung an. Wenn er das PW richtig eingegeben hat dann öffnet sich die Mainform mit einem Überblick Grid.-das vollständig geladen ist. Der Kunde kann dann andere Infos wie Patientendaten usw. anklicken.

Warum braucht man beim Öffnen des Formulars Daten im Grid ?
Weil das logisch ist und der Kunde das möchte,- deshalb öffnet er ja das Grid. Merkwürdige Frage.
Alles andere verstehe ich nicht. Macht für mich kein Sinn.

[charlytango]

Warum braucht man beim Öffnen des Formulars Daten im Grid ?
Weil das logisch ist und der Kunde das möchte,- deshalb öffnet er ja das Grid. Merkwürdige Frage.
Alles andere verstehe ich nicht. Macht für mich kein Sinn.

Es kann schon sein dass das für dich keinen Sinn macht.
Und vielleicht ist es der Kunde einfach nur so gewohnt.

Bei einer Desktop Datenbank hast du natürlich die ganzen Datensätze einmal lokal und schränkst dann er ein. Bei Server willst du gar nicht noch alles haben, sonder nur das was bereits Eingeschränkt ist.

Es ist eine grundlegend andere Denkweise.

Als ich ich vor Dekaden noch mit dBase Derivaten zu tun hatte was das für mich auch so. Fenster auf und Tabellendaten anzeigen war eins.

Seit ich mit SQL arbeite, ist mein Konzept eher:
Formular geht auf, etwaige Grids sind leer, der Benutzer sieht seine Auswahlmöglichkeiten und holt sich (mit einer Aktion - Button, Editfeld etc) die von ihm gewünschten Daten.

Ich stelle es nur zur Diskussion und als Impuls es zu überdenken.
Denn damit hättest du mit einem Schlag dieses Geschwindigkeits-Problem vom Hals.
Denn beim Öffnen eines (Such- oder Übersichts-) Formulars erwartet dann niemand dass die Daten blitzschnell geliefert werden.
Ja, es ist vermeintlich ein Schritt dazwischen, aber sobald ein Benutzer eine angezeigte Liste per Button einschränkt sind die Aktionen gleich und nur vertauscht.

Sorry dass ich da missionarisch unterwegs bin

Warum besteht zum Zeitpunkt des Öffnens des gegenständlichen Forms keine Datenbankverbindung?
Wie kommst du darauf das dies nicht so ist? Natürlich besteht eine Datenverbindung.-der Kunde meldet sich am Anfang mit der Form Mitarbeiteranmeldung an.

Eine bestehende DB-Verbindung (vor dem eigentlichen SELECT, das Daten fetcht) war die Voraussetzung für meinen Vorschlag von oben. Eben den Grid mit einem Fake-SELECT zu füllen anstelle einer mehrzeiligen Aktion die leere Gridfelder manipuliert

[Andy Nightingale]

Warum braucht man beim Öffnen des Formulars Daten im Grid ?
Weil das logisch ist und der Kunde das möchte,- deshalb öffnet er ja das Grid. Merkwürdige Frage.
Alles andere verstehe ich nicht. Macht für mich kein Sinn.

Es kann schon sein dass das für dich keinen Sinn macht.
Und vielleicht ist es der Kunde einfach nur so gewohnt.

Bei einer Desktop Datenbank hast du natürlich die ganzen Datensätze einmal lokal und schränkst dann er ein. Bei Server willst du gar nicht noch alles haben, sonder nur das was bereits Eingeschränkt ist.

Es ist eine grundlegend andere Denkweise.

Als ich ich vor Dekaden noch mit dBase Derivaten zu tun hatte was das für mich auch so. Fenster auf und Tabellendaten anzeigen war eins.

Seit ich mit SQL arbeite, ist mein Konzept eher:
Formular geht auf, etwaige Grids sind leer, der Benutzer sieht seine Auswahlmöglichkeiten und holt sich (mit einer Aktion - Button, Editfeld etc) die von ihm gewünschten Daten.

Ich stelle es nur zur Diskussion und als Impuls es zu überdenken.
Denn damit hättest du mit einem Schlag dieses Geschwindigkeits-Problem vom Hals.
Denn beim Öffnen eines (Such- oder Übersichts-) Formulars erwartet dann niemand dass die Daten blitzschnell geliefert werden.
Ja, es ist vermeintlich ein Schritt dazwischen, aber sobald ein Benutzer eine angezeigte Liste per Button einschränkt sind die Aktionen gleich und nur vertauscht.

Sorry dass ich da missionarisch unterwegs bin

Warum besteht zum Zeitpunkt des Öffnens des gegenständlichen Forms keine Datenbankverbindung?
Wie kommst du darauf das dies nicht so ist? Natürlich besteht eine Datenverbindung.-der Kunde meldet sich am Anfang mit der Form Mitarbeiteranmeldung an.

Eine bestehende DB-Verbindung (vor dem eigentlichen SELECT, das Daten fetcht) war die Voraussetzung für meinen Vorschlag von oben. Eben den Grid mit einem Fake-SELECT zu füllen anstelle einer mehrzeiligen Aktion die leere Gridfelder manipuliert

Hallo Charlytango,
ich finde deinen Ansatz und die Denkweise absolut richtig.-Beim "ersten Grid" dem Übersichtsgrid habe ich ja nur wenige wichtige Datensätze als Anzeige. Ich werde trotzdem dem Kunden deine Idee mal so nebenbei vorschlagen wenn er brummelt wegen der Geschwindigkeit. Also auch dir danke für deine Ideen.