connection zum Server

[claudine99]

Hallo, ich habe eine Anwendung, welche auch außerhalb eines Firmennetzes mit einer NAT-IP gestartet werden soll. Dazu haben wir die NAT-IP in einem ini-File "verpackt" und im Quellcode bei 'on create'folgendes festgelegt:

Delphi-Quellcode:

ConnString :=
  'Provider=SQLOLEDB.1;Persist Security Info=False;' +
  'User ID=%s;Password=%s;Data Source=%s;Use Procedure for Prepare=1;' +
  'Initial Catalog=ABCDEF;Auto Translate=True;Packet Size=4096;Use Encryption for Data=False;'+
  'Tag with column collation when possible=False';

  UserName := 'DMT#';
  PassWord := 'dmt';
  IP := GetIPfromINI('NAT_IP.ini');
  DM.AdoConnection1.CLOSE;
  DM.ADOCon__DWH.Close;
  try
     Memo1.Lines.Append('try connect to IP: ' + IP);
     Memo1.Lines.Append('');
     DM.AdoConnection1.ConnectionString := Format(ConnString,[UserName, PassWord, IP]);
     DM.AdoConnection1.Open;
     DM.ADOCon__DWH.ConnectionString := Format(ConnString,[UserName, PassWord, IP]);
     DM.ADOCon__DWH.Open;
     if IP = '12.345.678.910'then
       Memo1.Lines.Append('Connection to IP: 12.345.678.910')
     else
      Memo1.Lines.Append('Connection to NAT IP: ' + IP);

  except
   on E: Exception do
   begin
    Memo1.Lines.Append('No connection to database available, please check IP in the NAT_IP.ini!') ;

   end;

  end;

Warum aber, versucht das Programm trotzdem zuerst auf die 12.345.678.910 zuzugreifen?

Viele Grüße und Danke für jede Hilfe!

[Sir Rufo]

Kann es sein, dass die ADOConnection mit

Delphi-Quellcode:

Active := True

compiliert wurde? ;)

Das

Delphi-Quellcode:

OnCreate

Event wird aufgerufen nachdem alle Komponenten (auch die ADOConnection) erzeugt wurden. Und wenn die mit

Delphi-Quellcode:

Active := True

compiliert wurde, dann verbindet die sich halt erst einmal

[claudine99]

nein, leider nicht:(
die ADOConnection steht auf 'Connected:= false' und alle Querys, welche die Connection nutzen, stehen auf 'Active:= false'.

[Sir Rufo]

Zitat:

Zitat von claudine99 (Beitrag 1207086)

nein, leider nicht:(
die ADOConnection steht auf 'Connected:= false' und alle Querys, welche die Connection nutzen, stehen auf 'Active:= false'.

Das alle verbundenen DataSets dann auch nicht aktiv sind, ist logisch ;)

So als Tip, ich würde die Verbindungseigenschaften im Event TADOConnection.BeforeConnect setzen, dann kannst du sicher sein, wenn die Verbindung geöffnet wird (egal von wo und wem) sind auch die richtigen Verbindungsparameter gesetzt ;)

Wenn du dann noch einen Haltepunkt auf diesen Event setzt, dann kannst du auch über den CallStack sehen, wer da die Verbindung so öffnet (auch wenn es dir eigentlich egal sein könnte)

[Furtbichler]

Entferne mal den Connectionstring im Objektinspektor und compiliere/starte das Programm erneut.

Was passiert?

[claudine99]

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 :x
Leider immer das selbe Ergebnis.

[Jumpy]

Nur mal doof gefragt. Was steht denn in der variablen IP?
Sicher das der Zugriff auf die INI funzt?

[claudine99]

wenn ich das Codebeispiel bei 'beforeConnect' hineinschreibe bekomme ich eine Fehlermeldung: EStackoverflow mit der Meldung 'Stack-Überlauf'

[Furtbichler]

Du schreibst im BeforeConnect' natürlich nicht 'MyConnection.Open;' rein. Denn dann wird ja 'BeforeConnect' aufgerufen (schätze ich).

Aber Du hast einen Wurm in deiner SW, wenn Du nicht mal weißt, wo die Verbindung aktiviert wird.

[claudine99]

so wird die ini ausgelesen:

////////////ini auslesen

function GetIPfromINI(cFile:string):string;
var
ini: TIniFile;
filename: String;
begin
Result:='';
filename := ExtractFilePath(ParamStr(0)) + cFile;
ini := TIniFile.Create(filename);
try
Result := ini.ReadString('connection', 'IP', '12.345.678.910');
finally
ini.Free;
end;
end;
////////////////////////////////////


die ini heißt auch richtig und steht im gleichen Ordner wie die .exe.
Wäre super, sollte jemand noch eine Idee haben.

[claudine99]

Den Wurm suche ich ja grad:cry::cry:
Vorher hatte ich den Aufbau der Connection bei 'on create'. Trotzdem wurde zuerst versucht, sich mit der 12.345.678.910 zu verbinden und daach mit der IP aus der ini. Da die Kollegen, welche die ini nutze, icht auf die andere IP kommen, erhalten sie dann immer die Fehlermeldug der fehlenden Connection.

