Best Practice MVC und große Datenmengen aus einer mySQL - Datenbank

[SignIn]

Hallo zusammen,

ich entwickle derzeit ein Frontend zu einer Mysql-Datenbank. Mit kleinen Datenmengen klappt das auch schon gut.
Die Datenbank enthält z.B. eine Tabelle Geräte (mti deren Eigenschaften). Es gibt keine Duplikate, Name, Größe und Einheit sind unique.
In meinem Model habe ich eine LinkedList mit Geräte-Objekten (Interface), die ich aus der Datenbank gelesen habe - und zwar komplett. Auf der View schmeisse ich meine Liste über ein TableModel in eine JTable (die selbst in einer ScrollPane liegt).
Momentan läuft der mySql-Server lokal, soll aber später im LAN laufen.
Der Nutzer soll die Geräte verändern, löschen können und neu einfügen natürlich.
Meine Frage ist jetzt, was passiert, wenn ich 10000 Datensätze (Geräte aus der Datenbank lese) und in meinem Model als Linked-List mit Objekten (mit Interfaces) verwalte und dann auch noch in eine JTable schmeisse ...
Bricht mein Programm performance-technisch dann zusammen ?

Wie programmiert man sowas denn am besten ? (ich möchte kein Hibernate etc. verwenden) ...

Vielen Dank.

SignIn

 

[Joose]

Meine Frage ist jetzt, was passiert, wenn ich 10000 Datensätze (Geräte aus der Datenbank lese) und in meinem Model als Linked-List mit Objekten (mit Interfaces) verwalte und dann auch noch in eine JTable schmeisse ...
Bricht mein Programm performance-technisch dann zusammen ?

Du könntest dir natürlich einfache Dummy Daten generieren lassen und es einfach mal testen.
Aber bei 20000 Objekten sollte es eigentlich noch keine Probleme geben (kommt auch immer auf das Objekt selbst an).

Ich würde nicht einfach alles aus der DB lesen wenn ich die Liste anzeigen will. Die Liste bzw. dein Bildschirm hat nicht genug PLatz um alle 10000 Geräte Einträge gleichzeitig anzuzeigen.
Hier wäre es von Vorteil dynamisch immer wieder Blöcke nachzuladen.

Wie programmiert man sowas denn am besten ? (ich möchte kein Hibernate etc. verwenden) ...

Das DAO Pattern wäre eine Möglichkeit.

 

[SignIn]

Danke Joose,

Ich würde nicht einfach alles aus der DB lesen wenn ich die Liste anzeigen will. Die Liste bzw. dein Bildschirm hat nicht genug PLatz um alle 10000 Geräte Einträge gleichzeitig anzuzeigen.
Hier wäre es von Vorteil dynamisch immer wieder Blöcke nachzuladen.

Das Frontend ist nach dem MVC realisiert. Ich habe quasi eine Modelklasse, die eine Liste der Gerätschaften beispiesweise hält (also Objekte der Klasse Geraet). Wenn ich jetzt komplette alle Daten aus der Datenbank hole und sie als Gerät in die Liste im Modell speicher, dann ist wohl ziemlich schnell der Hauptspeicher voll und das Programm wird zusehends langsamer ? Die View also die Tabelle greift dann auf das Modell zu und holt sich die Daten von da ...

wenn ich jetzt die Daten dynamisch nachlade, müsste ich ja wissen, was ich nachladen muss, also welche Datensätze. Da der mySQL - Server ja später im LAN laufen soll und es mehrere Clients gibt, die in der Zwischenzeit schon wieder was in die Datenbank geschrieben haben könnten. (hätte noch so die Idee einen Timpstamp zu speichern, um bei einem Reload nur die Veränderten zu laden, dann müssten aber alle Rechner, die daran beteiligt sind, synchron laufen).

Für jedes Entity in der Datenbank exisitert natürlich eine ID und man könnte nur die darauffolgenden Datensätze nachladen. Das mache ich dann, wenn der Nutzer nach unten scrollt in meiner JTable? Dann wird das Scrollen schleppend oder ?
Oder was mache ich, wenn ich eine Suchfunktion integrieren will und die Hälfte der Daten noch gar nicht geladen sind, weil noch in der Datenbank ?

Fragen über Fragen und sehr viel Verständnisproblem .... :bahnhof:

Vielen Dank.

