Ungültiges Quell-Array bei Zuweisung string zu Query.FieldByName

[haentschman]

Hallöle... 8-)

In der Entwicklung kann ich es nicht nachvollziehen...:?

Ein Arbeitsplatz (immer der Gleiche) schmeißt folgenden Fehler:

Zitat:

Ungültiges Quell-Array

siehe Bild 1

Die Query auf dem Datamodule hat ein Event "OnNewRecord"
siehe Bild 2

...Bei der Zuweisung des aktuellen Users...:evil:

PS: Die Tante sagt zu dem Fehler nichts...:?
PS: Der CurrentUser ist nicht nil!

Delphi-Quellcode:

  TUser = class(TBaseObject)
  strict private
  {$REGION 'Fields'}
    FRole_1: TUserRole;
    FRole_2: TUserRole;
    FRole_3: TUserRole;
    FIsDefault: Boolean;
    FUserGroup: TUserGroup;
    FUserName: string;
    FUserPassword: string;
    FChangePassword: Boolean;
    FUserShortName: string;
    FUserShortFull: string;
    FOnChangeUser: TOnChangeUserEvent;
    FAccessCount: Integer;
    FActive: Boolean;
    FAccessLast: TDateTime;
    FOffsetDayPreviousNumber: Integer;
  {$ENDREGION}
    procedure SetUserName(const Value: string);
  public
    constructor Create;
    destructor Destroy; override;
    property OnChangeUser: TOnChangeUserEvent read FOnChangeUser write FOnChangeUser;
    property UserGroup: TUserGroup read FUserGroup write FUserGroup;
    property UserName: string read FUserName write SetUserName;
    property UserNameShort: string read FUserShortName write FUserShortName;
    property UserNameFull: string read FUserShortFull write FUserShortFull;
    property UserPassword: string read FUserPassword write FUserPassword;
    property ChangePassword: Boolean read FChangePassword write FChangePassword;
    property Role_1: TUserRole read FRole_1 write FRole_1;
    property Role_2: TUserRole read FRole_2 write FRole_2;
    property Role_3: TMUserRole read FRole_3 write FRole_3;
    property IsDefault: Boolean read FIsDefault write FIsDefault;
    property Active: Boolean read FActive write FActive;
    property AccessLast: TDateTime read FAccessLast write FAccessLast;
    property AccessCount: Integer read FAccessCount write FAccessCount;
    property OffsetDayPreviousNumber: Integer read FOffsetDayPreviousNumber write FOffsetDayPreviousNumber;
    function IsRightAllowed(RightID: Integer): Boolean;
  end;

Wo muß ich suchen?

Danke :wink:

[Frickler]

Wäre die Fehlermeldung nicht eh anders, wenn "CurrentUser" nil wäre?

Aber vielleicht enthält ja "UserNameShort" irgendwelchen Murks? Im VCL Quelltext findet sich zu der Fehlermeldung der Kommentar "Used by TEncoding".

[Uwe Raabe]

Der Fehler entsteht in TEncoding.GetBytes:

Delphi-Quellcode:

  if (Bytes = nil) and (CharCount <> 0) then
    raise EEncodingError.CreateRes(@SInvalidSourceArray);

Eine der beiden Bedingungen trifft offenbar nicht zu.

Die aufrufende Zeile ist dabei folgende:

Delphi-Quellcode:

  Len := (Length(Value) + 1) * SizeOf(WideChar);
  if DataSize < Len then
    Len := DataSize;
  TEncoding.Unicode.GetBytes(Value, Low(Value), (Len - 1) div SizeOf(WideChar), FIOBuffer, 0);

Also ist entweder

Delphi-Quellcode:

FIOBuffer = nil

oder

Delphi-Quellcode:

(Len - 1) div SizeOf(WideChar)

ist 0. Was auch immer das auslösen mag bekommst du nur raus, wenn du die Anwendung auf dem betroffenen System debuggst.

[haentschman]

Danke...:wink:

Zitat:

Aber vielleicht enthält ja "UserNameShort" irgendwelchen Murks?

...in diesem Falle wäre "UserNameShort" = 'BeaDör':zwinker:

Zitat:

Was auch immer das auslösen mag bekommst du nur raus, wenn du die Anwendung auf dem betroffenen System debuggst

:kotz: ...ne oder.

[Uwe Raabe]

Dazu möchte ich noch sagen, dass ich einen systemischen Fehler für sehr unwahrscheinlich halte. Dein Code ist vollkommen korrekt und löst diesen Fehler vermutlich gar nicht aus. Ich verorte das Problem entweder an einer vollkommen anderen Stelle, die unerlaubt fremden Speicher manipuliert, oder eine externe Quelle (z.B. einen defekten Treiber oder eine fehlerhafte DLL) als Ursache des Problems. MadExcept zeigt doch die geladenen Module und deren Versionen an. Vielleicht wirst du da bei einem Vergleich mit einem funktionierenden System fündig.

[Delphi.Narium]

Wieviele weitere UserNameShort mit Umlauten gibt es?

