MSSQL Fehler

[haentschman]

Hallöle...

Ich habe ein Tool was 365/24 läuft. In diesem Tool gibt es "Module". Beim Start des Tools werden verschiedene Connections (verschiedene DB) erstellt. Die Module verwenden die Connection die benötigt wird.

Sporadisch kommt es bei einem Modul zu folgenden Fehlern:

Zitat:

Error Module: Import der Avis - [FireDAC][Phys][ODBC][Microsoft][SQL Server Native Client 11.0]TCP-Anbieter: Ein Socketvorgang konnte nicht ausgeführt werden, da dem System Pufferspeicher fehlte oder eine Warteschlange voll war.

...danach

Zitat:

Error Module: Import der Avis - [FireDAC][Phys][ODBC][Microsoft][SQL Server Native Client 11.0]TCP-Anbieter: Normalerweise darf jede Socketadresse (Protokoll, Netzwerkadresse oder Anschluss) nur jeweils einmal verwendet werden.

Der Quelltext (DB Zugriff) ist von einem Kollegen "verzapft" worden. Auch wenn ich manche Sachen anders gemacht hätte, ist da nichts wirklich auffälliges.

Delphi-Quellcode:

// Work
function TModuleImportMailDatabase.GetWriteLastBelNumber:string;
var
  Qry: TFDQuery;
  FBelNumber: string;
begin
  Qry := CreateQuery;
  try
    Qry.SQL.Add(GetSQLByName('MODULE_IMPORT_MAIL_GET_BELART_LAST_NUMBER'));
    Qry.Open;
    if not Qry.Eof then
    begin
      FBelNumber := Qry.FieldByName('BelNummer').AsString;
      FBelNumber := IntToStr(StrToInt(FBelNumber) +1);
      Qry.Edit;
      Qry.FieldByName('BelNummer').AsString := FBelNumber;
      Qry.Post;
    end
    else
      FBelNumber := '';
  finally
    result := FBelNumber;
    Qry.Close;
    Qry.Free;
  end;
end;

function TModuleImportMailDatabase.IsDataAvailable(AuftragNr: string; FilialNr: string): boolean;
var
  Qry: TFDQuery;
  FSQL: string;
begin
  Qry := CreateQuery;
  try
    FSQL := GetSQLByName('MODULE_IMPORT_MAIL_IS_DATA_AVAILABLE');
    FSQL := StringReplace(FSQL, ':AUFNR', QuotedStr(AuftragNr), [rfIgnoreCase]);
    FSQL := StringReplace(FSQL, ':FILNR', QuotedStr(FilialNr), [rfIgnoreCase]);
    Qry.SQL.Add(FSQL);
    Qry.Open;
    if Qry.Eof then
      result := false
    else
      result := true;
  finally
    Qry.Close;
    Qry.Free;
  end;
end;

procedure TModuleImportMailDatabase.Write(Receipt: TSEAMTaskReceiptHead; var DatenOK: boolean);
var
  Qry: TFDQuery;
  FBelNumber: string;

  function MaxLength(Value: string; Laenge: Integer): string;
  begin
    Result := Value;
    if Length(Result) > Laenge then
    begin
      Result := Copy(Result, 1, Laenge);
    end;
  end;

begin
  Qry := CreateQuery;
  DatenOK := false;
  try
    //erst nachsehen, ob daten schon da
    if not IsDataAvailable(Receipt.STÖAuftragsNr, Receipt.STFilialNr) then
    begin

      Qry.SQL.Text := GetSQLByName('MODULE_IMPORT_MAIL_RECEIPT_INSERT');

      FBelNumber := '';
      FBelNumber := GetWriteLastBelNumber;
      Qry.ParamByName('pBelNummer').DataType := ftString;
      Qry.ParamByName('pBelNummer').AsString := FBelNumber;
...
      Qry.ParamByName('pAddDate').DataType := ftDateTime;
      Qry.ParamByName('pAddDate').Value := Receipt.AddDate; // D now
      Qry.ExecSQL;
      DatenOK := True;
    end;
  finally
    Qry.Free;
  end;
end;

PS: Speicher in der Größe ist immer stabil.
PS: https://social.technet.microsoft.com...dowsserver16de...is das Einzige was ich gefunden habe. Ob das damit zu tun hat?

...hat jemand Ideen?

Danke.

[TigerLilly]

Hmm, die Meldung gibt es in unterschieldichsten Kontexten:

https://community.symcon.de/t/3-imag...nge-voll/28037
https://administrator.de/forum/conne...en-263338.html
https://social.technet.microsoft.com...dowsserver16de
https://social.technet.microsoft.com...dowsserver16de

Das sieht doch eher nach einem servseitigen Problem mit den Ports aus, oder?

[haentschman]

Zitat:

Das sieht doch eher nach einem servseitigen Problem mit den Ports aus, oder?

...das Gefühl habe ich auch.

Die Frage ist: Wer belegt die Ports? In einem Beitrag ist vor einer Software die Rede...irgend ein Treiber. Das war aber 2017.

Das betreffende Modul schaut jede Minute in einen Ordner. Vieleicht haben die anderen Module keine Chance den gleichen Fehler zu werfen.

[rokli]

Moin,

Du gehst über einen ODBC Treiber, SQL Server Native Client 11.0 (Version 2011.110.7001.00).

Ist das neu?

Hast Du mal einen anderen ODBC versuch? Mit der Version 11 habe ich schon öfter Probleme gehabt, die ich mit der SQL Server (Version 10.00.19041.2130) nicht habe.

Gruß

[haentschman]

Moin...

heute morgen hatte ich wieder 2200 Mails gehabt... Es muß die Anwendung sein. Ein Neustart...alles wieder gut.

Ich habe folgendes herausgefunden:
...es bestehen aktuell rund 12000 Connections. (Bild)

Verstehen tue es nicht. Das Modul wird bei Ausführung mit der Datenbank erzeugt und wieder freigegeben.

Delphi-Quellcode:

constructor TTaskDatabase.Create(Preferences: TTaskPreferences);
begin
  FPreferences := Preferences;
  FConnectionE := CreateConnection(ctE);
  FConnectionM := CreateConnection(ctM);
  FConnectionW := CreateConnection(ctW);
  FConnectionD := CreateConnection(ctD);

  FCurrentConnectionType := ctE;
end;

destructor TTaskDatabase.Destroy;
begin
  if Assigned(FConnectionD) then FConnectionD.Free;
  if Assigned(FConnectionW) then FConnectionW.Free;
  if Assigned(FConnectionM) then FConnectionM.Free;
  if Assigned(FConnectionE) then FConnectionE.Free;
  inherited;
end;

Muß man vor dem Free die Connection explizit trennen? Ich dachte das mit dem Free das automatisch erfolgt.

Nachtrag:
Ich habe das Modul gefunden was mit jedem Durchlauf eine neue Connection erzeugt. (Standard = Bild2)

[DeddyH]

BTW:

Zitat:

if Assigned(FConnectionD) then FConnectionD.Free;

Das ist doppelt gemoppelt, Free prüft intern sowieso schon auf Assigned (im Gegensatz zu Destroy).