SignIn

 

[Joose]

Das Frontend ist nach dem MVC realisiert. Ich habe quasi eine Modelklasse, die eine Liste der Gerätschaften beispiesweise hält (also Objekte der Klasse Geraet). Wenn ich jetzt komplette alle Daten aus der Datenbank hole und sie als Gerät in die Liste im Modell speicher, dann ist wohl ziemlich schnell der Hauptspeicher voll und das Programm wird zusehends langsamer ? Die View also die Tabelle greift dann auf das Modell zu und holt sich die Daten von da ...

Wie gesagt "Sachen" die man nicht sehen kann und nicht braucht sollten auch nur bedingt im Speicher herumliegen.
Aber es kommt natürlich auf die Menge und Größe der Objekte an ob es wirklich dann zu einem Performance Einbruch kommt. Solange man nicht wirklich mit mehreren Millionen Objekten handiert sollt es eigentlich machbar sein.

Generell muss man hier von Programm zu Programm schauen was genau benötigt wird etc.

wenn ich jetzt die Daten dynamisch nachlade, müsste ich ja wissen, was ich nachladen muss, also welche Datensätze. Da der mySQL - Server ja später im LAN laufen soll und es mehrere Clients gibt, die in der Zwischenzeit schon wieder was in die Datenbank geschrieben haben könnten. (hätte noch so die Idee einen Timpstamp zu speichern, um bei einem Reload nur die Veränderten zu laden, dann müssten aber alle Rechner, die daran beteiligt sind, synchron laufen).

Für sowas wäre es praktisch eine Server Applikation zu basteln über welche sich der Client die Daten holt.
Einerseits ist die DB so nicht von außen ansprechbar, der Server kann das Schreiben/Lesen/Bearbeiten von gleichen Datensätzen etwas handeln. Und ein Server hat normal etwas mehr Arbeitsspeicher da sollten sich mehr Objekte im Speicher ausgehen.

Für jedes Entity in der Datenbank exisitert natürlich eine ID und man könnte nur die darauffolgenden Datensätze nachladen. Das mache ich dann, wenn der Nutzer nach unten scrollt in meiner JTable? Dann wird das Scrollen schleppend oder ?

(Annahme es kommt zu Performanceproblemen weil ich zuviele Objekte gleichzeitig lade)
Beispiel: Deine Applikation kann 10 Datensätze gleichzeitig anzeigen, im Speicher könnte man dann zum Beispiel 30 halten (10 vor und nach dem angezeigten Block). Wenn man nun scrollt ladet man im Hintergrund entsprechend nach (hier kann es vielleicht zu einem "Stocken" kommen).


Aber schreibe einfach mal das Programm so wie es machen würdest und denke nicht viel über die Performance Probleme nach. Es sollte mal eine lauffähige Version geben, wo man dann immer noch schauen kann:
Wo bleibt wirklich die Zeit liegen, sind zu viele Objekte im Speicher? Wo könnte ich Caches oder ähnliches verwenden.

 

[Thallius]

Ich würde niemals eine Table machen die mehr als vielleicht 100 Einträge hat. Wer soll sich denn durch eine 10000 Einträge Table durchscrollen? Ab 100 Einträgen würde ich anfangen zu pagen.

Gruß

Claus

 

[SignIn]

Danke für Eure Antworten

Aber schreibe einfach mal das Programm so wie es machen würdest und denke nicht viel über die Performance Probleme nach.

Das Programm läuft schon, zumindest mit den Haupttabellen. Momentan ist es so realisiert, dass wenn der Nutzer im Menü den Punkt Geräteliste anklickt, dann die komplette Geräteliste aus der Datenbank geholt wird und in einer Tabelle angezeigt werden.

Selbst einen Server schreiben (wegen der Timestamps) wollte ich nicht. So sicher bin ich da nicht und ich möchte nicht mehr Sicherheitsprobleme schaffen. Außerdem haben die Admins in unserer Schule was dagegen

Das Pagen wäre eine Möglichkeit ... in Webapplikationen sagt man dann 1-30 etc ... finde ich aber in meinem Fall nicht so günstig. Dann schon eher nach Buchstaben, wobei man nie weiß, wie viel Einträge da wo vorhanden sind ....
Also doch lieber scrollen: Ich wollte noch ein Textfeld als Eingabefeld machen, in dem der Nutzer die ersten Buchstaben des gesuchten Gerätes eingibt und die Tabelle dynamisch ihre Einträge anpasst ... in Echtzeit natürlich ... das wäre bei ständigem Nachladen von Daten ziemlich blöd .... aber wahrscheinlich kann man nicht alles haben ???:L

