Announcement

Collapse
No announcement yet.

Speicher Problem mit Datenbankabfrage

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Speicher Problem mit Datenbankabfrage

    Hallo
    Ich möchte gerne eine Anwendung schreiben wo man nach belieben SQL Befehle an einen DB Server schicken kann und das Ergebnis nach einem select z.B in einem dataGrid oder listView angezeigt werden.Es funktioniert auch alles nur wenn ich einen select über eine Tabelle schieb wo tausende
    Datensätze oder mehr vorhanden sind dann platzt meine Anwendung aus allen Nähten hatte mal über 500 MB im Speicher ist mir gar nicht aufgefallen hatte ich nur durch Zufall geshen und dann mal versucht rauszufinden warum.
    Bis jetzt ohne Erfolg.
    Das Problem kann ich ja evtl. verstehen ich hol mir alle Sätze im Speicher. Das muß ja nicht sein man kann dem odbcdataAdapter auch ein start und end recordset mitgeben das Problem was dann besteht ist folgendes wenn ich 10 oder mehr selects auf die DB abfrage dann wächst der Speicher immer an nach jedem button_Click mehr und mehr und mehr usw.Erst nach dem Beenden der Anwendung wirds etwas leerer im Speicher.Ich habe schon mit dem odbcDataAdapter und oder odbccommand ausprobiert ,das DataSet vorher geleert aber der Speicher steigt immer wieder an je mehr abfragen je mehr Speicher wird verbraten.
    Weiß jemand wie man sowas wieder los wird und oder es richtig Programmieren kann ?
    Die Anwendung wird in C# Progrmmiert als Datenbank wird die DB2 benutzt.
    Danke schonmal

  • #2
    Schaue mal hier rein:<p>
    http://www.entwickler-forum.de/WebX?128@@.4a870843<p>
    Stichwort: Garbage Collector.<p>
    Schöne Grüße, Mario NOac
    Schöne Grüße, Mario

    Comment


    • #3
      Hallo
      Da ich noch nicht so lange mit dem Framework Programmiere und mit Delphi etc. auch wenig am Hut hab bringt mich dieser Artikel leider nicht weiter.Aber Danke für deine Antwort.
      Ich kann mi aber kaum vorstellen das ich der einzigste bin der solch ein komisches Problem hat

      Comment


      • #4
        Hallo,

        &gt;..das ich der einzigste bin ...

        mit den Klassen SqlConnection, SqlDataAdapter und SqlCommand lässt sich dieser Effekt in der Tat nicht reproduzieren. Immer dann, wenn ich so etwas gesehen habe (wie zum Beispiel im Fall von <i>BDP.NET</i>) war der zugrundeliegende Datenbanktreiber der Schuldige. Denn <i>OdbcConnection</i> bindet ja "nur" einen alten ODBC-Treiber (Unmanaged Code) ein, so dass der Garbage Collector nicht mehr automatisch weiterhelfen kann

        Comment


        • #5
          Hallo
          ADO/ODBC/OleDB hin und her.Sagen wir mal so ,so richtig hab ich da noch nicht durchgeblickt.Im VS erstelle ich jedenfalls eine neue Datenquelle wähle beim provider <Microsoft OLE DB Provider for ODBC> aus und habe im nächsten Tab meine Connection die ich vorher im OdbcAdministrator definiert habe.Funktioniert alles auch jedenfalls was ich so sehen kann.
          Habe allerdings auch einen IBM AS400 OLE DB Provider ,wenn ich diesen auswähle dauert alles extrem lange im gegensatz zum ODBC Treiber.SQL Abfragen Verbindungsaufbau etc.
          Mit dem SQLDataAdapter / SQLConnection hab ich es noch nicht probiert,dachte dieser wäre für den SQL Server vorgesehen,werde es mal testen.Die Sache mit dem minimieren ist schon eine Komische Sache .Meine Anwendung hat z.B. 280 MB im Speicher nach einigen abfragen ,dann minimier ich die Anwendung ,dann hat sie noch 1,5 MB im Speicher beim maximieren gerade mal 4 bei den nächsten SQLs steigt der rapide an .Ob das mal alles so richtig ist mag ich zu bezweifeln.
          Alles sehr komisch..

          Comment


          • #6
            Hallo,

            mit SqlConnection, SqlDataAdapter und SqlCommand ist nur der Zugriff auf den MS SQL Server möglich.

            &gt;..dann minimier ich die Anwendung ...

            Beim Ablegen einer Anwendung in die Taskleiste verringert der Speichermanger von Windows das so genannte <i>Working Set</i> (d.h. die tatsächlich im physischen RAM befindlichen Speicherseiten), indem die "unnötigen" Speicherseiten in die Auslagerungsdatei geschrieben werden. Im Fall einer .NET-Anwendung spielt es auch noch eine Rolle, wann der Garbage Collector (GC) die nicht mehr benötigten Objektinstanzen freigibt. Um zu prüfen, ob der GC zu lange warten, kann man in der .NET Framework-Konfiguration die Threadpriorität des GC in den Vordergrund schalten.

            &#10

            Comment

            Working...
            X