Datenbank-Zugriff auslagern in Datenmodul

[af0815]

Das hat aber absolut nichts mit dem Datenmodul zu tun. Es ist nur die Art zu arbeiten. Das Datenmodul ist ja nichts anderes wie ein Form ohne Sichtbarkeit.

[charlytango]

als vielmehr mit deinem Datenhandling.

Da gibt es unterschiedliche Strategien dazu, auch ob für einzelne Themen (z.B. Rechnungserstellung) nicht doch eigene DB-Verbindungen mit eigene Transaktionen nötig sind, was aber auch wieder Einfluss auf die maximal möglichen offenen Verbindungen am SQL-Server bzw dessen damit verbundenen Speicherbedarf hat. So eine Strategie für Datenhandling geht weit über die Entscheidung hinaus ob datensensitive Controls verwendet werden sollen oder auch nicht. z.B. Locking in Mehrbenutzerumgebungen.

Ob die Rechnung in der Datenbank steht sollte die Entscheidung dessen sein, der eine Rechnung erstellt, heiß bei einer nicht fertige Rechnung muss es die Möglichkeit geben diese wieder zu verwerfen.

Da bin ich etwas anderer Meinung. Bei der Anlage eines "Dokuments" (also z.B. Auftrag, Rechnung, Gutschrift, Lieferscheine et al.) speichere ich jede Benutzereingabe sofort in der Datenbank, allerdings immer als "Entwurf". Damit kann ein Benutzer auch immer auf seine Arbeit zugreifen. Laufende Rechnungsnummern werden immer dann vergeben, wenn ein Benutzer einen Entwurf finalisiert, was eine getrennte Benutzeraktion ist, die dann nicht mehr rückgängig gemacht werden kann

[charlytango]

Solange mit meinen Anwendungen nur max. eine Handvoll Benutzer im LAN arbeiten, sollten die paar Datenbankverbindungen nicht stören.

Wie groß ist diese Hand, die da voll Benutzer ist?
Wieviele Formulare mit eigener Connection existieren pro User gleichzeitig?
Wie klein ist der Server ?
Was ist sonst noch im Lan los?
Erlaubst du paralleles/gleichzeitiges Öffnen von Formularen? (Also Rechnungen von Huber, Stammdaten von Meier, die Artikelstammdaten, dazwischen noch die Telefonliste und eine Statistik weil der Chef sie gerade braucht.)

Fragen über Fragen, und noch keine einzige Codezeile geschrieben
Um so etwas halbwegs im Zaum zu halten, versuche ich ressourcenschonend zu arbeiten, ohne aber das letzte Quentchen rauszuholen.
Alleine die Frage der Benutzerverwaltung/Steuerung/Rechte und des Lockings im Mehrbenutzerbetrieb kann einem schonmal einige schlaflose Nächte bescheren

[Joh]

Wie groß ist diese Hand, die da voll Benutzer ist?

Meine Klientel sind eher sowas wie Handwerksbetriebe.
meist 1-5; an den meisten Tagen eher 1-2.

Wieviele Formulare mit eigener Connection existieren pro User gleichzeitig?

10-15, davon meistens so 5-6 gleichzeitig geöffnet.

Wie klein ist der Server ?

Ein Standard-PC; teilweise auch der Rechner im LAN, der eh am meisten läuft; also dann die Datenbank lokal

Was ist sonst noch im Lan los?

nix wildes; der allgemeine Wahnsinn: surfen, mailen, Telefonie, scannen, Windows-Updates...

Erlaubst du paralleles/gleichzeitiges Öffnen von Formularen? (Also Rechnungen von Huber, Stammdaten von Meier, die Artikelstammdaten, dazwischen noch die Telefonliste und eine Statistik weil der Chef sie gerade braucht.)

genau so; Telefon klingelt, dann noch mal eben hier geguckt und geändert, Kommentare hinzugefügt. Dann da weitermachen...

Fragen über Fragen, und noch keine einzige Codezeile geschrieben
Um so etwas halbwegs im Zaum zu halten, versuche ich ressourcenschonend zu arbeiten, ohne aber das letzte Quentchen rauszuholen.
Alleine die Frage der Benutzerverwaltung/Steuerung/Rechte und des Lockings im Mehrbenutzerbetrieb kann einem schonmal einige schlaflose Nächte bescheren

Und die Freude, wenn man endlich herausgefunden hat, wie der Kunde es alle 6 Wochen geschafft hat, den Artikel mit der ID 0 anzulegen.

[Joh]

Da bin ich etwas anderer Meinung. Bei der Anlage eines "Dokuments" (also z.B. Auftrag, Rechnung, Gutschrift, Lieferscheine et al.) speichere ich jede Benutzereingabe sofort in der Datenbank, allerdings immer als "Entwurf". Damit kann ein Benutzer auch immer auf seine Arbeit zugreifen. Laufende Rechnungsnummern werden immer dann vergeben, wenn ein Benutzer einen Entwurf finalisiert, was eine getrennte Benutzeraktion ist, die dann nicht mehr rückgängig gemacht werden kann

