Firebird und Lazarus

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

[IBExpert]

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.

[jobo]

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.

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