Datenbankkomponenten - Verbindung immer offen!

[Mavarik]

Hallo Zusammen!

Ich habe bisher immer mit meiner eigenen ISAM und eigenen ISAMEdit auf Datenbanken zugegriffen..

Ein geladener Datensatz wurde in die Edit/Maskedit/Comboboxen usw. übertragen und war dann
statisch verfügbar, auch wenn die Datenbank schon lange geschlossen war...

Das geht ja leider nicht mit den DBEdit's usw... Auch muss eine Datenbank immer im Edit-Modus stehen
damit die Felder bearbeitet werden können...

Ein Kundenauftrag erfordert jetzt leider diese Art des Datenzugriffes... Da es mein ersten Programm
mit permanent offenen Datenbanken ist, habe ich einige Fragen:

Wann öffnent und schließt Ihr die Datenbank? Besonders, wenn zwischen mehreren Programmteilen hin und
her gesprungen werden kann? Beispiel: Adresseingabe -> Textverarbeitung -> Kalender -> Adresseingaben
Der Datensatz sollte ja erhalten bleiben...

Benutzt Ihr eine 2. Temp-Verbindung für Suchfunktionen z.B. um eine andere Adresse in einen Brief einzufügen,
wenn eine Adresse schon im Edit-Modus ist?

Öffnet und schließt Ihr "nur" die Datenbank oder löscht und Connected Ihr auch immer den Server?

Wie sieht es aus bei Multiuser Betrieb? Beim speichern einer Adresse, sollte ja überprüft werden,
ob ein anderer Arbeitsplatz die Adresse ggf. in der Zwischenzeit geändert hat. Hier wäre ja wieder eine
Temp-Verbindung nötig?


Es geht mit nicht darum, dass ich nicht weiss, wie es geht, sondern "lediglich" um Tipps das ganze Praktikabel
zu lösen...

Grüsse Frank :coder:

[mkinzler]

Warum ist die geöffnete Verbindung ein Problem?
Schon eine Mehr-Ebenen-Architektur gedacht (Multi-Tier)?

[Elvis]

Zitat:

Zitat von mkinzler

Warum ist die geöffnete Verbindung ein Problem?
Schon eine Mehr-Ebenen-Architektur gedacht (Multi-Tier)?

Ganz genau.
IMHO ab D6 ist das ClientdataSet bereits in der Professional enthalten.
Und IMHO sollten bei BDS2006 Pro die Client komponenten für Data Snap enthalten sein.
Es sollte also eine BDS Enterprise reichen um den Server zu schreiben, aber Pro SKUs sind ausreichend für den Client.
Vorausgesetzt dass keine Zusatzkomponenten wie kbmMW oder RemObjects SDK/Data Abstract benutzt werden sollen. (Wobei beide Systeme es seeehr viel einfacher machen wirklich sichere, internet fähige Application server zu bauen :) )
Selbst in simplen Client/Server Designs lässt sich das ClientDataset sehr einfach in Verbindung mit dbExpress benutzen. (Auch in der Pro)

[Mavarik]

Hallo!

Zitat:

Zitat von mkinzler

Warum ist die geöffnete Verbindung ein Problem?

Nein eigentlich nicht... Ich hatte nur ein Timeout-Problem mit dem SQL Server, aber das habe ich gelößt...
Es ist nur ungewohnt immer nur einen Datensatz bearbeiten zu können...

Sonst habe ich eben

Delphi-Quellcode:

  Blockread(f,Alter_datensatz,Sizeof(Adresse));
  Blockread(f,Neuer_datensatz,Sizeof(Adresse));

Das war irgendwie einfacher... :zwinker:

Zitat:

Zitat von mkinzler

Schon eine Mehr-Ebenen-Architektur gedacht (Multi-Tier)?

Kannst Du den Vorteil bzw. das Verfahren in 3 Sätzen erläutern?

Frank :coder:

[hsg]

Mag sein, dass ich so kurz vor Feierabend das Problem nicht so ganz richtig verstanden habe, falls dem so ist: ignoriert meine Antwort :-D

