Newsgroup: it.comp.lang.delphi
Titolo: Mi hanno SCASSATO gli indici PARADOX

Ho un'applicazione fatta con delphi 5 che usa delle tabelle PARADOX.
Questa applicazione e' installata in un solo PC, quindi anche il DB viene
usato solo da questo.
Il mio problema e' che su quelle caz...... di tabelle PARADOX mi si scassano
spesso gli indici.
Quale potrebbe essere il problema?


di solito la colpa e' di chiusure improvvise del programma (crash di
windows, reset della macchina, mancanza di corrente) oppure di una cattiva
progettazione del software. Vedi te :)
Ciao, Sandro


Stai pure sicuro che la "seconda" e' da scartare...

 Stai pure sicuro che la "seconda" e' da scartare...
1^ legge di Lazarus:
Quando un programmatore afferma che il proprio software non e' 
progettato male, e' sicuramente progettato male.
-- 
Posted from  [80.105.34.80] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 progettato male, e' sicuramente progettato male.
Legge di Zortek complementare alla 1' legge di Lazarus:
Un programmatore Visual Basic afferma sempre che i suoi software sono
progettati bene.
;)
Ciao, Sandro

 ArtId: 24248


Zortek wrote:

Postulato di Ktarr figlio di Knorr:
Per fare un pessimo programma è condizione necessaria e sufficente un
cattivo programmatore.
Visual Basic, non basta  ma aiuta...
maurizio

E' tutto sul PC
"Max S. C. Z." <Massimiliano....@Softway.it> ha scritto nel
messaggio news:9puop3$r8d$1...@fe1.cs.interbusiness.it...





Apparte la progettazione del software che non voglio stare a discutere....
alcuni suggerimentini:
- Non usare controlli DBAware (DBGrid, DBEdit ...), che al momento del
Change mettono il DataSet in stato di edit, (difatti gli indici Paradox
frequentemente si scassano se si tronca l'application mentre la tabella è in
State=dsEdit).
- Usa la DBISaveChanges sull'afterPost del DataSet, così la tua modifica non
viene bufferizzata in memoria ma scritta fisicamente su disco.
Spero che ciò possa aiutarti. Ciaoux

viene bufferizzata in memoria ma scritta fisicamente su disco.
E cosi' rallenti tutto e aumentando gli accessi su disco faciliti 
collisioni tra utenti.
Usa DBISaveChanges in Application.OnIdle o in altri momenti in cui l'utente 
non sta lavorando.
Ciao Uberto
-------------------------------
Message Posted by  <dedGateway>
http://www.dedonline.com/forump

non sta lavorando.
E così gli continua a sbombare..
Però vedi di non criticare solo le risposte che diamo noi ma tenta anche di
aiutare chi ha fatto la domanda iniziale...
Ciao ciao

E così gli continua a sbombare..
Perche'?
Diminuendo i DBISaveChanges diminuiscono anche i possibili conflitti.
Nel caso di piu' post di seguito qui fa un unico update e non diversi.
Spero possa essere utile a chi ha posto la domanda...


Si ma si allungano i momenti in cui ci sono ancora modifiche pendenti...

>Si ma si allungano i momenti in cui ci sono ancora modifiche pendenti...
Se il problema e' che crashando l'applicazione non ci sono gli ultimi dati 
allora e' migliore la tua strada, se invece il problema e' che ogni tanto 
gli indici si corrompono e' meglio diminuire la frequenza dei salvataggi.


Allora ok.
Ma per il problema del crash degli indici hai qualche altro suggerimento?
Su qualche applicazioncina anche io ho avuto il problema e ho dovuto
implementare la ricostruzione con la TUtil32 ma se si potesse in qualche
modo prevenire...
Grazie.
Ciaoux

modo prevenire...
E' il problema dei db file-based.
Cmq con una rete solida e macchine ben configurate e non piu' di 5-6 client 
non dovrebbe crashare quasi mai, al massimo una volta all'anno.