Ist aber eher ein Ansatz für Firmenstrukturen, bei denen die Arbeitsplätze gewechselt werden; nicht für Kleinbetriebe

[charlytango]

Ist aber eher ein Ansatz für Firmenstrukturen, bei denen die Arbeitsplätze gewechselt werden; nicht für Kleinbetriebe

Da bin ich anderer Meinung. Gerade Kleinbetriebe brauchen bessere und intelligentere Software, die hilft, Fehler zu vermeiden und trotzdem das Pensum eines Mittelbetriebs mit einer personellen Mindestausstattung leicht schaffen.

wie der Kunde es alle 6 Wochen geschafft hat, den Artikel mit der ID 0 anzulegen

Wenn so etwas möglich ist, dann stimmt das Design nicht oder das Programm ist fehlerhaft. Es darf einfach nicht passieren können, was lt. DB-Design nicht sein darf. Im allerschlimmsten Fall verhindern das Constraints in der DB (die ich übrigens zu vermeiden suche, wie weitgehend alle Sprach- und serverspezifischen Funktionen). IDs (also Primary Keys einer Tabelle) werden bei mir immer automatisiert vergeben und haben sprechende Namen (z.B ID_Rechnung, ID_Kunde, ID_Person oder so ähnlich) damit die Logik der DB auch ohne Doku schneller zu durchschauen ist.

Der Vorteil von einer Entwurfslogik ist, dass du immer mit dem gleichen Formular gegen die DB kennst und musst keine Klimmzüge mit einfachen Edit-Feldern machen, sondern kannst DB-Sensitive Controls verwenden. Das hält dir schonmal einen Haufen Tipparbeit vom Hals.

Und wenn der Benutzer mit der Eingabe fertig ist wird der "Rechnungsentwurf" in eine echte Rechnung umgewandelt. Das ist bei mir einfach das entfernen des "Entwurfsmarkers" in der DB. Der besteht dann natürlich aus Datum/Zeit der Umwandlung und welcher User es war. Gleichzeitig werden dann alle Rechnungsnummern automatisch vergeben und alle Abschlussarbeiten für eine Rechnung erledigt.
So eine Strategie hat auch Vorteile wenn Lieferungen und Leistungen über einen Zeitraum in einer Rechnung (also dem Entwurf dazu) gesammelt und gebündelt werden sollen, bis die Rechnung ausgeschickt wird. -- wenn du das diskutieren möchtest, dann vielleicht als PM oder in einem eigenen Thread, das geht über das Thema hier weit hinaus

[fliegermichl]

Aufgrund meiner Erfahrungen mit ZEOS 8.0 empfehle ich erst einen Test mit Lazarus 3.4 zu machen.

Bei mir wird das Datenmodul vor allen Formularen und auch vor dem Hauptformular erzeugt

Machst du das manuell über über die Reihenfolge der Auto-Create-Forms ?

Der Befehl zur Verbindung mit der Datenbank ist

Code: Alles auswählen

TZConnection.Connect

Wenn du Interesse an einem Beispielframework hast, findest du es hier
Es ist so gebaut dass man sehr leicht eine Verschlüsselung beim Schreiben/Lesen des INI Files einbauen kann, dann hast du das Problem des Klartextpassworts vom Tisch.

Kennt jemand das Problem? Was mache ich hier falsch?

Hier spielen einfach einige Strategien zusammen und oft auch gegeneinander.
Beginnend von Erstellungsreihenfolge von Objekten (automatisch oder manuell) über Art und Weise von Datenbankzugriff und Problemen mit unterschiedlichen Komponentenversionen.
Ohne mehr Einblick in die Applikation ist es schwer einen Tip zu geben

@CharlyTango
Zunächst einmal vielen Dank für das erstellen des Frameworks.
Ich habe bislang noch keine Datenbankanwendung mit Lazarus erstellt und war dabei mir Informationen einzusammeln, wie ich diese am besten aufbaue.
Wenn ich dein Repository clone, das Beispielprojekt öffne, dann lässt sich dieses auch compilieren.
Beim Start erscheinen aber Fehlermeldungen bezüglich einer fehlenden ini Datei ohne weitere Angaben, was jetzt zu tun ist.

Könntest du die Readme.txt um diese Anweisungen ergänzen?

Edit: Sorry, wer lesen kann ist klar im Vorteil. Das Programm meckert, daß es die sqlite3.dll nicht öffnen kann. Schande über mich.

[charlytango]

kein Problem -- in dieser Falle steckten wir alle schon mindestens einmal