Hast Du da zufällig bei genau einem UserNameShort mit 'nem Umlaut an genau einem Rechner ein (wieauchimmerwodurchauchimmerverursachtes) Problem oder zufällig nur einen UserNameShort, so dass das Problem andernorts einfach nur deshalb (bisher) nicht aufgetreten ist?

[Poelser]

Zitat:

Zitat von Uwe Raabe (Beitrag 1505452)

Ich verorte das Problem entweder an einer vollkommen anderen Stelle, die unerlaubt fremden Speicher manipuliert

und das könnte auf einem Rechner auch von einem defekten Speicherriegel herkommen, alles schon gehabt:-(

[haentschman]

Zitat:

Wieviele weitere UserNameShort mit Umlauten gibt es?

...u.a. ich selbst AndHän :zwinker:

Zitat:

und das könnte auf einem Rechner auch von einem defekten Speicherriegel herkommen

...die Hardware ist 2 Monate alt. :gruebel: Ausschließen kann man es nicht.

Zitat:

Ich verorte das Problem entweder an einer vollkommen anderen Stelle, die unerlaubt fremden Speicher manipuliert

...das dumme ist, daß der Fehler exakt der gleichen Stelle (Quelltext) auftritt. Auch nach dem Hochfahren ist es die gleiche Stelle im Quelltext.

Auf die Frage, ob das immer auftritt:
"Immer wenn ich Fenster 1 öffne, zum Fenster 2 wechsle, was eintrage, zum Fenster 1 zurückwechsle und einen neuen Vorgang erzeuge ---> Puff)"
...kann ich mir nicht vorstellen. Das ist eine Funktion die 100 Mal am Tag benutzt wird. Da wäre schon mehr Mecker... Deshalb stufe ich das als "sporadisch" ein...einmal am Tag (gefühlt) :?

[Uwe Raabe]

Zitat:

Zitat von haentschman (Beitrag 1505457)

Auf die Frage, ob das immer auftritt:
"Immer wenn ich Fenster 1 öffne, zum Fenster 2 wechsle, was eintrage, zum Fenster 1 zurückwechsle und einen neuen Vorgang erzeuge ---> Puff)"

Dann bist du immerhin in der glücklichen Situation, dass du reproduzierbare Steps hast. Hol dir die Kiste in dein Büro und versuch es mit Remote-Debugging. Alternativ Delphi installieren und direkt debuggen.

[haentschman]

Zitat:

Hol dir die Kiste in dein Büro

...nächste Woche bin ich wieder vor Ort. :zwinker:

[haentschman]

Moin...:P

Nachtrag:
Inzwischen gibt es mehrere Rechner mit diesem Fehler...:cry:

Inzwischen habe ich auf D11.1 umgestellt. Die Hoffnung, daß das damit erledigt ist, hat sich nicht bestätigt. :?

Ideen? :wink:

[Union]

Hast Du mal ein reproduzierbares Mini-Projekt?

[haentschman]

Danke für dein Mitgefühl...:wink:

Leider nein. Der Fehler kommt sporadisch! :evil: Aktuell ca. 1-2 mal im Monat bei > 1000 Aufrufen der Funktion.

Kann ich das "User" Objekt irgendwie "loggen" wenn der Fehler auftritt...:gruebel:

[Union]

Dann mach doch einen Unit-Test, der mit den "verdächtigen" Daten so lange läuft, bis der Fehler auftritt.

[Frickler]

Tritt der Fehler auch auf, wenn das Programm beim Virenscanner als Ausnahme hinzugefügt wird?

[haentschman]

Zitat:

Dann mach doch einen Unit-Test

...damit stehe ich auf Kriegsfuß...wegen Zeitmangel. :oops:

Zitat:

Tritt der Fehler auch auf, wenn das Programm beim Virenscanner als Ausnahme hinzugefügt wird?

...kann ich mal probieren. Ich halte die Aussichten aber eher unter 1%. :zwinker:

[Uwe Raabe]

Zitat:

Zitat von haentschman (Beitrag 1507190)

Zitat:

Dann mach doch einen Unit-Test

...damit stehe ich auf Kriegsfuß...wegen Zeitmangel. :oops:

... und wieviel Zeit steckst du mittlerweile in die Suche nach diesem Fehler?

{$I Geschichte von dem Bauern, der keine Zeit hat einen Zaun zu bauen, weil er die Kühe einfangen muss }

Wenn du einen Test schreibst, der die besagte Zeile ein paar Millionen mal fehlerfrei aufruft, dann brauchst du an der Stelle vermutlich nicht mehr weiter zu suchen. Das Problem liegt dann (wie schon vermutet) an einer anderen Stelle und die sichtbare Fehlermeldung ist nur ein Nebeneffekt eines anderen Fehlers.

[haentschman]

:zwinker:

Zitat:

... und wieviel Zeit steckst du mittlerweile in die Suche nach diesem Fehler?

...bis auf das Lesen der Meldung...keine. Ich habe noch andere Baustellen... :wink:

Zitat:

Wenn du einen Test schreibst, der die besagte Zeile ein paar Millionen mal fehlerfrei aufruft,

...ich habe mich damit noch nicht beschäftigt. :oops:

[Uwe Raabe]

Zitat:

Zitat von haentschman (Beitrag 1507192)

...bis auf das Lesen der Meldung...keine. Ich habe noch andere Baustellen... :wink:

Dann scheint es ja auch nicht sooo wichtig zu sein :)