:rtfm:

Gruß, SignIn

 

[Thallius]

Danke für Eure Antworten

in Echtzeit natürlich ... das wäre bei ständigem Nachladen von Daten ziemlich blöd .... aber wahrscheinlich kann man nicht alles haben ???:L

:rtfm:

Gruß, SignIn

Nein genau das wäre sehr einfach indem man einfach entsprechend die DB Funktionalität nutzt und den Query definiert.

Du brauchst keine Datenbank wenn du die Daten eh immer alle lädst. Dann kannst du die auch in einer XML speichern. Aussedem bekommst du Änderungen in Deiner DB von anderen Clients so niemals mit nur bei erneutem Programmstart. Ich finde diese Lösung nicht besonders gelungen.

Gruß

Claus

 

[SignIn]

Na, ich habe schon eine Reloadfunktion (und hatte die Idee des Timestamps, die aber auch nicht so gut war)... aber wie eben angesprochen, ist das nicht sonderlich performant. Wenn Du die Daten nur teilweise aus der Datenbank lädst und dann bei einem scroll die z.B. 30 Objekte verwirfst und wieder 30 Objekte lädst, wie willst du eine Echtzeitsuche über alle Daten machen, die auf Tastendruck des Nutzers reagiert ... (also wenn er z.B. B eingibt dann alle Geräte mit B anzeigt und dann ein 'e' eingibt, eben alle Bechergläser anzeigt ..... ) etc .... das würde doch nur funktionieren, wenn die Daten schon da sind auf dem Rechner ..... (der Datenbank-Server befindet sich auf einem anderen Rechner im LAN)

 

[Thallius]

So mit Datenbanken hast du dich noch nicht wirklich beschäftigt oder?

Der Sinn einer DB ist es ja gerade nur die benötigten Daten zu liefern. Dazu gehört natürlich auch und vor allem die Daten schon vorm Übertragen zu selektieren. Willst Du also nur die Geräte mit B, dann fragst du bei der DB natürlich auch nur die Geräte mit B an und nicht alle um dann selber die mit B heruaszufiltern. Ist Deine Ergebnissmenge überschaubar groß, dann ist das Übertragen der Daten auch in Echtzeit möglich. Klar, wenn du 30000 Geräte von der DB abfragst, dann wird das Ganze Übertragen der Daten zum Nadelöhr. In Deinem Fall bedeutet das beim Programmstart und bei jedem Refresh wartet der User eben bis alle Daten da sind. Dummerweise wartet der User aber nur, weil Du alle Daten lädst und das obwohl den User mit grosser Wahrscheinlichkeit nur 1% davon interessiert.

Also überleg doch mal. Der User kann maximal 20 vielleicht 30 oder wenn er einen super grossen Montor hat 100 Zeilen gleichzeitig sehen. Da lädst aber 30000 Zeilen. Warum? Wem bringt das was, ausser das du es leichter beim Programmiern hast.

Lade zunächst immer nur die Daten die angezeigt werden. Whähle dazu eine Blockgröße die doppelt so groß ist wie die Anzahl Zeilen die sichtbar sind. Wenn dann das Scrollen ruckelt, dann fängst du an zu optimieren indem Du einen kleine Cache einbaust, der schonmal die nächsten Zeilen vorlädt etc.

Wird ein Filter angegeben, dann rufe in der DB auch nur die Daten ab die auf den Filter zutreffen.

Du must die Daten überhaupt nicht lokal halten. Es reicht, wenn das TableModell sich immer die richtigen Daten vom Server holt wenn er sie braucht. Damit hast du auch automatisch einen Refresh drin.

Gruß

Claus

 

[SignIn]

Wem bringt das was, ausser das du es leichter beim Programmiern hast.

Ja, as stimmt ... danke Dir. Werde am Wochenende mal sehen, ob ich das so hinbekomme. Muss dann halt mein Model umprogrammieren. Mein TableModel arbeitet mit meinem Model ....