Ich habe bei mir in der Applikation außer DBGrids keine Datensensitiven Felder, das Füllen der entsprechenden Eingabemasken mache ich per Hand und auch das Schreiben in die Datenbank wird von Hand erledigt. Damit können bei mir die Datenbanken im Hintergrund ruhig geschlossen werden, die entsprechenden Informationen würden immer noch angezeigt. Zudem habe ich für jedes Fenster eine (oder ggf mehrere) eigene Instanz der notwendigen Datenmodule. D.h. meine Such-Fenster sind vollkommen unabhängig von den Eingabe-Fenstern. Soll ein entsprechender Datensatz aus der Suche bearbeitet werden, wird das Eingabe-Fenster geöffnet, die entsprechenden Datenbanken (TTable.GotoCurrent) und laufen von dann an wieder unabhängig voneinander.

Die einzigen Datenbank-Elemente die global für alle Tabellen sind, sind bei mir die Connections zur Datenbank. Diese sind auch nicht in den Datenmodulen hinterlegt, sondern in einem global verfügbaren Datenmodul. Die anderen Datenmodule greifen dann auf dieses Datenmodul zu. Damit halte ich die Anzahl der Connections klein, spare die Zeit für den Verbindungsaufbau (geschieht beim Start der Applikation und endet erst mit Beenden der Applikation).

Achso: verwende die Komponenten und Datenbank-Server von Advantage Database Server. Dort sind Connections und Tables bzw. Querys getrennte Komponenten)

[Mavarik]

Zitat:

Zitat von hsg

Ich habe bei mir in der Applikation außer DBGrids keine Datensensitiven Felder, das Füllen der entsprechenden Eingabemasken mache ich per Hand und auch das Schreiben in die Datenbank wird von Hand erledigt. Damit können bei mir die Datenbanken im Hintergrund ruhig geschlossen werden, die entsprechenden Informationen würden immer noch angezeigt.

Ja so habe ich es früher auch gemacht...

Das war nicht die Frage, trotzdem Danke

Frank :coder:

[mkinzler]

Zitat:

Kannst Du den Vorteil bzw. das Verfahren in 3 Sätzen erläutern?

Der Vorteil von Middleware ist das keine direkte Verbindung des Client zum Server bestehen muß. Der Client puffert dann den Inhalt und stellt bei Bedarf die Verbindung wieder her. Es können so auch mehr virtuelle Verbindungen als physikalische aufgebaut werden. Verbindungspooling

[Udontknow]

Zitat:

Zitat von mkinzler

Zitat:

Kannst Du den Vorteil bzw. das Verfahren in 3 Sätzen erläutern?

Der Vorteil von Middleware ist das keine direkte Verbindung des Client zum Server bestehen muß. Der Client puffert dann den Inhalt und stellt bei Bedarf die Verbindung wieder her. Es können so auch mehr virtuelle Verbindungen als physikalische aufgebaut werden. Verbindungspooling

Mit Server ist der DB-Server gemeint, die Verbindung zum Midas-Appserver, der die Zwischenschicht darstellt, bleibt natürlich bestehen... ;-)

Für die "normalen" zweischichtigen Anwendungen nutze ich übrigens immer die Simpledatasets, die Clientdataset, Datasetprovider und SQLDataset kapseln.

Cu,
Udontknow

[Mavarik]

Hallo!

Ja ok aber darum geht es doch nicht...

Ob ich zum "zwischen" Server oder direkt zum MySQL Server verbinde macht für mich keinen Unterschied,
abgesehen davon, dass ich noch einen Vermittlungsstelle habe, die wieder Rechenzeit benötigt...

Es ging mir doch um mein Lokales Programm...

Grüsse Frank

[Udontknow]

Da habe ich mich ungeschickt ausgedrückt...

Sobald Daten in einem Clientdataset oder in einem Simpledataset enthalten sind, kann man die Connection schliessen und trotzdem noch mit den Daten arbeiten (z.b. anzeigen, ändern, einfügen und löschen).
Um die vorgenommenen Änderungen dann wieder in die DB eintragen zu lassen, ruft man die Methode ApplyUpdates auf, in der dann bei Bedarf die Connection wiederhergestellt wird und die Änderungen übernommen werden.

Cu,
Udontknow