![]() |
Datenbank: mysql • Version: 4.1 • Zugriff über: zeos
Zeos Query - too many connections
Hallo,
Ich habe eine Klasse TDatabase in der sich folgendes befindet
Delphi-Quellcode:
Der Konstruktor dazu sieht so aus:
TDatabase = class(TObject)
private FWQuery : TZQuery; FDQuery : TZQuery; FCQuery : TZQuery; FMQuery : TZQuery; FSqlConnection : TZConnection; public constructor Create(); //...
Delphi-Quellcode:
constructor TDatabase.Create();
begin FSqlConnection := TZConnection.Create(FSqlConnection); FSqlConnection.HostName := '//'; //Server FSqlConnection.User := '//'; //Benutzername FSqlConnection.Password := '//'; //Passwort FSqlConnection.Database := '//'; //Name der Datenbank FSqlConnection.Protocol := 'mysql-4.1'; FSqlConnection.Port := 3306; FWQuery := TZQuery.Create(FWQuery); FWQuery.Connection := FSqlConnection; FDQuery := TZQuery.Create(FDQuery); FDQuery.Connection := FSqlConnection; FCQuery := TZQuery.Create(FCQuery); FCQuery.Connection := FSqlConnection; FMQuery := TZQuery.Create(FMQuery); FMQuery.Connection := FSqlConnection; end; Nun benutze ich in einer Kind-Klasse in einer Funktion das FCQuery und während FCQuery noch offen ist wird in der selben Funktion noch das FDQuery benutzt. Wenn die Abfragen ausgelesen wurden versuche ich immer die Queries zu schließen und zu zerstören.
Delphi-Quellcode:
FCQuery.Close;
FCQuery.SQL.Text := 'SELECT'; FCQuery.SQL.Add('..............etc'); FCQuery.Open; while not FCQuery.EOF do begin FMyStatus := FCQuery.FieldByName('Status').AsString; // etc if (...) then begin //... FDList := FMyDSearch.DBSearch('vague',FMyDCriteria); // <-------- Ruft eine Funktion auf in der FDQuery in gleicher Weiße benutzt wird wie FCQuery in dieser Funktion //... end; //... FCQuery.Close; FCQuery.Destroy; //... Obwohl ich die Queries am Ende immer zerstöre und meine Datenbank 100 Connections zur gleichen Zeit zulässt, kommt der SQL Fehler, dass "too many connections" vorhanden sind. Vielleicht kann mir jemand sagen wie ich die Zquery richtig disconnecte ? |
Re: Zeos Query - too many connections
1, Ich sehe in deinem Code das du immer FCQuery zerstörst. Die erzeugung erfolgt nur im Konstruktor
2, Rufe Destroy nicht direkt auf. Hiefür ist Free zuständig. 3, Binde mal FastMM in deinem Code ein um schnellere Rückmeldung über Speicherlücken zu bekommen. |
Re: Zeos Query - too many connections
zu 1,
Die Funktion ist eine Funktion einer Kinderklasse von TDatabase, sprich beim Erstellen der Instanz der Kinderklasse rufe ich ja den Konstruktor auf und somit ein neues TZQuery. Ich hab auch grad versucht die Instanz nach dem Gebrauch wieder zu zerstören, sodass die Queries alle verlorengehen, aber hilft auch nichts, gleicher Fehler. zu 2, Hmm ok aber ändert nichts soweit. |
Re: Zeos Query - too many connections
zu 1.
Du erzeugst die Queries im Konstruktor und gibst sie in einer Methode frei. Und wenn jetzt die Methode ein 2tes Mal für die gleiche Instanz aufgerufen wird? |
Re: Zeos Query - too many connections
Die Instanz wird einen einmaligen Aufruf erzeugt (und kann dann zerstoert werden eigentlich).
Ich denk aber nicht, dass das was mit den "too many connections" zu tun hat. Ich hab ja eher das Problem, dass die Instanzen noch vorhanden sind als dass sie mir fehlen |
Re: Zeos Query - too many connections
Dann häng doch mal FastMM rein um zu sehen ob es nicht komplett an einer anderen Stelle liegt.
|
Re: Zeos Query - too many connections
Jo hab ich, find blos die komische log datei nicht ^^
|
Re: Zeos Query - too many connections
Wennst du alles korrekt (Compilerschalter+Defines) machst liegt die parallel zur Exe.
|
Re: Zeos Query - too many connections
Ja die Logdatei wird mega groß und ich muss das Programm abbrechen sonst hört er wohl garnicht mehr auf in die Log datei reinzuschreiben. Irgendwie bau ich mist mit meinem Objekten :/
|
Re: Zeos Query - too many connections
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 19:04 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 by Thomas Breitkreuz