Da hab ich z.B. Lagerorte, die Geräte enthalten. Das könnten dann Objekte sein, die zwar in der DB stehen, aber nicht in meiner Geräteliste im Model vorhanden sind. Mal sehen, das muss ich mir nochmal genauer ansehen.

Bis dahin, danke erstmal.

Gruß, SignIn

Edit: mit Datenbanken hab ich mich schon beschäftigt und ich weiß, dass ich die SQL-Statementes so anpassen kann, dass ich selektiere ;-)

 

[Joose]

Muss dann halt mein Model umprogrammieren.

Hat nichts mit dem eigentlichen Problem zu tun:

Wenn du für diese Änderung dein Model wirklich ändern musst hast du einen kleinen Designfehler
Das Model sollte nur die Daten halten, welche Daten geladen werden bzw. vom Model gehalten werden sollte ein Controller entscheiden.

 

[SignIn]

Hm. Ok.

Die Controller sind bei mir Listener, die auf Ereignisse der Oberfläche reagieren. Sie halten eine Referenz auf die View und das Model. Das Model enthält schon nur die Daten, stellt aber auch die Verbindung zur Datenbank her. Es ist ein Observable. Ändert sich was am Model, werden die Observer (View) benachrichtigt.
Im Model gibt es eine LinkedList mit Geräten, einen Raum, der wiederrum eine Liste mit Lagerorten enthält. Nun kann aber ein Lagerort, wiederum Geräte aufnehmen (am besten einen Zeiger auf ein Gerät in der Gesamtliste der Geräte). Was aber dann nicht mehr gehen würde, wenn nur noch die Geräte gehalten werden, die angezeigt werden. (mal abgesehen davon, dass es keine Zeiger gibt ;-)
So hatte ich mir das ursprünglich vorgestellt.

Und Ihr sagt jetzt, wenn der Nutzer nur die Gerätelist anzeigt, dann stehen im Model auch nur die Gerätelist, die der Nutzer sieht +- 20 Einträge z.B. --> der Rest wird über Bord geworfen (wenn vorher woanders gescrollt wurde). Wenn jetzt ein Nutzer die Lagerorte anzeigen lassen will, läd man die neu (das sind rel. wenig Einträge). Was ist jetzt mit den Geräten, die den Lagerorten in einer LinkedList zugeordnet sind ?

Oje, ich hoffe, ich habe mich verständlich ausgedrückt.

SignIn

Vielen Dank für eure Geduld und Hilfe

 

[Thallius]

Da stelle ich mir die Frage was meinst du mit linkedlist?

Normalerweise müsste doch ein gerät ein Attribut haben in welchem Lager es ist oder nicht? Wozu braucht es da eine linkedlist?

Gruß

Claus

 

[SignIn]

Ich hänge mal einen Ausschnitt des ERM an, den es betrifft.

Es werden verschiedene Lagerorte verwaltet in verschiedenen Räumen.
In den Lagerorten stehen, dann verschiedene Geräte in bestimmter Anzahl.
Um das ERM in einer Klassenstruktur abzubilden, habe ich eben eine Klasse Raum, die eine Liste mit Lagerorten hält und jeder Lagerort eine Liste mit Geräten.

Mein Model sollte also die Geräteliste halten und einzelne Geräte, werden dann bestimmten Lagerorten zugeordnet, wobei die Geräte, die in die Lagerorte eingeräumt wurden, lediglich Referenzen auf die Geräteobjekte in der "globalen" Geräteliste sein sollte. Aber da hatte ich wohl das Model völlig falsch aufgezogen ?

 

[Thallius]

Nein also das DB Model ist gut so. Ich habe noch nicht ganz verstanden wofür die räume sind aber die Beziehung orte zu Geräten über eine Crosstable passt so.

Wenn du jetzt nur Geräte haben willst die in einem bestimmten Raum sind dann geht das über einen JOIN im Query. Das kannst du auch alles mit einer Anfrage abbilden,

Gruß

Claus

 

[SignIn]

Hi Thallius,

ich hänge mal noch das grobe Model (Ausschnitt) dran. Darin soll erkennbar sein, dass ich eine DBClass habe, die die Verbindung zur Datenbank herstellt über JDBC. In meinem Programm kommt der User erst zu einem Login-Dialog, in dem er sich anmelden muss und den Raum auswählt (es können also viele Räume verwaltet werden. So eine Schule ist ja auch groß). Ist das Login erfolgreich, kommt der Nutzer zur eigentlichen Oberfläche und der gewählte Raum wurde im Model gespeichert und wird auch angezeigt.

