AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Delphi Datendefinition der DB im Programm prüfen
Thema durchsuchen
Ansicht
Themen-Optionen

Datendefinition der DB im Programm prüfen

Ein Thema von Hobbycoder · begonnen am 8. Sep 2018 · letzter Beitrag vom 10. Sep 2018
 
Hobbycoder

Registriert seit: 22. Feb 2017
1.002 Beiträge
 
#21

AW: Datendefinition der DB im Programm prüfen

  Alt 10. Sep 2018, 10:35
Der Threadersteller hat das Knowhow, um die Ideen selbständig zu analysieren und die für seinen Belange beste Kombination daraus zu erstellen.
Ist sicherlich deutlich effektiver als sich über eventuell bestehende Fehermöglichkeiten und / oder Schwachstellen zu streiten.
Hat er

Ihr habt mir einige Anregungen gegeben, die ich mir alle angesehen habe.

Stand zur Zeit:
Ich möchte keine weiteres Tools einsetzen, deshalb mache ich dann doch alles selber. Auch wenn diese Tools durchaus gut sind und mit Sicherheit vieles auch noch besser machen, als ich, so geht das doch oft über meine Anforderungen hinaus, bzw. verursacht weitere Kosten, die ich vermeiden kann.

In einer Tabelle lege ich mir die Version der DB an (der Einfachheit halber nutze ich dafür die Programmversion, warum erzähle ich später).
Beim Programmstart wird auf DB-Version<Programmversion geprüft. Ist diese größer, so wird die Datenbank überprüft. Ich prüfe jede Tabelle und jedes Feld. Dazu habe ich mir eine Klasse geschrieben, die alle Tabellen und Felddefinitionen enthält, diese validieren kann und auch die gewünschten Operationen durchführen kann.
(Löschen von Tabellen oder Feldern wird mit Sicherheit eine Ausnahme bleiben, und wahrscheinlich nur zwei, drei mal, wenn überhaupt, vorkommen. Und bei Änderungen wird es auch nur mal eine Feldvergrößerung sein)

Weiterhin hat die Klasse die Möglichkeit in Abhängigkeit von Operationen oder bestimmten Versionsnummern auch SQL-Scripte auszuführen.
Somit sind da doch all meine Anforderungen erfüllt.

Zum Thema "an mehreren Clients updates gleichzeitig". Nun, das sollte ja logisch sein, dass man sowas berücksichtigen muss. Aber auch dort habe ich keine Bedenken.
Da sich die Clients in einer Benutzertabelle anmelden müssen, wird natürlich als erstes geprüft, ob andere Clients angemeldet sind. Ist dies der Fall werden diese Benachrichtigt und gewartet, bis alle Clients sich ordnungsgemäß abgemeldet haben. Erst dann kann das DB-Update gestartet werden. Dann wird natürlich auch ein Updateflag in die DB geschrieben, welches eine später Anmeldung während des Update-Vorgangs verhindert.
Somit sollte sichergestellt sein, dass kein Client mehr aktiv mit der DB arbeitet.

Sicherlich hat mein Konzept Lücken und auch Schwachpunkte. Aber ich denke ich kann damit sehr gut leben.
Das wichtigste ist vorab umgesetzt: Die Sicherung der kompletten Datenbank

Achja, warum nehme ich die Programmvesion als Datenbankversion.
Das Programm wird nur ca. alle 3 Monate als Update ausgeliefert. Eine der häufigsten Änderung ist in den erstellen Indizes, da für neue Berechnungen weiter Indizes hinzukommen. Deshalb lasse ich die DB in dem Zuge auch gleich überprüfen, was das Neuerstellen der Indizes beinhaltet. Somit brauch ich keine weitere Versionsnummer. (innerhalb der Entwicklung löse ich das anders).
Gruß Hobbycoder
Alle sagten: "Das geht nicht.". Dann kam einer, der wusste das nicht, und hat's einfach gemacht.

Geändert von Hobbycoder (10. Sep 2018 um 10:40 Uhr)
  Mit Zitat antworten Zitat
 


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 17:33 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz