Newsgroup: it.comp.programmare.win32
Titolo: BCB3 e il componente DBGrid

Ciao ,
vi risulta che il componente DBGrid abbia un difetto nel trascinare la
casellina della barra di scorrimento verticale ?
A me ritorna o nella posizione iniziale o passa direttamente a quella
finale . Oppure si ferma esattamente a meta' ma a questa posizione non
corrispondono i record visualizzati nella tabella .
E' un difetto del componente o e' (spero) colpa mia ?
Uso il Borland Builder 3 standard .
grazie

E' un difetto del componente o e' (spero) colpa mia ?
Non è né colpa tua e neanche un difetto. Per posizionare
lo scroll box proporzionalmente, bisogna contare il numero
delle tuple presenti nel set dei dati ritornanti dalla query
e metterlo in relazione con la posizione attuale del cursore
nel set. Il fatto è che 'contare' quante tuple compongono una
relazioneè un'operazione molto onerosa da fare. Infatti non sempre 
il risultato di una query è il contenuto (anche parziale) di una
tabella (per la quale - forse - sarebbe semplice contare
il numero dei record). Molte volte le query sono particolarmente
articolate e potrebbero ritornare un set di tuple molto grande.
Questo costringerebbe, ad esempio un server, alla esecuzione
completa della query al solo scopo di contare le righe che
compongono la relazione descritta. Se la query definisce un join
un po' incasinato potrebbe trattarsi di un inacettabile spreco
di tempo e di spazio per avere una simile informazione. Infatti,
le tuple normalmente vengono fetch-ate a blocchi e non viaggiano
tutte subito dopo l'esecuzione della query dal server verso
il client per cui è difficile sapere prima quanta roba arriverà. 
È invece molto semplice sapere se un cursore associato 
ad una relazione è posizionato all'inizio o alla fine di un set 
di tuple. Quindi la DBGrid, che non vuole costringere il sistema 
ad operazioni computazionalmente onerose, mette lo scroll 
box all'inizio se sa che una certa proprietà denominata Bof (Begin 
of file) del DataSet è vera; mette lo scroll box alla fine se scopre 
che la proprietà del DataSet chiamata Eof (End of file) è vera; 
mette lo scroll box nel mezzo se nessuna delle due proprietà 
Bof ed Eof del Dataset è vera. Ecco perché le posizioni dello
scroll box, inevitabilmente, sono solo tre!
Comunque, per avere una informazione precisa sul numero
di record in un dataset (passante per il BDE), quando la proprietà
RecordCount non è precisa (e può capitare per il motivo descritto
sopra) puoi usare DbiGetExactRecordCount, una funzione 
del BDE: DbiGetExactRecordCount(Handle, &ExactRecordCount);
Ciao!
Giuliano

Non č né colpa tua e neanche un difetto. Per posizionare


stesso a farlo ?
Penso che tu debbe *scriverti* una tua TDBGrid. 
Ricordati che tu stai usando una TTable, ma questa - se avessi a che
fare con database remoto - potrebbe essere il risultato di una query
che corrisponde ad una tabella. Addiritura, quello che a te potrebbe
sembrare (attraverso una connessione ad un RDBMS) una tabella,
potrebbe essere una vista che a sua volta è il risultato di un join
complesso oppure un set ritornante da una stored procedure.
In tutti questi casi, anche se usi un TTable, dietro a tutto questo
potrebbe esserci uno dei suddetti "aggeggi". È time & resources
consuming tutto ciò, non si può rischiare di richiedere a priori
il numero di tuple: potrebbero volerci molti, troppi secondi.
La Borland ha preferito non richiedere mai tale informazione
al solo scopo di posizionare uno scroll box. Sono scelte, discutibili
o meno, ma sono scelte.
Ricordati inoltre che, avendo a che fare con DBMS orientati ai valori
(come i database relazionali) e non con DBMS orientati agli oggetti,
i "record", la quantità di "record" (o nel tuo caso di tuple), la
*posizione fisica* di un record (orrore), sono concetti che 
andrebbero tenuti in scarsissima considerazione.
Ciao
Giuliano