[Perlsau]

Zitat:

Zitat von claudine99 (Beitrag 1207124)

so wird die ini ausgelesen:

Delphi-Quellcode:

 Result := ini.ReadString('connection', 'IP', '12.345.678.910');

Schau doch einmal nach, ob nicht hier bereits der Default-Wert als Result zurückgeliefert wird. Womöglich existiert dein Schlüssel nicht oder es ist ihm kein Datenwert zugeordnet.

Auszug aus der Hilfe:

ReadString liest einen String-Wert aus einer INI-Datei.
Der String Section bezeichnet den Abschnitt, der den zum Wert gehörigen Schlüssel enthält.
Der String Ident ist der Name des Schlüssels mit dem Wert.
Default ist der Standardwert, der in den folgenden Situationen zurückgeliefert wird:

1. Der Abschnitt ist nicht vorhanden.
2. Der Schlüssel existiert nicht.
3. Dem Schlüssel ist kein Datenwert zugeordnet.

[Sir Rufo]

@Perlsau

:thumb:

@claudine99

Setze dir einen Haltepunkt auf das Ende der Funktion und schau, welchen Wert Result dort bekommt.

BTW: Es macht sich immer gut in ein Programm eine Log-Funktion einzubauen, dadurch sieht man, was dort wirklich passiert, gerade wenn das beim Anwender in Aktion ist.

[Furtbichler]

Zitat:

Zitat von Perlsau (Beitrag 1207132)

Schau doch einmal nach, ob nicht hier bereits der Default-Wert als Result zurückgeliefert wird.

Dann würde folgendes nicht passieren:

Zitat:

Zitat von claudine99 (Beitrag 1207129)

Trotzdem wurde zuerst versucht, sich mit der 12.345.678.910 zu verbinden und danach mit der IP aus der ini...

Wann wird denn zum 1.Mal connected (mit der falschen IP)?

[Perlsau]

Zitat:

Zitat von Furtbichler (Beitrag 1207139)

Zitat:

Zitat von Perlsau (Beitrag 1207132)

Schau doch einmal nach, ob nicht hier bereits der Default-Wert als Result zurückgeliefert wird.

Dann würde folgendes nicht passieren:

Zitat:

Zitat von claudine99 (Beitrag 1207129)

Trotzdem wurde zuerst versucht, sich mit der 12.345.678.910 zu verbinden und danach mit der IP aus der ini...

Die IP, die in der ersten Connect-Zeile steht, ist zweifellos diejenige IP, die von der

Delphi-Quellcode:

Function GetIPfromINI(cFile:string):string;

zurückgeliefert wird.

Delphi-Quellcode:

  IP := GetIPfromINI('NAT_IP.ini'); // ZUWEISUNG AUS DER FUNCTION AN IP
  DM.AdoConnection1.CLOSE;
  DM.ADOCon__DWH.Close;
  try
     Memo1.Lines.Append('try connect to IP: ' + IP);
     Memo1.Lines.Append('');
     DM.AdoConnection1.ConnectionString := Format(ConnString,[UserName, PassWord, IP]); // ÜBERNAHME DES STRINGS AUS IP
     DM.AdoConnection1.Open;

Weshalb also sollte es nicht passieren können, daß zuerst mit der Default-IP verbunden wird? Denn schließlich wird in

Delphi-Quellcode:

Result := ini.ReadString('connection', 'IP', '12.345.678.910');

genau diese Default-IP angegeben, falls eine der Fehlerbedingungen von

Delphi-Quellcode:

TIniFile.ReadString

zutrifft. Und genau diese Fehlerbedingung könnte eintreffen, ja ist sogar sehr wahrscheinlich, denn sonst stünde in der Variablen IP ja eine andere IP-Adresse als der Defaultwert.

[Furtbichler]

Schon klar, aber es werden hier doch 2 Verbindungsversuche unternommen. Die erste mit der (falschen) default IP und die zweite dann mit der richtigen.

Laut Code dürfte es nur einen Verbindungsversuch geben. Das es aber zwei gibt, gehe ich stark davon aus, das es entweder mehr Code gibt (den wir nicht kennen), oder eben das Connect doch beim Start ausgeführt wird (weil es in der DFM so eingestellt ist).

Sehe ich das etwas falsch?

[Perlsau]

Zitat:

Zitat von Furtbichler (Beitrag 1207160)

Schon klar, aber es werden hier doch 2 Verbindungsversuche unternommen. Die erste mit der (falschen) default IP und die zweite dann mit der richtigen. Laut Code dürfte es nur einen Verbindungsversuch geben. Das es aber zwei gibt, gehe ich stark davon aus, das es entweder mehr Code gibt (den wir nicht kennen), oder eben das Connect doch beim Start ausgeführt wird (weil es in der DFM so eingestellt ist). Sehe ich das etwas falsch?