Nun kann der Nutzer über das Menü z.B. die globale Geräteliste einsehen und Geräte löschen, speichern, verändern. Dazu wird im Model eine LinkedList mit Geraete-Objekten gespeichert (und vorher natürlich aus der Datenbank geladen). Weiterhin kann der Nutzer die Lagerorte in dem Raum einräumen. Also z.B. sagen, der Arbeitsplatz A Fach 1 enthält jetzt Filterpapier, 1 Motor, 4 Weingläser. Deshalb gibt es in einem Objekt von der Klasse Lagerort auch eine LinkedList mit Geräten. Nun dachte ich, ich kann hier nur Referenzen oder Zeiger speichern, die auf das Gerät in der LinkedList im Model verweist.

Das mit der gesamten Geräteliste laden, habe ich mir jedoch nicht richtig überlegt, weil wenn es sehr viele Geräte gibt, bricht mein Programm irgendwann zusammen. Und Geräte sind nicht die einzigsten Objekte, die an solchen Orten lagern.
Also hat mein Model, so wie es jetzt ist ein Problem.

Wenn der Nutzer jetzt also einen Lagerort einräumen will, muss er eine Liste von Geräten haben, die er auswählen kann. Ich kann ihm aber bei entsprechender Anzahl von Geräten nie die ganze Liste präsentieren.

Versteht ihr was ich meine ?

Wie löse ich denn sowas ? Soll ich dem Nutzer erst nach eingabe von Suchwörtern eine Geräteliste präsentieren ?

Thanx.

SignIn

 

[Thallius]

Warum hälst du überhaupt etwas lokal auf dem Client? Diene Datenbankstruktur erlaubt doch alles abzubilden was Du da erzählst. Sprich. Wenn der User sich in einen Raum einloggt, dann holst du mit einem Query die Geräte welche in dem Raum sind. Das dürften ja niemals zu viele sein. Löscht er nun ein Gerät, dann schicke doch auch direkt den Query an die DB das das Gerät nun nicht mehr im Raum ist und mach danach einen neuen Fetch der Daten. Das must du doch nicht erst alles im Speicher halten und dann irgendwann wieder zurück schreiben. Das Gleich gilt für das Ändern oder hinzufügen. Mach für jede Aktion die der User macht eine Datenbankanfrage welche die DB gleich wieder in den richtigen Zustand bringt. Damit wäre Dein Datenmodel nichts anderes als die Datenbank, welche vom Controller nach Daten gefragt wird, bzw die vom Controller geändert wird.

Gruß

Cluaus

 

[SignIn]

Wenn der User sich in einen Raum einloggt, dann holst du mit einem Query die Geräte welche in dem Raum sind.

Die Geräteliste ist ja global und ist eine Liste für alle Räume. Es kann Weingläser in Raum A456 geben und es kann Weingläser in A567 geben. Es kann aber auch sein, dass in Raum B32 keine Weingläser stehen, der Nutzer da aber gerne welche hinstellen würde. Demnach müsste ich dem Nutzer eine Geräteliste präsentieren, wonach er auswählen kann, was für Geräte er jetzt da hineinstellen möchte. Gesamte Anzahl der Geräte laden wäre quatsch. Also ein Suchfeld anlegen und den Nutzer den Namen des Gerätes eintragen lassen und dann die Geräte laden ?

Na ja, das mit dem Model hab ich mal so gelernt. Ich soll also meine Querys schreiben und dann gleich mit den ResultSets und PreparedStatements arbeiten ? Ein ResultSet ist doch auch ein Objekt auf ClientSeite, was die Daten hält.
Was ist dann mit MVC ?


Sorry, wenn ich schwer von Begriff bin. :bahnhof:

 

[Thallius]

Wieso passt doch alles dann.

Natürlich hast du das Resultset. Ohne geht es ja auch nicht

Also im Prinzip sieht dein Konzept jetzt doch schon richtig rund aus. Genauso würde ich es machen. Nur die Geräte des Raumes laden. Wenn der User neue Geräte hinzufügen will, dann geht ja eh ein neues Fenster auf in dem er das Gerät auswählen kann. Das hat wiederum seinen eigenen Controller der bei der DB dann eben alle Geräte anfragt. Hat der User ein Gerät ausgewählt, dann wird es direkt in die DB geschrieben (Also in die Crosstable) und der Raum wird aktualisiert.