[freimatz]

Zu Unit-Tests: https://blogs.itemis.com/schreibe-niemals-unit-tests

[haentschman]

Moin...8-)

...das der Quelltext in Ordnung sei, ist nicht ganz richtig. Aber ihr konntet es nicht wissen...:wink:

Fällt Euch was auf?

Delphi-Quellcode:

procedure TDMED.FDQVorgangAssignmentNewRecord(DataSet: TDataSet);
begin
  DMED.FDQVorgangAssignment.FieldByName('idBelKopf').AsString := DMED.FDQAssignment.FieldByName('idBelKopf').AsString;
  DMED.FDQVorgang.FieldByName('ixUserVon').AsString := FPreferences.CurrentUser.UserNameShort;
  DMED.FDQVorgang.FieldByName('ErfasstAm').AsDateTime := Now();
  DMED.FDQVorgang.FieldByName('ixSPAdr').AsString := DMED.FDQAssignment.FieldByName('ixSPAdr').AsString;
end;

...so muß es sein:

Delphi-Quellcode:

procedure TDMED.FDQVorgangAssignmentNewRecord(DataSet: TDataSet);
begin
  DMED.FDQVorgangAssignment.FieldByName('idBelKopf').AsString := DMED.FDQAssignment.FieldByName('idBelKopf').AsString;
  DMED.FDQVorgangAssignment.FieldByName('ixUserVon').AsString := FPreferences.CurrentUser.UserNameShort;
  DMED.FDQVorgangAssignment.FieldByName('ErfasstAm').AsDateTime := Now();
  DMED.FDQVorgangAssignment.FieldByName('ixSPAdr').AsString := DMED.FDQAssignment.FieldByName('ixSPAdr').AsString;
end;

...vorher schreibe ich in eine andere Datenmenge. :shock:

Das ist mit der Trennung der Datenmenge passiert...:oops: :duck:

Danke für die Teilnahme...:thumb: Sollte nochwas sein, melde ich mich. :-D


ja, ja, ja... mit UnitTests wäre das nicht passiert. :zwinker:

[BerndS]

wäre es nicht so noch besser?

Delphi-Quellcode:

procedure TDMED.FDQVorgangAssignmentNewRecord(DataSet: TDataSet);
begin
  DataSet.FieldByName('idBelKopf').AsString := DMED.FDQAssignment.FieldByName('idBelKopf').AsString;
  DataSet.FieldByName('ixUserVon').AsString := FPreferences.CurrentUser.UserNameShort;
  DataSet.FieldByName('ErfasstAm').AsDateTime := Now();
  DataSet.FieldByName('ixSPAdr').AsString := DMED.FDQAssignment.FieldByName('ixSPAdr').AsString;
end;

[himitsu]

Jupp, einmal das falsche DataSet,
dann gibt es das "richtige" auch direkt als Parameter

und DMED ........... NIEMALS nicht aus einer Form/Objekt-Methode auf die globale Varaible zu dieser Form/Objekt zugreifen ... wenn man eine Variable braucht, dann nimmt man hier das Self.

Delphi-Quellcode:

procedure TDMED.FDQVorgangAssignmentNewRecord(DataSet: TDataSet);
begin
  DataSet.FieldByName('idBelKopf').AsString := FDQAssignment.FieldByName('idBelKopf').AsString;
  DataSet.FieldByName('ixUserVon').AsString := FPreferences.CurrentUser.UserNameShort;
  DataSet.FieldByName('ErfasstAm').AsDateTime := Now;
  DataSet.FieldByName('ixSPAdr').AsString := FDQAssignment.FieldByName('ixSPAdr').AsString;
end;

Beim "ErfasstAm" könnte man sich eventuell noch streiten, ob es dann ist, wo man anfing, mit Einfügen, oder dann wenn man fertig war,
also ob das nicht besser erst im OnBeforePost aufgehoben ist, anstatt im OnAfterInsert ... bzw. in einem Trigger in der DB (und das "ixUserVon" auch, falls es z.B. dem LoginName für DBConnection entspricht)

[haentschman]

:oops:
Ich oute mich mal...
Bei der Umstellung war das noch der alte Code. Da ist nur das DataSet gewechselt worden. Vorgang->VorgangAssignment. In dieser Stuation habe ich nicht darüber nachgedacht.

Das habe ich gleich mal überall geändert. :oops:

Delphi-Quellcode:

procedure TDMED.FDQVorgangAssignmentNewRecord(DataSet: TDataSet);
begin
  DataSet.FieldByName('idBelKopf').AsString := FDQAssignment.FieldByName('idBelKopf').AsString;
  DataSet.FieldByName('ixUserVon').AsString := FPreferences.CurrentUser.UserNameShort;
  DataSet.FieldByName('ErfasstAm').AsDateTime := Now;
  DataSet.FieldByName('ixSPAdr').AsString := FDQAssignment.FieldByName('ixSPAdr').AsString;
end;