Newsgroup: it.comp.lang.delphi
Titolo: Problemi con Paradox

C'è una cosa, fra tante :o) , che non mi spiego.
Mi capita che durante l'uso di un'applicazione che memorizza dati su una
tabella paradox 7 se si verifica un'errore di qualunque tipo, es. key
violation (non ho ancora inserito un controllo sui dati) o comunque anche
errori esterni al programma che bloccano il pc perdo tutti i dati inseriti
fino a quel momento.
Se però inserisco dei dati, chiudo l'applicazione, la riapro e si verificano
errori successivamente i dati scritti prima della chiusura rimangono
disponibili.
Insomma pare che Delphi esegua una specie di roll back in caso di errori.
A titolo semplificato di esempio:
  with Table1 do
  begin
    First;
    for A := 0 to 19 do
    begin
      Edit;
      Fields[NField].AsInteger := AArray[A];
      Post;
      Next;
    end;
  end;
La DBGrid conferma le avvenute modifiche.
Si verifica successivamente un'errore.
Rilancio l'applicazione ed i dati non risultano modificati.
(La verifica la eseguo anche con Database Desktop).
Non usando gli aggiornamenti in cache il Post non dovrebbe memorizzare
permanentemente la modifica / inserimento anche se l'errore si dovesse
verificare addirittura durante il ciclo?
Valter?

Ciao.
capitava anche a me con archivi Paradox
Me la sono cavata cosě :
Sul DataModule nella funzione AfterPost dell' ARCHIVIO preso in esame ho 
inserito questa istruzione (ARCHIVIO=Table1)
procedure TDM.ARCHIVIOAfterPost(DataSet: TDataSet);
begin
      DbiSaveChanges(ARCHIVIO.handle);
end;
Devi aggiungere tra le uses la DbiProcs
Io uso D5 Pro + BDE , tu NON lo hai specificato cosa utilizzi, la prossima 
volta fallo, č meglio se desideri aiuto piů precisi.
Ciao
Marco

Hai ragione...
Delphi 7 PRO + BDE
faccio come suggerito
Ciao
Valter
"MaoSw" <mar...@NOSPAMtin.it> ha scritto nel messaggio
news:4396b03f$0$16211$4faf...@reader3.news.tin.it...


 ha scritto nel messaggio 
news:Jrzlf.16788$z_6....@tornado.fastwebnet.it...


 (almeno nell'esempio) la procedura ti potrebbe rallentare.
L'esempio di codice era semplificato. In realtà i cicli sono ben più di uno
ed il For A è variabile.
Ad ogni inserimento / modifica dell'utente sulla Table principale è
necessario riallineare tutti i dati legati a questa operazione sulla Table
secondaria (la teorica Table1 in oggetto).
Dunque la seconda proposta dovrebbe essere + indicata.
Però, se il Close della Table scrive permanentemente nella tabella potrebbe
anche essere la soluzione.
Non essendo questa Table la principale, l'accesso durante l'uso del prg è
limitato e potrei aprirla e chiuderla al bisogno.
Invece utilizzare DbiSaveChanges per l'altra che deve restare sempre
consultabile.



In effetti un close salva su disco, io ho adottato DbiSaveChanges per
evitare di "dimenticarmi" di fare gli open .
Inoltre, ma qui vado proprio a memoria, era più lento il close quando è
necessario gestire degli indici.
Oggi il NG è un poco fiacco, forse sentono il ponte, magari poi la prossima
settimana si scatenano e mi massacrano con qualche post che smentisce quanto
io affermo, ma ripeto oramai io adotto sempre questa tecnica, perchè così
funziona e se qualche cliente hoh ha la corrente stabilizzata o "gioca" con
il PC e va tutto in tilt, almeno"perde" solo l'ultima operazione e non tutto
il lavoro da quando ha aperto le procedure.
Spesso gli utenti (o utonti come il buon Morde li chiama") lasciano
programmi e/o procedure aperte tutta la giornata senza mai preoccuparsi di
uscire dalle stesse quando non le usano (vedi emissione dei DDT), così tocca
a noi cercare di salvare il salvabile.
Ciao
Marco

 a noi cercare di salvare il salvabile.
E' il caso del zucchetti gestionale 1, del quale siamo rivenditori e io ci
faccio le personalizzazioni: il server e' una cartella condivisa agli
UTONTI, se questi mi lasciano il gestionale aperto in pausa pranzo e per
qualche motivo gli si spegne il pc, gli si crasha, oppure il server va
giu'... beh gli indici mdx si corrompono alla grande! Hai voglia a
recuperare una scrittura di magazzino in mezzo ai dbf...
ciao!
-- 
Morde. 
ICLDweb: 
http://www2.samatel.com/icld/


E poi quando durante l'inventario le rimanenze non tornano (e non tornano
mai) č colpa del TUO  programma che non funziona bene.
La prima settimana di gennaio si avvicina. RRRRabbrividisco.  :-)
Ciao
Marco

 mai) č colpa del TUO  programma che non funziona bene.
Netto! :D
Stai telefonando e mandando fax ai tuoi clienti di fare assolutamente il
backup prima delle chiusure festive?
Possono succedere tante cose ai computer che stanno spenti 10 giorni... ;)
Ciao



Non ci crederai (anche se invece credo che ci credi benissimo) , ma alcuni
mi stressano tutti gli anni perchè gli invii un fax con l'elenco delle
operazioni di fine/inizio anno.
Anche se il SW è cambiato, alla fin fine sono le stesse da 15 anni, ma loro
perdono il fax dell'anno prima.
La prima riga delle istruzioni è : "FARE LE COPIE DI SALVATAGGIO SU UN
SUPPORTO MAGNETICO ESTERNO (ZIP)" .
Cmq quando ai primi di gennaio qualcuno dei PC che sono stato spenti per N
giorni non si accende (e accade spesso perchè ci sono uffici che sembrano
cantine e 10/15 gg. di umidità si fanno sentire) è un piacere quando ti
rispondono "COPIE DI SALVATAGGIO ??? SI, SI LI HO FATTE SUL DISCO FISSO"
("ma va a ca..re" penso io) .
Ciao
Marco

 Non ci crederai (anche se invece credo che ci credi benissimo)
Ebbene si, lo sai pure, ti credo eccome: e' lo stesso anche per noi...
Cambiano gli anni, i software, le tecnologie, ma l'UTONTO resta sempre
TONTO... non ci sono cavoli... ;-)
Ciao!
