Newsgroup: it.comp.lang.delphi
Titolo: OnPostError

Ciao a tutti,
      prima di scrivere in questa sede ho letto un po di post, ma nessuno mi 
ha dato la risposta che cerco.
Ho un indice in cui e' definito il valore ixUnique cosi' da essere certo di 
non avere doppioni i giro che potrebbero dare problemi.
Ho utilizzato questa opzione per eliminare un lavoro (inutile visto che c'e' 
gia') di controllo sul campo prima del salvataggio del record tramite 
TTable.locate(), se torna vero allora il record con la descrizione in un 
dato campo c'e' gia', quindi non salvare.
Ovviamente il controllo, artigianale, tiene conto del fatto che si sta 
modificando il record, in questo caso il recod non e' doppio ....
Tornando a noi, per evitare questo lavoro ho pensato di utilizzare l'evento 
OnPostError che viene chiamato ogni qual volta c'e' un errore di inserimento 
ma ho un problema che non riesco a risolvere, sia nell'ide che fuori 
(dell'exe) ovvero, il messaggio che devo visualizzare si visualizza ma il 
record viene comunque salvato !!!!
Ecco il codice ...
Prima di usare OnPostError ho usato questa procedura
 FDM.TFlag.DisableControls; // Per evitare sfarfallii
 If New Then FDM.TFlag.Append
 Else
 FDM.TFlag.Edit;
OK:=True;
 // Salvo i campi
 FDM.TFlag.FieldByName('Flag').AsString:=ED1.Text;
 FDM.TFlag.FieldByName('Descrizione').AsString:=ED2.Text;
 Try
 
FDM.TFlag.Post
;
 Except
   On ETurboDBError Do // Uso le turboDb di dataweb
   Begin
     RecordDoppio(1); //  Esce una form con la dicitura record doppio bla 
bla bla ...
     FDM.TFlag.EnableControls;
     FAF.ActiveControl:=ED1;
     Exit;
   End;
End;
Con questo codice il record, sia che sia nuovo (new) o lo si sta modificando 
... il record e' sempre salvato ... allora l'ho modificato cosi...
FDM.TFlag.DisableControls;
If New Then FDM.TFlag.Append
Else
FDM.TFlag.Edit;
OK:=True;
// Salvo i campi
FDM.TFlag.FieldByName('Flag').AsString:=ED1.Text;
FDM.TFlag.FieldByName('Descrizione').AsString:=ED2.Text;
FDM.TFlag.Post
;
End;
procedure TFDM.TFlagPostError(DataSet: TDataSet; E: EDatabaseError;
  var Action: TDataAction);
begin
  Action:=daAbort;
end;
In questo a volte succede come sopra, a volte funziona ma blocca la griglia 
, a volte il record modificato viene visualizato con le scritte errate, poi 
con TTable.Close; e TTable.Open la tabella si riapre e la griglia riporta le 
informazioni originarie ...
Qualche suggerimento ??? dove sto errando ???
Grazie di tutto,
Buon weekend
Daniele 
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4537 (20091023) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com

 dato campo c'e' gia', quindi non salvare.
E se tra il tempo della tua Locate() e il salvataggio un altro utente ha
operato sui dati salvando (se non esiste) o cancellando (se esiste) quel
record, che cosa succede? ti rendi conto che non � cos� che puoi
controllare queste situazioni? che database stai utilizzando?
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

Daniele ha scritto:

Oltre alle considerazioni di Andrea, credo che il blocco della griglia 
sia dovuto al fatto che non riabiliti i controlli nel dataset
  FDM.TFlag.DisableControls;
  Try
    If New Then
      FDM.TFlag.Append
    Else
      FDM.TFlag.Edit;
    OK:=True;
    // Salvo i campi
    FDM.TFlag.FieldByName('Flag').AsString:=ED1.Text;
    FDM.TFlag.FieldByName('Descrizione').AsString:=ED2.Text;
 
FDM.TFlag.Post
;
  finally
    FDM.TFlag.EnableControls;
  End;
^_Goblin_^

 controllare queste situazioni? che database stai utilizzando?
E', anche, per questo motivo che devo trovare il modo di utilizzare 
correttamente l'evento OnPostError.
Utilizzo i componenti DataWeb che altro non sono che una TTable e 
TDbDataBase piu' avanzati (migliorati rispetto agli originali) 100% 
conpatibili con quelli forniti da Borland (io ho ancora delphi 6).
Ora, tornando al questo evento, ho ben capito che viene invocato se durante 
il post avviene un errore ma, non ho capito, come gestirlo.
 Ti riporto le righe della procedura, anzi tutta
procedure TFAF.BT1Click(Sender: TObject);
begin
  If ED1.Text='' Then               // Se i campi sono vuoti si visualizza 
un errore generale ...
  Begin
    ErroreGenerale(1);
    FAF.ActiveControl:=ED1;
    Exit;
  End;
  If ED2.Text='' Then
  Begin
    ErroreGenerale(2);
    FAF.ActiveControl:=ED2;
    Exit;
  End;
  If New Then FDM.TFlag.Append
  Else
  FDM.TFlag.Edit;
  // Salvo i campi
  FDM.TFlag.FieldByName('Flag').AsString:=ED1.Text;
  FDM.TFlag.FieldByName('Descrizione').AsString:=ED2.Text;
  // Il DB e' indicizzato su Flag in modo ixUnique, quindi qui si genera 
un'eccezione perche' il valore di ED1.Text e' gia' presente nella tabella
 
FDM.TFlag.Post
;
  Close;
end;
procedure TFDM.TFlagPostError(DataSet: TDataSet; E: EDatabaseError;
  var Action: TDataAction);
begin
    Action:=daAbort;
end;
La cosa curiosa e' che nel tentativo di fare il post, la griglia (sia nel 
caso di un nuovo record, che nella modifica) viene aggiornata e la cella che 
visualizza il valore del FLAG cambia (o si aggiunge un record). Pero' 
chiudendo la tabella e riaprendola la trovo nell'aspetto originale (con il 
campo flag corretto o senza un nuovo record).
Un'altra anomalia e' che queste cose capitano anche se metto 
FDM.TFlag.DisableControls che, in teroria, non dovrebbe far vedere i 
cambiamenti in griglia fino al successivo Enablcontrols ...... cosa che non 
avviene ....
Dato che tutti gli esempi che ho trovato non vanno oltre quello che ho 
riportato qui, non so cosa fare per utilizzare al meglio questo evento.
Grazie di tuttto,
Ciao, Daniele


 dovuto al fatto che non riabiliti i controlli nel dataset.
