Zitat von Dejan Vu:

7. Wer schaut sich die 3 Mio Datensätze eigentlich an?
8. Gibt es keine bessere, schnellere, resourcenschonendere Möglichkeit, das, was Du mit den 3 Mio Datensätzen vorhast, zu lösen?

Genau das ist auch für mich das Punkt.
Niemand kann die Daten in einem Grid mit 3 Mio Datensätzen sinnvoll erfassen und nutzen. Es hat daher keinen Sinn, einem Menschen die komplette Datenmenge zu präsentieren. Ergo braucht man sie auch nicht aus der DB abrufen.
Mit ein wenig SQL kannst man dem Benutzer gruppierte und aggregierte Daten liefern, die den kompletten Datenhaushalt der abfragen, aber nur die "Fakten" in den Client transportieren.
Das Gruppieren und Aggregieren kann der SQL Server schnell und problemlos erledigen. Der Client jedoch nicht.

Die Tatsache, dass wir in unserer Anwendung einige Sachen "suboptimal" implementiert haben, war mir auch schon vor diesem Betrag bekannt und dies ist auch nicht mein Thema


Ich habe über Nacht eine Testbankenbank auf unserem MSSQL Server eingespielt mit 12 MIO Datensätzen, d.h. die Aussage Irgend eine 32 Bit Speichergröße geteilt durch die Größe eines Datensatzes ergibt die Anzahl der max. Records kann ich so nicht nachvollziehen.

Zitat:

Die Tatsache, dass wir in unserer Anwendung einige Sachen "suboptimal" implementiert haben, war mir auch schon vor diesem Betrag bekannt und dies ist auch nicht mein Thema

Warum wird das dann nicht geändert?

Zitat:

Ich habe über Nacht eine Testbankenbank auf unserem MSSQL Server eingespielt mit 12 MIO Datensätzen, d.h. die Aussage Irgend eine 32 Bit Speichergröße geteilt durch die Größe eines Datensatzes ergibt die Anzahl der max. Records kann ich so nicht nachvollziehen.

Für das DBMS ist das kein Problem, es ist aber eines wenn man versucht, die 3 (oder 12) MIO Datensätze in ein Grid anzuzeigen.
Dadurch werden die Daten dann (teilweise) redundant im Arbeitsspeicher des Clients gehalten. Vorher verstopfen diese das Netzwerk, da sie ja auch übertragen werden müssen.
Wieviel Hauptspeicher hast du?

der Client hat aktuell 32 GByte Arbeitsspeicher, Win 7 x64 ..... ; Für ~ 1000 Euro könnte ich kurzfristig weiter 64 GByte auf unserem Client nachrüsten und hätte mein Problem für einige Zeit gelöst / nach hinten geschoben;


Kann ich mir mit dieser Strategie "Zeit verschaffen" oder muss ich sofort den Code anpacken?

Das ist egal. Wenn der Client nur 32 Bit ist, dann kann der nunmal standardmäßig nur 2 GB (optional 3, bzw fast 4 GB) verwalten
und das auch, wenn im Rechner real nun 1 GB RAM verbaut sind. (siehe Auslagerungsdatei)


Es gibt aber auch DB-Komponenten und Grids, welche die Daten nicht alle sofort laden müssen, sondern nur einen (relevanten) verschiebbaren Teil,
so daß man in dem Grid dann auch 300 Mio. Datensätze anzeigen könnte, wenn es unbedingt sein muß.
Gut, sowas wie Sortierung und Filterung geht dann im Grid natürlich nicht mehr, da ja nicht alle Daten "aktuell" verfügbar sind.
(Das ist wie beim HxD, welcher, bei Anzeige der des RAM- oder HDD-Inhalts, auch nicht alles lädt, sondern nur den aktuell sichtbaren Bereich)

Zitat von bernhard_LA:

der Client hat aktuell 32 GByte Arbeitsspeicher, Win 7 x64 ..... ; Für ~ 1000 Euro könnte ich kurzfristig weiter 64 GByte auf unserem Client nachrüsten und hätte mein Problem für einige Zeit gelöst / nach hinten geschoben;

Du hast das Problem nicht gelöst. Du versucht es durch unpassende Mittel zu umgehen.
Und solange deine erstellte Exe nicht 64-Bittig ist bringt dir das ehe nix.

Zitat von bernhard_LA:

Kann ich mir mit dieser Strategie "Zeit verschaffen" oder muss ich sofort den Code anpacken?

Das ist keine Strategie. Das ist planloses handeln.
Mit 32 GB RAM kann man heutzutage problemlos ein ganze Automodell im CAD-System laden. Und du schafft es nicht damit ein popelige Tabllendarstellung zu realisieren.

Ein Workaround wäre u.U. den Curser den Table-Komponente auf clUseServer zu stellen um ein paar Tage zeit zu haben. das so anzupassen das du nicht alle Datensätze in den Clientspeicher list. Man muss aber bedenken das dieser SErverseitige Curser Last auf den Server erzeugt.

Zitat von bernhard_LA:

unser fatales Problem hat folgende technische Kennwerte

1. DB Server : MSSQL, Prof. Version
2. Delphi : XE2, ADO, x64
3. Datenbank : 10 Tabellen
4. Dateivolumen 800 Mbyte
5. Index Volumen 200 Mbyte
6. Anzahl der Datensätze in der Größten Tabelle ~ 3 Mio

Unsere Anwendung liefert ein Thread Fehler beim Einfügen von weiteren Datensätzen in die DB.

Hallooooo,
das Problem taucht beim Einfügen auf!

Eigentlich ist hier nur ein

markieren

Code:

input into Mytable (Fld1...Fldx) values(....)

vonnöten (TAdoQuery .Execute). Da muß keine Tabelle geladen werden!


Gruß
K-H

Zitat:

Und solange deine erstellte Exe nicht 64-Bittig ist bringt dir das ehe nix.

unsere *.exe ist x64 !


Unsere Analyse zeigt : Das Programm kippt bereits beim Versuch eine TADOTable zu aktivieren (MyAdoTable.active := true ) , bis zur Anzeige der Daten im Grid kommen wir erst gar nicht.
Damit bin ich auch nicht in der Lage in einer Query einen Befehl "select * from MyTable" abzuschicken, damit ist ein Lösungsweg absolut nicht klar

Du sollst auch auf die Table verzichten und per Query, die Daten holen, welche Du benötigst! Und nur die!!! Das für Deinen Anwendungsfall falsche Verhalten selber nachzubilden ist ja auch nicht besser!

Zitat:

Du sollst auch auf die Table verzichten und per Query, die Daten holen, welche Du benötigst! Und nur die!!! Das für Deinen Anwendungsfall falsche Verhalten selber nachzubilden ist ja auch nicht besser!

Eurer Idee habe ich schon verstanden , nur führt die leider nicht zum Ziel.



Meine Anwendung ist ganz gut vergleichbar mit einem CAD Programm, wenn der Anwender auf den "Male Gegenstand auf Bildschirm, z.b. einen Pkw "
Button drückt dann läuft intern "select * from Tabelle"; soll ich beim Zeichnen des Autos die Reifen dann weglassen ????