toglierli tutti tranne il primario ed usare query.
Vuoi dire che le query non hanno bisogno di indici per
lavorare ? sei sicuro ?
-- 
The Follet

On Mon, 15 Oct 2001 17:18:56 GMT, thef...@thefollet.bye (The Follet)
wrote:

No, non servono se vuoi fare dei bei Table Scan ;-)

No, non servono se vuoi fare dei bei Table Scan ;-)
Appunto... e' quello che penso anch'io... ma il table scan
riduce moltissimo le prestazioni...
Ma e' vero che riducendo gli indici secondari e lasciando
solo i primari si migliorano le performance ???
-- 
The Follet

legge e scrive sui file px mentre gli altri scambiano cds con lui.
Posso farti un po' di domande sul funzionamento di Paradox ?
Mi perdonerete se non c'entra molto col topic del thread, ma
potrebbe essere d'aiuto.
Che differenza c'e', realmente, tra un db file-based come
Paradox e un client/server tipo Interbase ?
Quello che mi chiedo, in particolare, e' la differenza tra
fare una query su Interbase e una su Paradox (suppongo che
la base dati sia su una macchina remota).
Intuisco che, con Interbase, la query viene eseguita sul
server e in rete viaggiano solo le informazioni relative ai
record reperiti (che in caso di risultati corti potrebbero
essere poche migliaia di byte, no ?).
In caso di utilizzo con Paradox, invece ? la query viene
eseguita dalla macchina locale o comunque sulla macchina
remota ?
Nel caso venga eseguita sulla macchina locale che succede ?
viene trasferito l'intero contenuto della tabella e poi, da
locale, estratti solo i record richiesti ?
Usare il ClientDataSet con Paradox cosa comporta ? che la
query venga eseguita in remoto ? che si ricostruisca un
funzionamento simile a quello di Interbase, ovvero con un
client che riceve il risultato della query eseguita sulla
macchina remota ?
Quali sono i reali vantaggi dell'uso di TQuery rispetto alle
TTable ?
Vabbe', le domande sono un po' troppe, ma le risposte mi
sarebbero d'aiuto :)
-- 
The Follet

On Mon, 15 Oct 2001 20:50:50 GMT, Massimo Pini

Ti posso rispondere in base alla mia esperienza: lavoro su tabelle
MSSQL di discrete dimensioni (dai 100.000 ai 40.000.000 di record).
Lavorare senza indici secondari è impensabile.
Le query per utilizzare l'indice primario devono, per forza di cose,
utilizzare nella where *tutti* i campi, qualsiasi altra chiamata
effettua comunque un table scan, clustered o meno che sia la primary
key.
Il Table scan, non ci sono santi che tengano, è la morte del database:
al primo inner join, al primo bookmark lookup, o altro  che trovi non
solo vai a casa a salutare il gatto, dargli da mangiare e fargli
qualche carezza e quando torni  e la query non ha ancora terminato, ma
blocchi completamente il server.
La scelta degli indici secondari in un database SQL è una delle cose
in assoluto più importanti, anche più della bontà delle query.
L'unico vantaggio di non avere chiavi secondarie è il non dover fare
delle riorganizzazioni degli indici (e delle statistiche) ogni pochi
giorni, ma questi sono normalmente eseguiti in batch, di notte, e non
è un fattore.
Ciao,
Massimo.

In full table scan ci vai molto spesso se non stai attento, soprattutto se
non usi indici ;-)
Ci vai inoltre se usi la Exists in una subquery.
Attenzione, anche la order by rallenta le prestazioni dovendo creare un
buffer (tabella) temporaneo di appoggio per l'ordinamento.
Una buona norma per velocizzare le query è che le join "viaggino" su chiavi
primarie, mentre ci siano indici che interessano i campi coinvolti nelle
clausola where.
Spero vi possa essere di qualche aiuto
Ciaoux

lavorare ? sei sicuro ?
Sicuro. 