Il conrollo sulla griglia adesso l'ho ripreso .......
Tuttavia anche disabilitando i controlli, nel momento del post la griglia 
viene aggiornata !!! ugualmente, poi viene riabilitata ma il record che si 
stava cercando di modificare mantiene il valore errato. Se chiudo e riapro 
la tabella, l'errore sparisce !!!! Comunque questa non dev'essere la 
soluzione !
C'e' sicuramente qualcosa di piu' semplice che mi sta sfuggendo.............
Grazie di tutto,
Ciao, Daniele


Ciao a tutti ...
     ho risolto ......... in effetti era una banalita' ..... glommm
Non mettevo TTable.Refresh !!!
Ora tutto ok !!
Grazie a tutti
Ciao, Daniele 


 
mmmm cosi' .. a prima vista .... un table.refresh dopo un abort ... mi 
sa di grande cavolata ... uno di quei AV che quando escono non sai dove 
prenderli.. io IMHO non mi fiderei .... poi .... :)
^_Goblin_^

 prenderli.. io IMHO non mi fiderei .... poi .... :)
Ti riporto la parte della procedura che ci interessa
FDM.TFlag.DisableControls;
  OK:=True;
  // Salvo i campi, anche se c'e' il disablecontrols la griglia viene 
comunque aggiornata nel post
  FDM.TFlag.FieldByName('Flag').AsString:=ED1.Text;
  FDM.TFlag.FieldByName('Descrizione').AsString:=ED2.Text;
  Try
 
FDM.TFlag.Post
;
  Except
    On ETurboDBError Do // dato che inserisco un valore gia' esistente .... 
l'errore si verifa
    Begin
      FDM.TFlag.Cancel; // dovrebbe annullare tutto
      FDM.TFlag.Refresh; // se non metto questa riga la grigla non viene 
riaggiornata e lascia il valore gia' esistente nel campo
// in cui sopra ho salvato ED1.Text. In teoria con Cancel tutto dovrebbe 
tornare come in origine ma cosi' non e' !!!!
// Con refresh e EnableControl la griglia non riflette alcun cambiamento.
      FDM.TFlag.EnableControls;
      RecordDoppio(1); // Form_RecordDoppio.Pas
      FAF.ActiveControl:=ED1;
      Exit;
    End;
  End;
  FDM.TFlag.EnableControls;
Non so cosa dire oltre al fatto che funziona ..... vediamo se regge !!!
Un'ultima domanda, secondo te ha piu' logica fare un try excpet end oppure 
fare i controlli nel onpostevent ???
E' la stessa cosa ??
Grazie e ciao
Daniele 
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4538 (20091024) __________


     Begin
....e se l'eccezione NON E' un ETurboDbError che succede?
A.

 correttamente l'evento OnPostError.
Ripeto la domanda a cui non hai risposto: che database stai utilizzando?
I componenti del tipo TTable andrebbero buttati nel dimenticatoio.


 E' la stessa cosa ??
Io centralizzerei tutto nell'evento OnPost discriminando il parametro 
dataset in modo da sapere quale tabella ha sollevato l'eccezione, e 
testando il tipo di eccezione viene sollevata per agire di conseguenza
^_Goblin_^

 I componenti del tipo TTable andrebbero buttati nel dimenticatoio.
Non so se le TurboDB hanno gli stessi problemi delle TTable.
Grazie di tutto
Ciao, Daniele
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4545 (20091026) __________


 ....e se l'eccezione NON E' un ETurboDbError che succede?
Bellissima domanda ....
La lasciamo ai posteri ???? o all'incazzato di turno che si vedra' un casino 
e sapra' il perche' ????
Provvedo subito :-))))
Grazie e ciao
Daniele
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4545 (20091026) __________


 testando il tipo di eccezione viene sollevata per agire di conseguenza
TKS ...
Ciao, Daniele 
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4545 (20091026) __________
