Firebird und Lazarus

[Frickler]

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?

[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?

[hoika]

Hallo,

Zitat:

Was nehmt ihr denn so

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

Die DB-Operationen laufen über einfache Queries.

[Frickler]

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?

[Frickler]

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?

[jobo]

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.

[hoika]

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

[mkinzler]

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!

[Frickler]

Zitat von jobo:

Ok, Du willst eine richtige Datenbankanwendung bauen und fürchtest BDE Relikte in den Komponenten?

Nee so nicht Ich fürchte, ich habe mich falsch ausgedrückt. Ich möchte eben nicht "weiter wie BDE", und brauche deswegen auch keine db-Komponenten, die sich BDE-like verhalten (gibts ja reichlich im Delphi-Umfeld).

Ich möchte ein über lange Zeit gewachsenes Programm modernisieren, ohne es komplett neu schreiben zu müssen. Zu Anfang in den 90ern haben wir das mit BDE/Paradox gemacht, später bin ich auf ADS umgestiegen (mit dem man die "BDE-Schiene" mit SetRange, Locate und co. einfach weiterfahren kann...); aber ADS ist tot. Jetzt soll es Firebird werden, open source, einfach zu installieren und zu warten (IBExpert sei Dank ). Der Umstieg ist im vollen Gange, Zugriff mache ich per IBDAC. Die "BDE-Schiene" habe ich stillgelegt, Zugriffe passieren weitgehend über Queries (lesen) und SPs (schreiben).

Ich verwende Delphi XE6 und sehe mich ein bisschen am Scheideweg: weiter upgraden auf 10.x oder umsteigen auf Lazarus. Alle Fremdkomponenten die zur Zeit genutzt werden, gibt es auch für Lazarus. Für die viel genutzten ClientDataSets muss ich eine Ablösung finden.