Hi,
irgendwie stehe ich hier gerade komplett auf dem Schlauch. Ich hab gedacht das ich mal so langsam bei Delphi durchblicke, aber Pustekuchen.
Im Moment hänge ich an den Begriffen DataSet und DataSource. Insbesondere verwirrt mich momentan das man einem DataSource ein TQuery als DataSet zuweisen kann, umgekehrt kann man dem TQuery ein DataSource zuweisen. Bisher hab ich das so vestanden das eine Komponente wie TTable die Daten erstemal aus der DB holt. TDataSource holt sich von dort und stellt sie DBGrid oder DBEdit zur Verfügung. Ich kann also in die Eigenschaft DataSet von TDataSource eine TTable oder TQuery eintragen. Das geht soweit.
Aber wieso kann auf einmal ein TQuery auch in die andere Richtung verbunden werden? Muß ich das dann machen wenn ich nicht nur Daten mit SELECT hole sondern auch Daten mit INSERT wieder schreiben will?
Und wie kann ich an den Inhalt von Feldern kommen wenn ich ganz ohne DBEdit und DBGrind arbeiten möchte?

Fragen über Fragen, aber vielleicht hat ja jemand die Gedult um sie mir zu beantworten. Bedanken tu ich mich schonmal im Voraus.

Gruß
Markus

Ich glaub, ich hab ein paar der Rätsel entschlüsseln können. Wenn ich das richtig sehen braucht ich TDataSource gar nicht wenn ich nicht mit visuellen Komponenten wie TDBEdit oder TDBGrid arbeite, sehe ich das richtig? So wie es aussieht werde ich fast ausschließlich mit TQuery arbeiten und die Daten "von Hand" weiterverarbeiten

Hi!

Zunächst mal ist die Reihenfolge so:

DB-Controls -> Datasource -> Query

Die Datasource ist sozusagen nur ein Verbindungsstück, das implementiert wurde, um schnell das Dataset für mehrere Controls auf einen Schlag zu ändern.

TQuery-Komponenten haben auch eine Datasource Eigenschaft, damit diese Query von anderen Datasets über Parameter beeinflusst werden kann. Standardmäßig ist diese erst einmal nicht zugewiesen.

Cu,
Udontknow

Udontknow hat folgendes geschrieben:

DB-Controls -> Datasource -> Query Die Datasource ist sozusagen nur ein Verbindungsstück

Jo, so in etwa hab ich mir das auch gedacht. Und Query oder Table ist dann das DataSet. Nach dem Query käme dann noch Database und evt noch Session.
Aber theoretisch brauche ich außer TQuery gar nichts hab ich festgestellt.

So langsam steig ich durch

THX
Markus

Um die Datasource kommst Du aber nicht herum, wenn Du Datensteuerelemente verwendest. Du musst aber im Normalfall nichts damit machen. Nur auf einem Formular, bzw. Datenmodul platzieren, den Namen der Query eintragen und in die Controls den Datasource-Namen setzen.

Wenn Du auf die Daten nur programmgesteuert zugreifst, also KEINE datensensitiven Controls verwendest, kannst Du auf die Datasource wirklich verzichten.

burli ist auf dem richtigen Weg. Die DB-Komponenten taugen nicht viel. Anscheinend hat er das bemerkt. Hier und da verwende ich DBedit oder DBtext und das wars schon. DBgrid z.B. habe ich ersatzlos gestrichen. Da nehme ich lieber ein Stringgrid und mache alles selber wie ich es will. Daß die DBedits überleben, wage ich auch zu bezweifeln. Denn dann muß ich die Transaktionen zu lange offen halten. Eine Alternative wären eventuell Read/Write-Transaktionen. Da weiß ich aber noch nicht genau, wie das geht. Angeblich soll bei FIBplus damit die Wahrscheinlichkeit eines Deadlocks usw. auf 0 zu reduzieren sein.

@Hansa:

Was ist denn so schlimm an DB-Grids? Und was haben die mit Transaktionen zu tun? Transaktionen sind doch ein Mechanismus/Feature der zugrundeliegenden DB, das hat doch nix mit irgendeinem Steuerelement zu tun?