Falls du detaillierte Fragen hast kannst du dich gerne an mich wenden.

Vom Datenbankzugriffsmodul gibt es mittlerweile auch eine neuere Version die gar kein Datenmodul mehr benutzt sondern nur mehr in einer Unit daheim ist und alle Objekte selbst erstellt.
Die ist dann auch per Compileswitch zum Umschalten zwischen SQLDB und ZEOS fähig.

In dem Framework habe ich ein Datenmodul zu besseren Anschaulichkeit und Einsatzfähigkeit in Beispielprogrammen benutzt. Da ist imho deutlicher was passiert und es lässt sich für ein simples Beispiel leicht integrieren.

Real verwende ich keine Datenmodule für den DB-Zugriff weil ich damit immer wieder Probleme mit der Vererbung hatte (aber das lag sicherlich auch an mir)

Das ist lästig wenn man dem Zugrifsmodul für eine bestimmte Anwendung noch zusätzliche Fähigkeiten verleihen möchte. Außerdem mag ich es, wenn ich die Kontrolle habe, wann welches Objekt nun erstellt wird.

Und nachdem ich auch im Frontend keinen DB-Zugriff aktiv habe, ist das kein Problem

[fliegermichl]

Ich hatte vor einigen Jahren mal eine Android App mit Android Studio erstellt.
Da gibt es eine Klasse SQLiteOpenHelper.

Diese hat einige sehr nützliche Methoden, welche man in der Anwendung überschreiben muss. So. z.B.
onCreate - wird aufgerufen, wenn die Datenbank geöffnet werden soll aber noch nicht existiert.
OnUpgrade(VersionOld, VersionNew : integer) wird aufgerufen, wenn die Datenbank zwar existiert aber in einer älteren Version.
und noch einiges mehr.

Ich werde mir wohl so etwas ähnliches auch für meine Anwendung machen.
Jede Tabelle bekommt dann auch eine entsprechende Klasseninstanz mit eigenen Methoden für Beziehungen zu anderen Tabellen, Einfüge und Updatefunktionen usw..

So spare ich mir die Arbeit, mich in ein umfangreiches Framework einarbeiten zu müssen und hab trotzdem hundertprozentigen Durchblick was so alles passiert.

[charlytango]

Na ja, was da passiert ist jetzt keine Atomphysik und im Kern nicht umfangreich.

Zugriffsobjekte erzeugen, Parameter setzen, Datenbankverbindung öffnen
.
Der ganze Rest ist der bequemen Bedienung und dem Logging geschuldet.

Ich werde mir wohl so etwas ähnliches auch für meine Anwendung machen.
Jede Tabelle bekommt dann auch eine entsprechende Klasseninstanz mit eigenen Methoden für Beziehungen zu anderen Tabellen, Einfüge und Updatefunktionen usw..

Na ja, das sind ganze 3 Prozeduren von denen OnOpen, OnCreate ohnedies in einer Form inkludiert sind und OnUpdate quasi vorbereitet ist (indem eine Versionsnummer schon vorbereitet ist.)

Das Framework ist gedacht um schnell Beispiele für SQL-Datenbanken zu entwerfen, die man leicht zwischen unterschiedlichen Datenbanken umschalten kann. Weil ich mich bei den diversen Beispielen immer geärgert habe dass ich auf die DB, die dazu nötig ist eben gerade nicht irgend einen Zugriff hatte.

Viele Wege führen zum Ziel, aber für jede Tabelle eigene Methoden zu schreiben klingt mir etwas aufwendig, meine Applikationen bewegen sich schnell mal im zweistelligen oder dreistelligen Bereich von Tabellen.
Außerdem würdest du damit quasi den SQL-Server nachprogrammieren, denn der kann bereits alle Fähigkeiten die zur Tabellenmanipulation und zur referential integrity nötig sind.

Da meine Programme gegen unterschiedliche Servertypen liefen, habe ich meistens auf RI verzichtet und quasi im Programm darauf geachtet und den Schlüsselfeldern durchgängig sprechende Namen gegeben

[Maddias]

Dann bleibe ich doch lieber bei den formulargebundenen Connections / Transaktionen.
Dann habe ich formularlokale Transaktionen und kann weiter mit den DBObjekten arbeiten.

Hallo Joh,

für mich steht fest: Keine Software-Entwicklung ohne automatisierte Testfälle. Das geht sowohl mit FPCUnit als auch mit FPTest.

Formulare sind da zum Testen absolut ungeeignet. Deswegen packe ich soviel wie möglich in Datenmodule. Ein Beispiel dafür findest Du auf BitBucket unter meiner öffentlichen Repository hier.

Ziel muß sein die Formulare "so dumm wie möglich" zu halten und Geschäftslogik anderweitig zu implementieren.

Salut,
Mathias