Klingt für mich so alles recht schlüssig

Gruß

Claus

 

[SignIn]

dann geht ja eh ein neues Fenster auf in dem er das Gerät auswählen kann.

Derzeit ist es so, dass der Nutzer ins Menü gehen muss, und den Punkt Geräteliste wählen muss. Und DANN erst wird die Geräteliste geladen. Problem: Wenn jetzt 20000 Geräte in der Datenbank gespeichert sind, dann habe ich im Model eine Liste mit 20000 Geraet-Objekten (oder eben ein ResultSet mit 20000 Zeilen). Ich glaube, dass das der Performance meines Programms nicht gut tut.
Mein TableModel arbeitet mit meinem Model, in dem eben diese Liste mit den Geräte-Objekten gespeichert ist. Die ganzen Einträge würden dann in der JTable dargestellt .... wie schon festgestellt, scrollt sich keiner durch 20000 Einträge.

Beim Einräumen der Lagerorte soll es so sein, dass ein neues Fenster aufgeht, in dem der Nutzer die Geräte auswählen kann. Also Fenster geht auf, Controller sagt dem Model, es sollen die Geräte geladen werden und gut. Bliebe trotzdem das Problem mit den 20000 Objekten. Soll ich da eben nur die ersten 100 Laden und bei Scrollereignissen die nächsten Hundert ? Wenn dann bis runter gescrollt ist, hab ich trotzdem 20000 Objekte.
Oder soll ich die ersten 100 laden und bei Scrollen diese hundert verwerfen (und durch den Garbage Collector einsammeln lassen) und die nächsten hundert laden ? Dann hätte ich nur 100 Objekte. Müßte aber beim Zurückscrollen die ersten hundert erneut laden Und das ganze übers Netzwerk ? Der DB-Server steht ja im LAN. Es sollte auch nicht zuviel Traffic entstehen ....

Was haltet ihr für die beste Lösung ?



Daaaaaaaaaaanke für die Geduld .....

 

[SignIn]

Ach ja, die Daten werden vorsortiert aus der DB geholt. Wenn jetzt jemand anders, von einem anderen Rechner ein neues Gerät einträgt, was sich dazwischen schiebt quasi, ist auch doof ..... ich möchte nicht auf Clientseite sortieren, wenn es nicht notwendig ist.

 

[Thallius]

Besteht denn keine Möglichkeit die Geräte zu gruppieren?

Gruß

Claus

 

[SignIn]

Hallo Thallius,

gruppieren scheint mir nicht die richtige Lösung zu sein.
Ich habe nochmal ein wenig nachgelesen und muss eine Annahme von mir revidieren. Ich dachte, das ResultSet besitzt bereits alle Daten von der Datenbank. Dem ist aber nicht so. Es läd auch nur die, die gerade gebraucht werden + eine bestimmte Anzahl, da mit nicht jeder Datensatz einzeln abgefragt werden muss von der Datenbank. Normalerweise iteriert man durch das ResultSet vorwärts.
Ich werde es jetzt so machen, dass ich auch bloß eine bestimmte Anzahl lade, +- eine Anzahl und dann auf Scrollereignisse reagiere. Und den Rest durch den Garbage Collector einsammeln lasse. Damit muss ich aber auch meine Speicherfunktion umschreiben.

Noch eine Frage ist mir eingefallen: wie handhabt ihr das mit der Connection. Haltet ihr eine Verbindung offen bis das Programm beendet wird und schließt dann ? Oder öffnet ihr eine Datenbankverbindung, wenn ihr sie braucht und schließt sie dann wieder und bei der nächsten Anfrage wird neu geöffnet und geschlossen ?

Merci.

SignIn

 

[Thallius]

Soviel ich weis ist das total egal da mySQL mittlerweile den Connect eh cached. Das bedeutet solange der Server läuft und genug RAM da ist bleibt der Connect bestehen und wird beim nächsten Open einfach wieder zurück gegeben.

Gruß

Claus

 

[SignIn]

Vielen Dank. Und wie ist das bei anderen Datenbanken ? Weil meine DBClass auch mit anderen DBMS umgehen kann (hoffe ich )