Cu,
Udontknow

hansa hat folgendes geschrieben:

burli ist auf dem richtigen Weg.

Das geht runter wie Öl
Aber nochmal ne Frage: ich hab ein kleines Prob bei meinem Provider. Der hat seinen SQL Server so konfiguriert das eine inaktive Verbindung nach 15 Sekunden getrennt wird. Das reicht meistens nicht mal um irgendwelche Datensätze anzulegen.
Wie würdet Ihr an das Prob rangehen? Ich möchte nicht unbedingt in 10 Sekunden Interwallen den Server anpingen, das ist schlechter Programmierstil. Ich könnte natürlich auch nach einer Transaktion TDatabase.Connected auf False setzen und vor der nächsten wieder Connecten. Nur hab ich dann das Problem das dann alle danan anschließenden Komponenten auch deaktiviert werden. Für den Fall das ich da noch ein DBEdit oä dran hab sind die Daten weg. Ich müsste also alles per Query holen und zwischenspeichern. Gibt es vielleicht noch eine andere Lösung?

Gruß
Markus

Udontknow hat folgendes geschrieben:

@Hansa: Was ist denn so schlimm an DB-Grids? Und was haben die mit Transaktionen zu tun? ...

Im Prinzip nichts. Die sind mir aber zu unflexibel. Hatte mit einem DBgrid 3 Wochen rumexperimentiert, weil ich dachte es ginge damit. Pustekuchen. In 2 Tagen war es mit einem Stringgrid erledigt.

Und die Transaktionen? Tja das ist so ne verflixte Sache. Die DBedits sind dafür schon gut. Nur: ändere ich was an den Daten, ist das dahinterliegende Dataset geöffnet und somit auch eine Transaktion. Jetzt mache ich Urlaub, dann ist die Transaktion eventuell nach Wochen immer noch offen.

Deshalb bin ich schwer am Überlegen auf die DB-Komponenten komplett zu verzichten. Es ist am Anfang mehr Arbeit, lohnt sich aber im Endeffekt
doch. Das ist übrigens auch ungefähr die Meinung von UGrohne. Der hat gesagt: "Ja, das ist mein voller Ernst".

Naja gut, das eine Transaktion gestartet wird, ist nicht abhängig von den Steuerelementen, sondern, wie du schon sagst, vom Dataset. Bei Clientdatasets z.B. passiert da gar nichts auf DB-Ebene, bevor du nicht ApplyUpdates aufrufst.

Als ich früher noch mit TQueries gearbeitet hatte, habe ich auch immer haarsträubende Fehlermeldungen bekommen (mein Lieblingsfehler war "Datensatz / Schlüssel gelöscht"). Seitdem ich TClientdatasets benutze, bin ich im 7. DB-Himmel.

Cu,
Udontknow

@hansa: darf man mal indiskret fragen was mit DBGrind nicht funktioniert hat?
Ich hab grade gesehen das man im DBGrid sogar Bilder und Memos einbinden kann und statt einem Feld auch ComboBoxen oder LookupFields einblenden. Finde ich schon recht ansprechend wenn es einem für Datenpräsentation und -eingabe reicht

Wie gesagt, die Transaktionen kurz zu halten ist mit dem Ding unmöglich. Versuche das mal für Eingaben zu verwenden: unmöglich, also besser gleich vergessen. Versuche dann mal, eine Zeile irgendwie anders zu gestalten: Fremdkomponenten sind gefordert, die das Problem mit den Transactions aber auch nicht beheben.

Ich muß aber dazu sagen, daß das Programm,an dem ich dran bin, im Netzwerk laufen muß, bei einem Einzel-PC ists vielleicht egal. Die einzige (und das ist eine Aussage, die ich noch nicht überprüft habe) ist, daß FIBplus eine lange lesende Transaktion und eine kurze Schreib-Transaktion erlaubt.

