connection zum Server

[Perlsau]

Zitat von claudine99:

Die Auslesefunktion der ini funktioniert. Das habe ich im Debug-Modus getestet. Leider bleibt das Problem weiter bestehen.

Und du bist dir ganz sicher, daß die Variable IP in deiner Procedure nach der Zuweisung mit IP := GetIPfromINI('NAT_IP.ini'); die richtige IP-Adresse enthält? Hast du dir einen Breakpoint auf diese Zeile gesetzt und durchgesteppt?

Zitat von claudine99:

Gibt es die ini, wird zuerst angezeigt, 'Connection open. SQL server does ot exist or access denied.' . Erst danach wird versucht, die Verbindung über die IP aus der ini herzustelllen.

Das bedeutet, es besteht bereits eine Verbindung deiner DB-Komponente mit der MS-SQL-Datenbank. Demnach funktioniert nämlich auch dein DM.AdoConnection1.CLOSE; nicht deinen Wünschen entsprechend. Auszug aus der Hilfe:
Mit Hilfe von Connected können Sie auch prüfen, ob ein Aufruf der Methode Open (Connected-Wert true) oder Close (Connected-Wert false) erfolgreich verlaufen ist.

In diesem Fall solltest du herauszufinden suchen, wo in deinem Programm bereits eine solche Verbindung vor dem Einsatz deiner Procedure zustande kommt, vielleicht in DM (Datenmodul) oder in einer anderen Unit, die auf das Datenmodul Zugriff hat. Versuche auch einmal, alternativ mit DM.AdoConnection1.Connected := false; zu schließen.

Zitat von claudine99:

Weiteren Quellcode in Bezug auf die Connection gibt es nicht.

Zitat von claudine99:

Kann es auch daran liegen, dass es bei eingebundenen Units ein 'on create' gibt, welches Daten lädt?

Das kannst nur du selbst beantworten, indem du in den eingebundenen Units selbst nachschaust. Aber eigentlich ist das nur schwer vorstellbar, denn die eingebundenen Units "wissen" in der Regel ja nichts von deinen Datenbank-Komponenten, es sei denn, du hast in einer deiner Units eben auch das Datenmodul eingebunden. Wie gesagt, das können wir hier nicht wissen.

Wie sieht es eigentlich mit der Eigenschaft KeepConnection aus?

Mit KeepConnection legen Sie fest, ob eine Anwendung mit einer Datenbank verbunden bleibt, auch wenn aktuell keine zugehörigen Datenmengenkomponenten aktiv sind. Wenn KeepConnection true ist (Voreinstellung), bleibt die Verbindung geöffnet. Bei Verbindungen mit entfernten Datenbankservern oder bei Anwendungen, die häufig Datenmengen öffnen und schließen, sollten Sie KeepConnection auf true setzen. Sie reduzieren auf diese Weise den Datenverkehr im Netzwerk, beschleunigen die Anwendung und umgehen die ständige Neuanmeldung beim Server, die erforderlich ist, wenn die Verbindung wiederhergestellt wird.

[p80286]

Wie wäre es denn die "default"-adresse auf einen Phantasiewert zu setzen, und die "richtige" Adresse aus der INI zu laden? Dann müßte sich das Fehlverhalten beim Kunden nachstellen lassen.

Was das Debuggen angeht, bei solch hartnäckigen Fällen hilft oftmals geduldiges Betätigen von F7.

Gruß
K-H

[claudine99]

TADOConnection.Connected:= false;-> hab ich
KeepConection := false;-> hab ich

ich habe einen Haltepunkt an das Ende der Funktion 'ini auslesen' gesetzt und mich dann durchgehangelt: ADOConnection.ConnectionString stimmt - wenn ini vorhanden, dann IP aus ini, sonst die 12.345.678.910....

es gibt einige Units, die ein 'on create' haben, unter 'uses' das Datenmodul steht und ein 'select' zum Laden von CheckListboxen ausführen-> Fehlerquelle?

[claudine99]

@p80286

hab ich gemacht. Funktioniert bei mir. Kann aber auch daran liegen, dass ich ja auf die 12.345.678.910 darf, aber der externe Partner nicht.

[Perlsau]

Zitat von claudine99:

TADOConnection.Connected:= false;-> hab ich
KeepConection := false;-> hab ich

Das ist aber schon seltsam: In dem Moment, wo du die Verbindung herstellen möchtest, besteht also keine aktuelle Verbindung, und dennoch erscheint die Meldung, daß eine Verbindung bestünde? Das kann ich nicht nachvollziehen ...

Zitat von claudine99:

ich habe einen Haltepunkt an das Ende der Funktion 'ini auslesen' gesetzt und mich dann durchgehangelt: ADOConnection.ConnectionString stimmt - wenn ini vorhanden, dann IP aus ini, sonst die 12.345.678.910....

Auch einen Haltepunkt in deiner Connect-Procedure? Überprüfe doch bitte auch dort einmal den Inhalt der Variablen IP.

Zitat von claudine99:

es gibt einige Units, die ein 'on create' haben, unter 'uses' das Datenmodul steht und ein 'select' zum Laden von CheckListboxen ausführen-> Fehlerquelle?

Okay, das wären dann mögliche Quellen für Verbindungen vor dem Ausführen deiner Connect-Procedure. Vielleicht hilft es, wenn du in diesen Units an den entsprechenden Stellen ein Connected := false bzw. ein Close einfügst ...

Ich habe mir angewöhnt, alle Verbindungen, die ich aufbaue, zentral von einer Stelle aus zu machen, und zwar im OnShow des Hauptformulars, wo z.B. erst einmal die Existenz einer eventuell notwendigen Ini-Datei überprüft und selbige ausgelesen wird, danach die Verbindung zur Datenbank hergestellt wird und danach erst alle Einstellungen, die in der Datenbank gespeichert sind (z.B. auch mal das Befüllen und Einstellen von Checklistboxen) vorgenommen werden.

[claudine99]

@ Frank,
Danke, da werd ich mir mal die Units vornehmen.

Der Inhalt der variablen IP stimmt jedenfalls.

Claudia

[Sir Rufo]

Also so wirst du da nicht weiterkommen ... und wir noch viel weniger ...

Ich würde mal vorschlagen du baust dir in das OnBeforeConnect Event der Connections einen StackTrace-Log ein, damit du erfährst, wer denn da die Verbindung auslöst (und ob es überhaupt die sind).

Im Anhang findest du die Units für das Loggen (Quelle http://synopse.info).

Einfach im Projekt-Verzeichnis auspacken und dann wie folgt dein Projekt bearbeiten:

In der DPR-Datei

Delphi-Quellcode:

uses
  SynCommons,  // Unit hinzufügen
  ...;

begin
  // Alle Logs in die Datei schreiben
  with TSynLog.Family do 
  begin
    Level := LOG_VERBOSE;
  end;

  ...
end.

Überall wo du jetzt den StackTrace benötigst fügst du einfach (SynCommons bei uses nicht vergessen) folgendes ein:

Delphi-Quellcode:

uses
  SynCommons,
  ...;

  // StackTrace in Log-Datei
  TSynLog.Add.Log( sllStackTrace );

Wichtig ist es jetzt beim Compilieren die MAP-Datei erzeugen zu lassen (Projekt/Optionen/Delphi-Compiler/Linken/Map-Datei = Detailiert) um auch die Namen im StackTrace zu sehen.

Für die Auslieferung wird nur noch die MAB-Datei benötigt (ist eine sehr stark komprimierte MAP-Datei und wird automatisch beim ersten Start der Anwendung selber erstellt).

Die Log-Dateien werden default im Anwendungs-Verzeichnis geschrieben.

[claudine99]

Danke Dir Sir Rufo, probiere ich aus. Ich halte Euch auf dem Laufendem

[Furtbichler]

Das mit dem Stack-trace... geht das nicht einfacher? Im Before-Connect einen Breakpoint setzen und dann den Aufrufstack anschauen?

Ich denk ja immer noch, das in der DFM eine der verknüpften Datasets auf 'Active = True' gesetzt ist. Böse Falle: Man schaut, ob die ADOConnection im DFM connected ist... Nein, super, alles klar. Das aber ein Dataset beim Öffnen implizit per verknüpfter ADOConnection eine Verbindung herstellt, vergisst man leicht.

Außerdem gibt es zwei ADOConnection-Komponenten. Sind beide geprüft?

Ich verwende die GExperts und da gibt es die Möglichkeit unter "Set Component Properties" einzustellen, das bestimmte Eigenschaften beim Programmstart garantiert den eingestellten Wert haben.

Bei mir setze ich immer TADOConnection.Connected := False , sowie TDataset.Active := False .

Das GExpert-Modul parst dann vor dem Compilieren die DFM und stellt o.g. constraints sicher. Problem gelöst (bei mir zumindest).

[Perlsau]

Zitat von Furtbichler:

Ich denk ja immer noch, das in der DFM eine der verknüpften Datasets auf 'Active = True' gesetzt ist. Böse Falle: Man schaut, ob die ADOConnection im DFM connected ist... Nein, super, alles klar. Das aber ein Dataset beim Öffnen implizit per verknüpfter ADOConnection eine Verbindung herstellt, vergisst man leicht.

Im Posting #3 hatte claudine99 geantwortet: "die ADOConnection steht auf 'Connected:= false' und alle Querys, welche die Connection nutzen, stehen auf 'Active:= false'." Wie sollte dan in der DFM was anderes stehen? Hab ich da was verpaßt?

Danach hattest du in #5 den Rat gegeben: "Entferne mal den Connectionstring im Objektinspektor und compiliere/starte das Programm erneut." und claudine99 hat geantwortet: "Hab ich schon vorher entfernt. Ich baue die Connection ja erst auf, wenn gestetet wurde, ob es ein ini gibt. So sollte es jedenfalls sein."

Also mal ehrlich, mir kommt das alles ziemlich seltsam vor ... wenn mein Delphi sich so verhalten würde, käme ich glatt auf die Idee, mein PC sei kaputt