Was nimmt man denn so für den Zugriff auf Firebird von Lazarus aus? SQLDB, Zeos, IBX2, ...? Ich möchte die Transaktionssteuerung gerne selbst in der Hand halten und "Retaining" wenns geht vermeiden.

Bei Delphi nutze ich sehr viel das ClientDataSet, zum einen zum Editieren von Daten (hält die Transaktionen kurz), zum anderen als Grundlage aller Reports. Da gibts bei Lazarus wohl mehrere verschiedene Memory DataSets, bei dem keins den Gesamtumfang abdeckt, soweit ich das bislang erkennen kann. Was nehmt ihr denn so?

Zitat von Frickler:

Ich möchte die Transaktionssteuerung gerne selbst in der Hand halten und "Retaining" wenns geht vermeiden.

Könntest Du das vielleicht etwas erläutern?

Hallo,

Zitat:

Was nehmt ihr denn so

Ich habe für jede Tabelle ein Objekt/ObjektListe.

Die DB-Operationen laufen über einfache Queries.

Zitat von jobo:

Zitat von Frickler:

Ich möchte die Transaktionssteuerung gerne selbst in der Hand halten und "Retaining" wenns geht vermeiden.

Könntest Du das vielleicht etwas erläutern?

Naja um die "klassische Anbindung" wie anno dunnemals bei der BDE zu simulieren, laufen jetzt zum Beispiel bei IBDAC Queries standardmäßig mit Commitretaining und damit "ewig" offenen Transaktionen. Das mag bequem sein, ich möchte das aber gerne selbst steuern. Bei IBDAC kann ich das auch, aber wie ist es mit den anderen Komponenten?

Zitat von hoika:

Hallo,

Zitat:

Was nehmt ihr denn so

Ich habe für jede Tabelle ein Objekt/ObjektListe.

Die DB-Operationen laufen über einfache Queries.

Wie "dumm" ist dabei die Datenbank? Gibt es Constraints auf Feld-/Domainebene oder macht das alles Dein Programm selbst? Wie stehts mit der Rechteverwaltung: GRANT in der Datenbank oder alles in der Anwendung oder beides?

Wann und wie validierst Du Eingaben? Beim "Absenden" des Formulars oder schon auf Ebene der Editfelder?

Werden Reports auch aus Objektlisten generiert oder greifst Du dabei direkt auf die Datenbank zu?

Zitat von Frickler:

Naja um die "klassische Anbindung" wie anno dunnemals bei der BDE zu simulieren, laufen jetzt zum Beispiel bei IBDAC Queries standardmäßig mit Commitretaining und damit "ewig" offenen Transaktionen. Das mag bequem sein, ich möchte das aber gerne selbst steuern. Bei IBDAC kann ich das auch, aber wie ist es mit den anderen Komponenten?

Ok, Du willst eine richtige Datenbankanwendung bauen und fürchtest BDE Relikte in den Komponenten?
Ich kann mir ehrlich gesagt nicht vorstellen, dass man irgendwo sowas benutzen muss. Es gibt bestimmt gar kein RDBMS, was scharf darauf wäre, Transaktionen möglichst lange offen zu halten.

Außer in einem exclusiven single user Betrieb, sollte es auch keinen Anwender geben, der sowas möchte.

Ich denke, Retaining muss man explizit anfordern und man sollte es nicht machen. Aus Versehen geht also nichts schief.


Was willst Du mit Deiner Anwendung machen?
Bei einer kleinen lokalen Anwendung mit Embedded DB musst Du wohl selbst die Business Logik implementieren. (Also in Delphi)
Bei einer großen Serveranwendung könntest Du es auch in der DB machen, wenn die SP unterstützt oder Du baust eine Multi Tier Architektur, wo keine Clientanwendung direkt gegen die DB arbeitet.

Hallo,
Wie "dumm" ist dabei die Datenbank? Gibt es Constraints auf Feld-/Domainebene
ja, gibt es natürlich

Wie stehts mit der Rechteverwaltung:
selbst implementiert im Programm
GRANT in der Datenbank oder alles in der Anwendung oder beides?

Wann und wie validierst Du Eingaben? Beim "Absenden" des Formulars oder schon auf Ebene der Editfelder?
Sowohl als auch (z.B. TMaskEdit)

Werden Reports auch aus Objektlisten generiert
aus den Objektlisten

Zitat:

Ich denke, Retaining muss man explizit anfordern und man sollte es nicht machen. Aus Versehen geht also nichts schief.

Dieses Verhalten ist notwendig wenn das Verhalten der BDE simulieren werden soll(alles in einem Kontext).
Die Komponente T<xx>Table waren nur gedacht, um für BDE gedachte Programme einfach zu portieren (1.Schritt!)
Im 2. Schritt auf getrennte Transkationskontexte umstellen und dann
3. Schritt weg von T<xx>Table!

das Problem könnte deine Vorgehensweise sein, im Sine von "ich will das weiter so machen wie bisher, aber die Komponente soll das besser machen".

IBDac funktioniert mit Lazarus auch ganz gut,man braucht halt die Source Version lizensiert.

Ich für meinen Teil benutze in einem großen Lazarus Projekt kaum TDatasources und schon gar nicht für das Editieren von Daten, daher kann meine Software dauerhaft ohne offene Transaktionen auskommen

Michael van Canneyt vom Lazarus/fpc Entwicklerteam hatte letztes Jahr auf unserer Lazarus Konferenz gesagt, das die bei den eingebauten SQLDB Komponenten (die ich übrigens auch benutze) ein Commit auf der Connection die Datasets nicht mehr zwangsweise schliesst, so wie das nach meiner Kenntnis bei fast allen Delphi db Komponenten Standard ist und für viele auch der Grund ist, mit dem commitretaining zu arbeiten, was im Endeffekt serverseitig gar kein commit ist. Ich hab mir das selber noch nicht näher angesehen, auch weil ich eh niemals Datasets länger als für ein whilenot eof erforderlich offen halte, aber Michael hat das explizit noch mal bestätigt.

Zitat von mkinzler:

Dieses Verhalten ist notwendig wenn das Verhalten der BDE simulieren werden soll(alles in einem Kontext).

ja, das war eben die Frage was er vorhat.
Für mich klingt es eher so, als ob alles gar kein Problem wäre, wenn man diese BDE Sache nicht im Kopf hätte. Man müsste dann gar nichts vermeiden, weil es gar nicht mehr so gemacht wird.
~ Ich plane den Kauf eines Umwelt schonenden Elektroautos und frage mich, wie ich nun noch vermeiden kann, Adblue da reinzukippen.

Aber vielleicht verstehe ich die Frage auch nicht.