@Hansa
Du musst die Komponenten auch richtig anwenden, sprich dass nehmen was der Situation angemessen ist. Ein DBGrid ist zb. 100x besser als ein Stringgrid wenn du einfach und schnell Daten anzeigen wllst. Schonmal mit einem Strigngrid versuch 300000-400000 Datensätze zu laden und an zu zeigen ? Viel Spass, da ist gedult gefordert da du alles erstmal laden musst. Bei einem DBGrid geht das ratz fatz weil er nur das läd was gerade angezeigt wird. Wie gesagt es geht hier nur um Daten anzeigen.

Geht es um Datenmanipulation dann sit ein Stringgrid besser, da man erst läd , dann Manipuliert und dann schreibt. Die Session mit der DB also nicht dauernt offen sein msus, man immer genau weiss wo man im Grid ist usw. Ausserdem kann man zusatzinfos leichter in das Grid bringen usw.

Transaktionen gehören hier überhaupt nicht rein. Wer eine Transaction aufmacht und diese dann lange laufen lässt gehört gesteinigt. Transactions macht man wenn man alle Daten zusammen hat und dann nurnoch alles in die DB schiesst. Aber man starte keine Transaktion und lässt die 5 min. offen bevor man sie abschliesst. Mein Datenbank Dozent wäre an die Decke gesprungen hätte man ihm sowas erzählen wollen.

JoelH hat folgendes geschrieben:

...Geht es um Datenmanipulation dann sit ein Stringgrid besser, da man erst läd , dann Manipuliert und dann schreibt. Die Session mit der DB also nicht dauernt offen sein msus, man immer genau weiss wo man im Grid ist usw. Ausserdem kann man zusatzinfos leichter in das Grid bringen usw. Transaktionen gehören hier überhaupt nicht rein. Wer eine Transaction aufmacht und diese dann lange laufen lässt gehört gesteinigt. Transactions macht man wenn man alle Daten zusammen hat und dann nurnoch alles in die DB schiesst. Aber man starte keine Transaktion und lässt die 5 min. offen bevor man sie abschliesst. Mein Datenbank Dozent wäre an die Decke gesprungen hätte man ihm sowas erzählen wollen.

Hoffentlich hast Du Recht. So sieht nämlich mein Konzept im Moment auch aus. Aber trotzdem fällt mir gerade ein, daß selbst zu Anzeigezwecken das DBgrid ungeeignet war, sofern es darum geht, Datensätze mehrzeilig darzustellen, statt in einer einzigen riesigen Zeile. Wenn Du da mal kurz ein Patentrezept dazu eventuell vielleicht hättest ? An dem Punkt hatte ich nämlich das DBgrid bis auf weiteres weggeschmissen.

Hm, das mit den Transaktionen hab ich noch nicht so ganz geblickt. Kann mir das bei meinem Prob mit meinem Provider und dem 15 Sekunden Timeout helfen?
Ich hab nämlich nen Online Shop erstellt der auf ner DB basiert und ich möchte den nicht über ein webinterface administrieren. Dafür will ich mit Delphi ne App erstellen.
Wenn ich z.b. nen neuen Artikel anlege würde ich ja "normal" die DB öffnen, über DBEdit usw ein paar neue Daten eingeben und dann hinzufügen. Nur bis ich fertig bin ist die Verbindung weg ich bekomm erstmal ne Fehlermeldung. Nur das ist fern ab von jeglichem guten Stil. Nur nach dem richtigen such ich noch

@Hansa
Wie gesagt, nutzen wenn sie zu sinnvoll zu nutzen sind. Ich benutz sie um schnell was an zu zeigen. Ansonsten eher nicht.

@burli
Transaktionen sind das sichere Übertragen von DAten und wir sprechen hier von ca.100%.
Eine Transaktion ist eigentlich eine folge von mehreren SQL Statement. Diese werden entweder alle erfolgreich ausgeführt oder es wird keine eine davon ausgeführt. Und genau deshalb dürfen sie nicht länger als nötig dauern. Denn sie blockieren quasi den Server für andere User.
Deshalb sollten da immer alle Statements hintereinander folgen und der Anwender keien Möglichkeit haben dazwischen noch was zu überlegen und ein zu geben etc. Dann speicher lieber alle Daten erstmal in einem Array und schreib sie dann komplett.