TADOConnection optimale Einstellungen für Mehrfachverwendung

[Piro]

Moin zusammen,

ich habe eine Anwendung geschrieben, die Computerdaten ermittelt und diese in eine Datenbank (Cluster) speichert. Dies geschieht während des Login des Benutzers.

Derzeit sind es ca. 6700 Benutzer in unserer Domäne. Der Login ist zwischen 06:30 und 08:30. Es kommt wahrscheinlich vermehrt vor, dass zu bestimmten Zeit viele Benutzer mit Hilfe der Anwendung ihre Daten in die DB schreiben.

Die Anwendung verwendet einen SQL Benutzer, um die Daten in der DB zu speichern. Nun kommt es vermehrt dazu, dass im Server Log Einträge zu finden sind, dass der Login des SQL Benutzers nicht möglich ist, da das Passwort nicht richtig ist. Das kann nicht sein. Alle haben das gleich, da sie nur die eine Anwendung benutzen.

Max. Verbindungen des SQL Servers sind 32767 gesetzt.

Nun ist meine Überlegung, dass ich meine TADOConnection besser konfigurieren muss.

Was wären die besten Einstellungen in Bezug auf die oben geschilderte Situation.

Code:

TADOConnection - aktuelle Werte:
- CommandTimeout : 30
- ConnectOptions : coConnectUnspecified
- CursorLocation : clUseCLient
- IsolationLevel : ilCursorStability
- KeepConnection : True
- LoginPrompt     : False
- Mode            : cmReadWrite
- Provider        : SQLOLEDB.1

Was kann ich optimieren?

Hier mein Code, um die Verbindung aufzubauen.

Delphi-Quellcode:

function Tfrm_main.ConnectToSQLServer : Boolean;
begin
 Result := True;

 SQLConnection.Connected := False;
 if IsHostAlive(dbserver) = False then
 begin
   CreateLogFile('SQL Server ' + dbserver + ' is unreachable.',LogPath,0);
   Result := False;
   Exit;
 end;

 try
   // SQL Authentifizierung
   if dbinstance = '' then
     SQLConnection.ConnectionString := 'Provider=SQLOLEDB.1;Data Source='+dbserver+';Initial Catalog='+db+';User ID='+sqluser+';Password='+sqlpassword+';Persist Security Info=false'
   else
     SQLConnection.ConnectionString := 'Provider=SQLOLEDB.1;Data Source='+dbserver+'\'+dbinstance+';Initial Catalog='+db+';User ID='+sqluser+';Password='+sqlpassword+';Persist Security Info=false';
   SQLConnection.Connected := True;
 except
   CreateLogFile('Database Connection has been terminated with an unexpected error.',LogPath,0);
   Result := False;
   SQLConnection.Connected := False;
   Exit;
 end;

 if SQLConnection.Connected = False then
 begin
   CreateLogFile('Database Connection failed. Please contact your local Administrator',LogPath,0);
   Result := False;
   Exit;
 end;
end;

[Perlsau]

Moin,

wenn Username und Paßwort automatisch durch die Anwendung an den SQL-Server übermittelt werden – und das geschieht offensichtlich, soweit ich das deinem Connection-String entnehme –, kann es sich bei den betreffenden Log-Einträgen nicht um Benutzer dieser Anwendung handeln. Vielleicht versucht da jemand anders, sich anzumelden, und wählt für seine Versuche genau die Zeit aus, wo sowieso viel los ist. Kann man denn den Logfiles auch entnehmen, von wo diese fehlgeschlagenen Anmeldungsversuche ausgingen? Kommen sie immer vom selben Rechner? Hat da jemand eine Brute-Force-Anwendung am Laufen? Sind die falschen und daher abewiesenen Anmeldedaten immer dieselben?

[jobo]

Ich seh das auch so wie Perlsau. Interessant sind allerdings Deine eigenen Logs, also die Deiner Anwendung.
Da verschluckst Du ja explizite Fehlermeldungen, obwohl Du brav logst. Wieso gibst Du die Fehler nicht aus im Logfile?
Also, bevor Du beginnst Phantome zu jagen, erstmal die Ursache genau feststellen.
Und was falsche Anmeldungen / PW angeht: Bei einer so hohen Nutzerzahl ist es nur eine Frage der Wahrscheinlichkeit, das jemand was falsch eingibt. Oh man, also die Wahrscheinlichkeit ist immer gleich, bei der Hohen Nutzerzahl kommen dann eben entsprechende Ereignisse häufig. Natürlich nur, wenn diese Anwendung mit fixem Login nicht die einzige ist.

Zu den Phantomen:
Ich kann mir gut vorstellen, dass da schlicht irgendwo ein Timeout beim Verbindungsaufbau greift, weil der arme Server etwas überlastet ist. Die Fehlermeldung wäre dann natürlich ziemlich schräg. Aber das würde mich nicht überraschen.

Dennoch, erstmal sauber loggen, dann weiterschauen.

[Piro]

Moin,

Ich habe das Problem gefunden. Die fehlerhaften Logins sind tatsächlich eine andere Anwendung, die den gleichen SQL Benutzer verwenden. Habe ich erstmal umgestellt.
Des Weiteren hatten einige Anwender eine falsche Version und deshalb kam es zu den Login Fehlern.

Nun läuft alles sauber nach meiner Umstellung.

Danke für die Tipps.

Sven

[Sir Rufo]

Ich weiß nicht ob Sie es schon wussten, ...

ein MS-SQL kann den Benutzer hervorragend auch mit dem Windows-Konto anmelden. Und da wir hier eine Domain haben ist das sogar sehr simpel vom Management.

Nie wieder Probleme mit den Anmeldedaten und keine Passwörter die irgendwie gespeichert werden müssen.

[jobo]

Ja, ist eine schöne Sache, aber dann müsste man ja bei tausenden Benutzern noch eine Berechtigung vergeben. Das ist sicher zu anstrengend.

[Sir Rufo]

Zitat von jobo:

Ja, ist eine schöne Sache, aber dann müsste man ja bei tausenden Benutzern noch eine Berechtigung vergeben. Das ist sicher zu anstrengend.

Um allen Benutzern der Domain einen Zugriff zu erlauben reicht ein Eintrag aus. Das sollte machbar sein.

[jobo]

Wenn's denn alle sind.
Aber mein Beitrag war sowieso nicht ernst-hab die Ironietags vergessen- sondern der Versuch einer faulen Ausrede für den TE.
Ich finde es sehr fragwürdig, mit zentralem Login zu operieren, besonders wenn man durch so eine Trusted Login Möglichkeit viel besser dastünde.

[Piro]

Danke für den Tipp mit dem Domän-Benutzer.

Es liegt nicht am Benutzer und Passwort. Das ist aber ein anderes Thema.

Danke für die Hilfe.