A Ube' ;-)
Lavorare lavorano, anche io programmerei con delphi6 su un 486.
Credo che il paragone di lentezza possa rendere bene l'idea.......


Puoi dare una giustificazione a questa affermazione?
-----------
Ore 18.30: premo invio.

 Sicuro. 
Adoro queste risposte piene di argomentazioni valide.
Che una query lavori lo stesso, nel senso che tiri fuori 
i dati richiesti, penso sia chiaro a tutti.  
A me non sembra che eliminando gli indici secondari si
arrivi ad una situazione conveniente, anzi li vedo (come gia'
e' stato confermato da chi e' intervenuto nel thread) come
una necessita'.
La tua proposta di eliminare gli indici per stabilizzare il PC
ed eliminare i crash la accetto, cosi' come accetto che per
non crashare con l'automobile, non bisogna guidare.
Ma guidare, la maggior parte delle volte e' necessario.
Se eliminare gli indici mi consente di evitare i crash ma
mi costringe a fare visita al nonno e portarlo al
parco, fintanto che non mi arriva il risultato della query,
preferisco usare qualche indice in piu' e aspettarmi qualche
crash ogni tanto.


crash ogni tanto.
Ma visto che possiedi tutta questa energia creativa perche' non fai delle 
prove al posto che costruire ardite metafore? ;)
Cmq io ho suggerito una soluzione che per me (e altri) ha funzionato.
Se ti interessa me l'ha suggerita Giuseppe Madaffari che e' una delle 
persone che conosce meglio il BDE in assoluto.
Se non ci credete fate delle prove e poi ne parliamo.


persone che conosce meglio il BDE in assoluto.
Forse però non conosce SQL.
Ciao.


Forse però non conosce SQL.
Perche' dici questo? Al di la' del fatto che lo conosce, anche se non lo 
conoscesse basta che conosca come vengono gestite le query SQL in Px.


 prove al posto che costruire ardite metafore? ;)
Le mie metafore sono bellissime... ma a parte tutto, sono molto pigro,
mi aspetto che le prove le faccia qualcun altro :)
E poi, aspetto i tuoi benchmark, no ? :)


 Ovviamente questo vale come regola generale con possibili eccezioni.
Ma ha senso parlare in termini di quante righe vengono *estratte* ?
Non e' piu' corretto parlare di quante righe subiscono l'elaborazione ?
Se la query ha molte condizioni di where e l'elaborazione va fatta su
una tabella con qualche milione di record, l'uso di indici secondari
perche' verrebbe evitato ?
Avere un indice su un campo in una condizione WHERE non e' forse un
fattore che aumenta la velocita' di ricerca per quel campo ?
Scusami, ma non riesco davvero a convincermi che quanto dici sia
vero, faro' delle prove e se avro' modo di darti ragione, giuro
che per punizione mi comprero' Laboratorio di Delphi 2^ ed. :))


 Forse però non conosce SQL.
Madaffari e' una persona in gamba (credo sia anche certificato da
Inprise) e puo' anche darsi che cio' che ha detto e suggerito a 
Uberto sia giusto e che Uberto stia dicendo una cosa corretta.
Quello che non riesco a spiegarmi e' perche' una query che estrae
qualche decina di record su qualche milione di record e con condizioni 
WHERE molto complesse, non dovrebbe utilizzare indici secondari ...


che per punizione mi comprero' Laboratorio di Delphi 2^ ed. :))
Anch'io sono molto perplesso. L'unica cosa che mi viene in mente è che
si tratti di un enorme malinteso e parliamo di cose diverse.
Seriamente.


WHERE molto complesse, non dovrebbe utilizzare indici secondari ...
Non lo metto in dubbio. Non lo conosco e mai mi permetterei di parlare
di una persona di cui non so nulla.
Fatto sta che domani creo un bel tabellone Paradox e faccio qualche
test :)


test :)
Fatemi sapere anche a me. Io l'ho proposta come soluzione che ha funzionato 
per me, non ho mai fatto prove generalizzate.
