BDE Multithread Fehler: wenn Begegnung ora-12560, kann TDatabase

Question

Wir haben ein großes Programm, mit BDE + Oracle, entwickelt von Delphi, Wir verwenden 3 Threads zu tun DB-Operationen, sie verwenden getrennte TSession. (1 deamon Gewinde, 1 Daten sammeln Gewinde, 1 Prüfung Gewinde)

Wir verwenden diese Struktur:

TQuery -> TDatabase -> TSession

Wir verwenden diese Methode Abfrage zu tun:

try 
    qu.close; //TQuery 
    qu.sql.clear; 
    qu.sql.add('select foo from db_foos'); 
    qu.open; 
except 
    on e:Exception do 
    begin 
    db.close; // db is TDatabase, We use this to auto restart connection when network fail. 
    error(e.message); 
    end; 
end; 

das Problem ist, Wenn unser Programm mehr als 24 Stunden läuft, ora-12560 auftreten, und unser Programm kann die Verbindung nicht neu starten, und melden Sie diesen Fehler beim Ausführen von Abfragen.

Wir hatten Code überprüft, debuggte die ganze Woche lang, und immer noch kann es nicht lösen, kennen Sie das gleiche Problem?

edit:

Wir haben diesen Testfall:

3-Programm, jeden Lauf einen Thread (mit 1 Sekunde Schlaf) und zwischen 0,5 bis 1 Stunden Sie alle zur gleichen Zeit schlugen fehl. (3 DB-Betrieb und 1 Indy9 FTP-Client ...)

Also ich denken, es ist etwas falsch in BDE oder Windows-Socket ist ... Strom I auf einem Auto-Restart-Programm machanism als Behelfslösung arbeite.

Answer 1

Offenbar ist es ein weit verbreitetes Problem in dem das Oracle-Client vergisst, wo es sollte eine Verbindung sein. Vielleicht ist einer von ihnen helfen:

http://www.cryer.co.uk/brian/oracle/ORA12560.htm

http://www.dba-oracle.com/t_ora_12560_tns_protocol_adapter_error.htm

Answer 2

Haben Sie eine separate Timer-basierte Routine die DB jederzeit offen zu halten - das ist, was wir je meinen Kommentar oben tun. IE, wenn die Datenbank trennt, dann öffnen Sie es sofort wieder, verlassen Sie sich nicht auf die Abfrage, um es für Sie automatisch zu öffnen. Verwenden Sie einen Timer, um periodisch zu überprüfen, ob die Datenbank noch (wirklich) geöffnet ist. Auf diese Weise verwenden wir keinen separaten Thread und vermeiden Cross-Thread-Probleme, aber in unserem Fall haben wir eine Verbindung pro Client. Jeder Client-PC sammelt Daten und es gibt viele Client-PCs in der Fabrik.

In Ihrem Fall können Sie die DB-Prüfroutine in jedem Thread müssen.