AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Duplicate-Value-Fehler bei Aufruf von Append
Thema durchsuchen
Ansicht
Themen-Optionen

Duplicate-Value-Fehler bei Aufruf von Append

Ein Thema von Perlsau · begonnen am 6. Mai 2015 · letzter Beitrag vom 9. Mai 2015
Thema geschlossen
Perlsau
(Gast)

n/a Beiträge
 
#1

GELÖST: Duplicate-Value-Fehler bei Aufruf von Append

  Alt 6. Mai 2015, 05:01
Dieses Problem hat mich offenbar so stark beschäftigt, daß ich ganz unruhig geschlafen habe. Vermutlich hab ich davon geträumt, erinnere mich aber nicht wirklich daran. Auf jeden Fall bin ich vor einer halben Stunde aufgewacht und mir war so gut wie klar, warum das nicht funktionieren konnte, was ich da zusammengestrickt hatte. Die Lösung: Cancel. So einfach und doch so wirkungsvoll:
Delphi-Quellcode:
Function TFrame_PersonenAktuell.Eintragen(Id : Integer; Person : String; Datum : TDateTime; DateExists : Boolean) : Boolean;
begin
  Try
    DatMod.Qset_Personen.Append;
    Feld_Id.AsInteger := Id;
    Feld_Name.AsString := Person;
    If DateExists Then
    Feld_Datum.AsDateTime := Datum;
    DatMod.Qset_Personen.Post;
    Result := True;
  Except
    On E: Exception Do
    Begin
      Result := False;
    // Das ist die Lösung: das Dataset ist noch im Insert-Mode, wenn ich es beim nächsten Mal anspreche
      If (DatMod.Qset_Personen.State = dsInsert) Or
         (DatMod.Qset_Personen.State = dsEdit) Then
          DatMod.Qset_Personen.Cancel;
      Memo_Log.Lines.Append(e.Message + GLD.TS + IntToStr(Id));
    End;
  End;
end;
Da sieht man mal wieder, daß menschliche Gehirne manchmal (oder auch öfter) erst dann auf die Lösung eines Problems stoßen, wenn man sie in Ruhe arbeiten läßt
Edit meinte noch: Abgelenkt und auf die falsche Fährte gelockt hatte mich die Fehlermeldung, die ja eigentlich die vom vorherigen Fehler war. Da wäre es doch schön, wenn Delphi melden würde, daß sich das Dateset bereits im Insert-Modus befindet ... doch dann hätten meine grauen Zellen ja nichts zu knobeln gehabt

Geändert von Perlsau ( 6. Mai 2015 um 05:14 Uhr) Grund: Edit
 
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.884 Beiträge
 
Delphi 11 Alexandria
 
#2

AW: Duplicate-Value-Fehler bei Aufruf von Append

  Alt 6. Mai 2015, 06:07
Insert und Append rufen Post auf, wenn der vorige Satz noch im Editmodus ist.
Markus Kinzler
 
Perlsau
(Gast)

n/a Beiträge
 
#3

AW: Duplicate-Value-Fehler bei Aufruf von Append

  Alt 6. Mai 2015, 06:24
Ahhh – ohhh .. entfleucht es mir gerade lautstark ...

Damit erklärt sich natürlich alles: Das ist nicht die alte Fehlermeldung, da wird beim zweiten Versuch, das Duplikat einzufügen, derselbe Fehler noch einmal ausgelöst. Auf so einen "gemeinen" Fallstrick muß man erst mal kommen

Danke, mkinzler, wieder was dazugelernt
 
Dejan Vu
(Gast)

n/a Beiträge
 
#4

AW: Duplicate-Value-Fehler bei Aufruf von Append

  Alt 6. Mai 2015, 07:43
Ich würde die Exceptionbehandlung noch verbessern: Reagiere explizit auf EIBNativeException, anstatt auf Exceptions im allgemeinen.
 
Perlsau
(Gast)

n/a Beiträge
 
#5

AW: Duplicate-Value-Fehler bei Aufruf von Append

  Alt 9. Mai 2015, 04:49
Was ist daran in welcher Hinsicht besser? Immerhin müßte ich, um deinen Vorschlag umzusetzen, eine zusätzliche Unit einbinden. Exception fängt jedoch den Fehler einwandfrei ab, das genügt mir.
 
Dejan Vu
(Gast)

n/a Beiträge
 
#6

AW: Duplicate-Value-Fehler bei Aufruf von Append

  Alt 9. Mai 2015, 09:13
Eine neue Unit einbinden ist ja jetzt nicht direkt ein Gegenargument, oder?

Aber warum soll das 'besser' sein? Ganz einfach: Wie ich bereits schrieb, ist es einfach sauberer, explizit auf genau diese Exception zu reagieren, und nicht auf irgend eine. Es kann ja auch nach dem Post geknallt haben, und dann wäre zumindest die Reaktion z.T. eine andere (bzw. könnte sein).