Ich glaube schon, daß du das falsch siehst. Laut Code werden beide Verbindungen mit denselben Parametern geöffnet. Wenn die Default-IP eine gültige IP-Nummer darstellt, dann werden auch beide Connects ausgeführt – wenn nicht, dann scheitert der TRY-Block schon beim ersten Versuch. Die Frage war ja Warum aber, versucht das Programm trotzdem zuerst auf die 12.345.678.910 zuzugreifen? – somit besteht das Problem darin, daß nicht mit der vermeintlich in der Ini-Datei existierenden IP verbunden wird, sondern mit der Default-IP. Weshalb auch sollte der zweite Connect nicht ausgeführt werden, wenn der erste erfolgreich war?

Delphi-Quellcode:

DM.AdoConnection1.ConnectionString := Format(ConnString,[UserName, PassWord, IP]);
DM.AdoConnection1.Open;
   DM.ADOCon__DWH.ConnectionString := Format(ConnString,[UserName, PassWord, IP]);
DM.ADOCon__DWH.Open;

Deshalb sollte sie auch zuerst einmal den Rückgabewert ihrer Ini-Auslesefunktion überprüfen. Leider wissen wir nicht, was diese Funktion zurückliefert ...

[Furtbichler]

Alles klar. Senile Demenz meinerseits. In letzter Zeit ein häufigeres Problem.

[Perlsau]

Zitat:

Zitat von Furtbichler (Beitrag 1207162)

Alles klar. Senile Demenz meinerseits. In letzter Zeit ein häufigeres Problem.

Mach dir nichts draus, da bist du beileibe nicht der einzige :-D

[claudine99]

....sorry für das späte Feedback, aber da ich nicht die Möglichkeit habe, die Verbindung mit der NAT-IP zu testen, musste ich auf ein Feedback warten.

Die Auslesefunktion der ini funktioniert. Das habe ich im Debug-Modus getestet. Leider bleibt das Problem weiter bestehen. 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.

Weiteren Quellcode in Bezug auf die Connection gibt es nicht.

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

Vielen Dank für Eure Mühe!

[Perlsau]

Zitat:

Zitat von claudine99 (Beitrag 1207256)

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

Delphi-Quellcode:

IP := GetIPfromINI('NAT_IP.ini');

die richtige IP-Adresse enthält? Hast du dir einen Breakpoint auf diese Zeile gesetzt und durchgesteppt?

Zitat:

Zitat von claudine99 (Beitrag 1207256)

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

Delphi-Quellcode:

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

Delphi-Quellcode:

DM.AdoConnection1.Connected := false;

zu schließen.

Zitat:

Zitat von claudine99 (Beitrag 1207256)

Weiteren Quellcode in Bezug auf die Connection gibt es nicht.

Zitat:

Zitat von claudine99 (Beitrag 1207256)

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:

Zitat von claudine99 (Beitrag 1207262)

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:

Zitat von claudine99 (Beitrag 1207262)

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:

Zitat von claudine99 (Beitrag 1207262)

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:thumb:

[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

Delphi-Quellcode:

TADOConnection.Connected := False

, sowie

Delphi-Quellcode:

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:

Zitat von Furtbichler (Beitrag 1207345)

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 :?

[Furtbichler]

Zitat:

Zitat von Perlsau (Beitrag 1207360)

Also mal ehrlich, mir kommt das alles ziemlich seltsam vor ...

Vollkommen korrekt, das passt alles nicht. Aber vielleicht ist auf einem Formular noch ein aktives Dataset, das mit der ADOConnection verknüpft ist. So...Pferde...Apotheke...kotzen und so. Deshalb verlass ich mich nur noch auf GExperts...

[p80286]

Zitat:

Zitat von Furtbichler (Beitrag 1207386)

Aber vielleicht ist auf einem Formular noch ein aktives Dataset, das mit der ADOConnection verknüpft ist. So...Pferde...Apotheke...kotzen und so. Deshalb verlass ich mich nur noch auf GExperts...

Ach nee, was haben denn die damit zu tun?
erzähl mal.

Gruß
K-H

[Furtbichler]

Wovon soll ich erzählen, von GExperts, den Apotheken, den Pferden oder der Vomitation denselben vor derselben? :lol:

[p80286]

GExperts bitte.
Die Pferde vor der Apotheke kenn ich schon.

Gruß
K-H

[Furtbichler]

Zitat:

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.

Dieses 'Set Component Properties' ist bei mir aber nicht im GExperts-Menü, sondern in der unter 'Configuration' angezeigten Liste von GExperts-Plugins. Dort gibt es dann einen 'Configure...' Button und darüber kann ich die vor jedem Compile zu prüfenden Klassen sowie die Defaultwerte der Properties einstellen. Echt sehr sehr praktisch.

Mehr Info?

[claudine99]

nachdem ich in allen Units das 'on create' inkl. dem 'Datenholen' entfernt habe, funktioniert es.
DANKE für Eure Unterstützung!

VG
Claudia:thumb: