[DELPHI] BDE e perdita dati

[satgio]

Ciao a Tutti,

Ho creato un applicazione con Delphi utilizzando BDE mediante Paradox 7. L’applicazione ha funzionato correttamente durante la fae di sviluppo (in w2k) e non ho avuto nessun problema finché è stata installata su windows 98 .

Per poter utilizzare l’applicazione da me sviluppata su un nuovo pc, ho installato anche il motore bde, e copiato l’alias DBDEMOS in una cartella Del pc con w98, dove successivamente ho copiato le tabelle.

Successivamente sono andato nel pannello di controllo e ho aggiunto Il DBDEMOS.

Dopo aver lanciato il software l’applicazione funzionava correttamente, vedevo i record di prova che avevo fatto All’interno delle tabelle durante lo sviluppo.
Durante la giornata ho inserito circa 50 records, e ad un certo punto w98 è andato in standby per il power managment e ho dovuto reboottare il pc . Dopo il successivo riavvio ho rilanciato il programma è ho perso tutti i nuovi record venivano visualizzati solo i 4 records di test usati durante lo sviluppo.
Per cercare di capire l’origine del problema, ho provato a creare un nuovo record, a salvarlo e poi a spegnere il pc dopo aver chiuso l’applicazione. Al successivo riavvio il nuovo record era presente nel database.

A questo punto sono completamente al buio , ovvero non so se i records non sono stati salvati a causa di un errore di programmazione, oppure a causa di un problema dell’applicazione sotto w98 con BDE. Durante lo sviluppo mi era capitato un problema simile, ma ho notato che succedeva quando per esempio mettevo un record in edit mode e per sbagli (puntando con il mouse un altro record nella griglia) cercavo di inviare i dati al record precedentemente editato. Comunque dopo aver corretto l’errore non ho più notato simili problemi, anzi sembrava funzionare perfettmaente (su w2k dove ho isntallato delhpi).

È possibile che i dati non vengano inviati direttamente al database anche dopo aver utilizzato la funzione tblname. post , e che quindi a causa dell’errore di standby i dati inseriti non siano stati realmente scritti nella tabella ? Se così fosse come faccio ad assicurarmi che i dati siano realmente scritti dopo un tblname.post ? Io ho inserito nella GUI delle tdbgrid per vedere come vengono scritti i dati nei record, e utilizzo funzioni come edit e sembra funzionare tutto correttamente. Non potrebbe essere la perdita dei dati un errore generato del bde installato sul w98 ?

Per il momento ho intenzione di installare un pc con w2000 , bde e usare il software con questa configurazione.



Ho capito che BDE è dichiarato come obsoleto, però ho deciso di utilizzarlo perché ho trovato un buon libro che spiegava come utilizzare le varie funzioni , e devo ammettere che ero soddisfatto del funzionamento del programma che ho realizzato.

Un’altra cosa esiste un tool che si integra nell’IDE di delphi 7 per la gestione dei sorgenti ? sapete consigliarmi ?

Come al solito ringrazio anticipatamente chi risponde.

Saluti
Giovanni

[alka]

Per quanto riguarda il tuo problema con il BDE, non credo che la causa possa essere un errore di installazione della libreria poichè, normalmente, la tua applicazione funziona come si deve.

Sono un po' basito dal nome dell'alias che hai scelto, DBDEMOS, che se non sbaglio è il nome dell'alias predefinito creato a scopo dimostrativo.

Escluderei anche la discriminazione tra sistema operativo e sistema operativo: sono convinto che il verificarsi del problema su Windows 98 al posto di Windows 2000 sia un caso fortuito.

Sono a conoscenza del fatto che il BDE gestisce un proprio buffer e memorizza i valori sfruttando meccanismi di caching, perciò - a prima vista - sembra che il tuo problema sia dovuto ad una latenza intercorsa tra il Post dei dati e l'effettiva scrittura su disco, interrotta dall'entrata in modalità standby del PC.

Non conosco il formato Paradox 7 (non è il classico formato Paradox semplice che si usa solitamente con il BDE attraverso il driver STANDARD, vero?); se quel formato di database supporta le transazioni, è possibile che si debba effettuare un'operazione di "Commit" sui dati, cioè confermare la serie di modifiche apportate affinchè vengano applicate ai dati.

Ad ogni modo, tanto per fornire una soluzione oltre a mere supposizioni, suggerisco di richiamare ad ogni post la funzione DbiSaveChanges, che fa parte dell'API del BDE; l'ho vista utilizzare molto spesso per risolvere proprio i problemi derivanti dalla scrittura fisica dei dati su disco che viene, apparentemente, dilazionata.

Il suggerimento migliore che posso darti è quello di abbandonare il BDE in favore di qualche tecnologia di accesso ai dati: non credo che la presenza di un po' di documentazione sia sufficiente a spingere la scelta di una piattaforma obsoleta per la realizzazione di un nuovo progetto. Certo, la documentazione è importante, ma la quantità a disposizione andrebbe valutata osservando piattaforme concorrenti possibilmente aggiornate, dello stesso periodo, e non obsolete.
Non posso scegliere di programmare a 16 bit solo perchè ho trovato al primo colpo un manuale per lo sviluppatore Windows 3.1, non sei d'accordo?

Per quanto riguarda la gestione dei sorgenti, suppongo che tu ti riferissi ad un Version Control System, giusto?
Cerca il termine CVS e Delphi su Google per ottenere qualche link da consultare.

Ciao!

[AlbertoPicca]

Originariamente inviato da alka
Non conosco il formato Paradox 7 (non è il classico formato Paradox semplice che si usa solitamente con il BDE attraverso il driver STANDARD, vero?); se quel formato di database supporta le transazioni, è possibile che si debba effettuare un'operazione di "Commit" sui dati, cioè confermare la serie di modifiche apportate affinchè vengano applicate ai dati.