Auch wenn Du natürlich argumentieren wirst, das in diesem konkreten Fall gar keine andere Reaktion eintreffen kann oder dir das egal ist, sollte man -auch aus Gründen der Lesbarkeit- genau aufführen, wie man in welchem Ausnahmefall reagiert. Beispielsweise wäre es denkbar, das Du später einmal eine andere Logik hinter das Post packst und spätestens dann solltest Du individuell reagieren. Warum also nicht gleich?
 
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#7

AW: Duplicate-Value-Fehler bei Aufruf von Append

  Alt 9. Mai 2015, 09:30
Was ist daran in welcher Hinsicht besser? Immerhin müßte ich, um deinen Vorschlag umzusetzen, eine zusätzliche Unit einbinden. Exception fängt jedoch den Fehler einwandfrei ab, das genügt mir.
Problematisch ist daran, dass du eben egal welche Exception fängst und durch den großen Einzugsbereich von try .. except eben auch für alles Möglich eine Exception bekommen kannst.

Wenn du programmtechnisch alles richtig machst, dann wird diese Lösung exakt das machen, was du davon erwartest. Somit also keine Einwände.

Die Probleme fangen immer dann an, wenn es aus welchen Gründen auch immer in dem gekennzeichneten Bereich zu einer Exception kommt:
Delphi-Quellcode:
  Try

    {problematischer Bereich Anfang}

    DatMod.Qset_Personen.Append;
    Feld_Id.AsInteger := Id;
    Feld_Name.AsString := Person;
    If DateExists Then
    Feld_Datum.AsDateTime := Datum;

    {problematischer Bereich Ende}

    DatMod.Qset_Personen.Post;
    Result := True;
  Except
dann reagierst du so, als ob es sich um ein Duplikat handelt.

Besser wäre es zumindestens schon mal das so umzustellen

Delphi-Quellcode:
Function TFrame_PersonenAktuell.Eintragen(Id : Integer; Person : String; Datum : TDateTime; DateExists : Boolean) : Boolean;
begin
  DatMod.Qset_Personen.Append;
  Feld_Id.AsInteger := Id;
  Feld_Name.AsString := Person;
  If DateExists Then
  Feld_Datum.AsDateTime := Datum;

  Try
    // Nur Post-Methode abfangen
    DatMod.Qset_Personen.Post;
    Result := True;
  Except
    // Eine Einschränkung auf den konkreten Exception-Typ wäre noch besser
    On E: Exception Do
    Begin
      Result := False;
    // Das ist die Lösung: das Dataset ist noch im Insert-Mode, wenn ich es beim nächsten Mal anspreche
      If (DatMod.Qset_Personen.State = dsInsert) Or
         (DatMod.Qset_Personen.State = dsEdit) Then
          DatMod.Qset_Personen.Cancel;
      Memo_Log.Lines.Append(e.Message + GLD.TS + IntToStr(Id));
    End;
  End;
end;
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
 
jobo

Registriert seit: 29. Nov 2010
3.072 Beiträge
 
Delphi 2010 Enterprise
 
#8

AW: Duplicate-Value-Fehler bei Aufruf von Append

  Alt 9. Mai 2015, 10:42
Also ich seh das nicht so problematisch, da jede Exception abgefangen und mit der original Message gelogged(!) wird und im Fall eines bestimmten, ggF. problematischen Datasetstate, genau dieser State/ Fall behandelt wird (unabhängig von der exakten Fehlermeldung, aber abhängig eben vom State). Es geschieht hier also nichts falsches.
Ein spezifischeres Exception Handling kann nur in Kombi mit dem allgemeinen geschehen und ist auch nur dann sinnvoll, wenn eine spezifische, dazu passende Codesequence folgt.

Vielleicht ist schon das verschieben des Try Blocks auf das Post problematisch, wenn es bei der Wertezuweisung ins Dataset knallt.
Gruß, Jo
 
Perlsau
(Gast)

n/a Beiträge
 
#9

AW: Duplicate-Value-Fehler bei Aufruf von Append

  Alt 9. Mai 2015, 12:06
Problematisch ist daran, dass du eben egal welche Exception fängst und durch den großen Einzugsbereich von try .. except eben auch für alles Möglich eine Exception bekommen kannst.
Echt jetzt? Für was könnte ich denn noch eine Exception bekommen?

Wenn du programmtechnisch alles richtig machst, dann wird diese Lösung exakt das machen, was du davon erwartest. Somit also keine Einwände.
Das nennt man eine Tautologie: Wenn ich dich mit Wasser begieße, bist du naß. Wenn ich alles richtig mache, gibt's keine Fehler. Ei sowas aber auch, da wäre ich in hundert Jahren nicht draufgekommen