Confermo la presenza delle Transizione per quanto riguarda la versione 7.0. Nel tuo caso penso che sia proprio dovuto ad una mancata Commit.

[alka]

Originariamente inviato da AlbertoPicca
Confermo la presenza delle Transizione per quanto riguarda la versione 7.0. Nel tuo caso penso che sia proprio dovuto ad una mancata Commit.

Ottimo...

Probabilmente, uscendo dal programma normalmente i dati vengono salvati perchè la chiusura dei DataSet (tabelle) provoca la Commit implicita dei dati.

P.S.: bella questa sinergia di risoluzione dei problemi.

[AlbertoPicca]

Originariamente inviato da alka
P.S.: bella questa sinergia di risoluzione dei problemi.

Speriamo, però, di aver aiutato satgio

[satgio]

Vi ringrazio per le risposte.

Alka : capisco di non aver scelto la soluzione migliore per il database, e che non dovrei basarmi su DBE solo perché ho trovato un buon manuale. Il problema è che ho iniziato a fare qualche prova seguendo il manuale sul DBE e mi sono ritrovato in poco tempo ad aver praticamente realizzato il programma che mi serviva. (questo spiega il nome dell’alias DBDEMOS ).

Essendo quasi terminato , vorrei completare questo programma così e per progetti future utilizzare una altro database.
Devo ammettere che mi avevi sconsigliato di usare BDE ancora prima che partissi a fare il programma, però ormai quello che è fatto è fatto…
Per programmi futuri ho solo l’esigenza di usare un database desktop, e non una soluzione client/server, è per questo che non ho optato per dbxpress.

Quindi se ho capito bene , per risolvere il problema che ho adesso basta chiamare la funzione tblname.CommitUpdates; alla fine di ogni post ?

Grazie
Giovanni

[alka]

Originariamente inviato da satgio
Alka : capisco di non aver scelto la soluzione migliore [...]

Comprendo le tue ragioni...ad ogni modo, la cosa veramente importante è che tu sia conscio della scelta che hai fatto e che comunque tu tenga un «occhio aperto» su eventuali librerie e piattaforme alternative; la pratica con il BDE potrà esserti d'aiuto per non ricominciare da capo a livello concettuale ma applicare la tua esperienza nel modificare l'applicazione, qualora sia necessario.

Originariamente inviato da satgio
Quindi se ho capito bene , per risolvere il problema che ho adesso basta chiamare la funzione tblname.CommitUpdates; alla fine di ogni post ?

Per fare prima, intercetta l'evento OnAfterPost sulla tabella e inserisci la chiamata a CommitUpdates.

Ciao!

[satgio]

Ho utilizzato la proprietà commitupdates; sull'evento afterpost delle tabelle come
Da voi suggerito.
Dopo la compilazione appariva un errore tblname not in cashed update mode, quindi
ho messo la proprietà cash update mode = true della tbl e ora funziona tutto.

C'è comunque una cosa che non riesco a capire, e vi sarei grato se potreste aiutarmi.
Leggendo la documentazione di delphi ho visto la funzione di cash update, e dice:

CachedUpdates enables or disables the use of cached updates for a dataset. If
CachedUpdates is true, cached updates are enabled. If CachedUpdates is false,
cached updates are disabled.
When cached updates are enabled, updates to a dataset (such as posting changes,
inserting new records, or deleting records), are stored in an internal cache on
the client machine instead of being written directly to the dataset’s underlying
database tables. When changes are complete, an application writes all cached
changes to the database in the context of a single transaction.

Dato che l'opzione di default di cashupdate è = false da quello che leggo dovrebbe
significare che impostata su false la tabella non dovrebbe utilizzata la cash temporanea,
e di conseguenza presumo le modifiche apportate ai record vengono inviate
immediatamente alle tabelle dopo il post, senza “sostare” nella cash.
Essendo state le impostazioni originali delle mie tabelle cashupdate = false,
e quindi i dati sarebbero stati scritti immediatamente senza "sostare"
nella cash, non mi spiego perché sono andati persi dopo lo standby VVoVe: . La cashupdate
delle tabelle era = false.

Grazie
Giovanni

[AlbertoPicca]

Originariamente inviato da satgio
Essendo state le impostazioni originali delle mie tabelle cashupdate = false,
e quindi i dati sarebbero stati scritti immediatamente senza "sostare"
nella cash, non mi spiego perché sono andati persi dopo lo standby VVoVe: . La cashupdate
delle tabelle era = false.

Nel tuo caso non hai parlato di transazioni, ovvero quella particolare azione che permette di confermare o annullare tutto ciò che é stato manipolato da un certo istante T di tempo.
E' logico che se fai il post dei dati ma non esegui la Commit i dati non verranno memorizzati.
Prova a pensare queste transizioni come una seconda conferma (oltre il post) e tutto ti sarà più chiaro.

[alka]

Originariamente inviato da satgio
CachedUpdates enables or disables the use of cached updates for a dataset. If CachedUpdates is true, cached updates are enabled. If CachedUpdates is false, cached updates are disabled.

A volte la Guida riesce ad essere...geniale.

Originariamente inviato da satgio
Essendo state le impostazioni originali delle mie tabelle cashupdate = false, e quindi i dati sarebbero stati scritti immediatamente senza "sostare" nella cash, non mi spiego perché sono andati persi dopo lo standby VVoVe:.
La cashupdate delle tabelle era = false.

Effettivamente, il tuo caso è un po' strano, ma non conosco le specifiche del database Paradox 7.0 per poterlo escludere sicuramente da ogni responsabilità.