Die Probleme fangen immer dann an, wenn es aus welchen Gründen auch immer in dem gekennzeichneten Bereich zu einer Exception kommt:
Äh – welche Probleme? Wenn es von Append bis Post bzw. Cancel zu einer Exception kommt, wird der Name nicht eingetragen und stattdessen in die Textdatei geschrieben mit einem Hinweis auf den Grund, weshalb das nicht eingetragen wurde. Wo ist denn da das Problem?

Inzwischen gibt es nicht mal mehr Doubles, die in die Textdatei geschrieben werden müssen, denn ich frage nun vor dem Append ab, ob der Name bereits eingetragen ist:
Delphi-Quellcode:
Function TAktual.Eintragen_Person(Id: Integer; Person: String; Datum: TDateTime; DateExists: Boolean): Boolean;
Var
  Z : Integer;
  Aus : String;

begin
  Z := 0;
  Aus := Person;

  While DatMod.PersonExists(Aus) Do
  Begin
    Inc(Z);
    Aus := Person + ' (' + IntToStr(Z) + ')';
  End;

  Person := Aus;

  Try
  ...
Ich kann erst später nachschauen/entscheiden/recherchieren, ob der doppelte Name dieselbe Person bezeichnet oder eben eine andere mit demselben Namen. Die Gründe hierfür zu erklären würde jetzt aber zu weit führen. Ich sehe hier nicht wirklich ein Problem, nicht mal im Ansatz. Und selbstverständlich verwende ich in anderen Fällen schon die passenden Exceptions, z.B. beim Umgang mit IdHttp:
Delphi-Quellcode:
Function TAktual.Anfrage(Var Aurl: String) : Boolean;
begin
  Try
    AUrl := IdHt.Get(Aurl);
    Result := True;
  Except
    on E: EIdHTTPProtocolException Do
    Begin
      Result := False;
      Aurl := Aurl + GLD.TS + IntToStr(e.ErrorCode);
    End;
  End;
end;
Da wird dann später anhand des Errorcodes auf den Fehler reagiert, einstweilen wird er in der aufrufenden Methode protokolliert, weshalb Aurl ein Var ist (und GLD.TS ein Trenner mit Space: ' | '). Was wäre da jetzt z.B. anders, wenn ich statt EIdHTTPProtocolException einfach Exception schreiben würde? Würde sich das Programm auch nur ein klein wenig oder sogar spürbar anders verhalten? Ich glaube kaum ...

Besser wäre es zumindestens schon mal das so umzustellen

Delphi-Quellcode:
Function TFrame_PersonenAktuell.Eintragen(Id : Integer; Person : String; Datum : TDateTime; DateExists : Boolean) : Boolean;
begin
  DatMod.Qset_Personen.Append;
  Feld_Id.AsInteger := Id;
  Feld_Name.AsString := Person;
  If DateExists Then
  Feld_Datum.AsDateTime := Datum;

  Try
    // Nur Post-Methode abfangen
    DatMod.Qset_Personen.Post;
    Result := True;
  Except
    // Eine Einschränkung auf den konkreten Exception-Typ wäre noch besser
    On E: Exception Do
    Begin
      Result := False;
    // Das ist die Lösung: das Dataset ist noch im Insert-Mode, wenn ich es beim nächsten Mal anspreche
      If (DatMod.Qset_Personen.State = dsInsert) Or
         (DatMod.Qset_Personen.State = dsEdit) Then
          DatMod.Qset_Personen.Cancel;
      Memo_Log.Lines.Append(e.Message + GLD.TS + IntToStr(Id));
    End;
  End;
end;
Also mal ehrlich, lieber Sir Rufo, wieso soll denn das Dataset nach Auftreten eines Fehlers, der ja einzig und allein ein Fehler beim Post sein kann, nicht im Insert-Status sein? Eine andere Möglichkeit gibt es hier doch gar nicht mehr. Bei meiner Version können zumindest noch das Append und die Wertzuweisungen (theoretisch) Exceptions auslösen, weshalb die Abfrage des Status mehr oder weniger gerechtfertigt ist. Aber hier? Du schreibs doch selber im Kommentar: Nur Post-Methode abfangen. Was für einen Status also kann ein Dataset nach einem mißlungenen Post überhaupt haben? Richtig: dsInsert oder dsEdit. Denn wäre bereits das Append schiefgelaufen – wäre ja theoretisch möglich, weil z.B. die Verbindung zur DB nicht mehr besteht –, wäre das Programm mit einer Fehlermeldung abgestürzt. Bei mir würde es aber nicht abstürzen. Also Sachen rätst du mir, da bleib ich doch lieber bei meiner Vorgehensweise, wenn du gestattest, vielen Dank.

Geändert von Perlsau ( 9. Mai 2015 um 12:16 Uhr)
 
Thema geschlossen


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 14:23 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz