Newsgroup: it.comp.lang.visual-basic
Titolo: [2] Problema gravissimo ADO (era: TrueDbgrid)

(come suggerisce Lupo ho sostiuito TrueDbgrid con ADO)
E' incredibile (per me): modifico un record con la TrueDbGrid (sto
provando 
la versione 7 con ADO), esco e subito leggo il record modificato (ho 
provato sia con DAO che con ADO).
Risultato: vede il record vecchio!!!!!!!
Se invece aspetto qualche secondo vede il record aggiornato!
Cosa puo' essere???
USO SEMPRE LA STESSA CONNECTION
HO RINFRESCATO TUTTO IL POSSIBILE (ho aperto anche le finestre di
casa) MA NIENTE
Grazie
Gianluca

 Gianluca

 ha scritto nel messaggio
news:hdovsuodrot23hshe...@4ax.com...


 numero di client elevato è sicuramente la scelta sbagliata
Cioè secondo te il cursore lato server è in generale meno performante di
quello lato client? :-|
PS:
Il quoting per cortesia! ;-)

ehm, mi intrometto con la delicatezza dell'elefante.....
[ castelmare.f] wrote:
non ti aggionra il recordset percè usi un cursore sbagliato dovresti
provare con un cursore lato server aggiornabile in questo modo vedi
sia i tuoi
aggiornamenti che quelli degli altri ma se devi distribuire su una
erete con un
numero di client elevato è sicuramente la scelta sbagliata
peccato che il recordset con cursore lato server non sia utilizzabile come
fonte dati per i datagrid.......(provare per credere)
[Lord Rayden]ha scritto nel messaggio news:aqqc28$150a$1...@half.spin.it...
 Cioè secondo te il cursore lato server è in generale meno performante di
quello lato client? :-|
beh, credo che la segnalazione di castelmare sia leggermente diversa: il
cursore lato server è meno scalabile: aprendo il recordset sempre sulla
macchina server, all'aumentare delle connessioni le prestazioni decadono
rapidamente. Il cursore lato client pone altri problemi, ma usato in
modalità disconnessa permette una scalabilità pressochè illimitata. (tra
parentesi credo sia questo il motivo per cui .Net spinge molto sul lato
client disconnesso, oltre per il fatto che "costringe" ad avere macchine
client più "performanti")
Salutoni


CUT
....che comunque esula da tutto il thread perchè le TDBgrid sono una
razzaccia a parte ed ogni tanto si "piantano" alla faccia di lato client
server master blaster disaster e finester!!!!!
:-)

 >
tanto per andare OT....l'unica cosa dell TDBgrid che ho trovato (ma
probabilmente smanettando si fa anche con una flexgrid e un po di
subclassing) č la gestione dell'evento click....che come si sa se fai click
in bound ti riporta il record precedente (....deve essere la sequenza degli
eventi per cui click viene prima dell'aggiornamento posizione record)
con le TDBgrid
Private Sub gTesto_Click()
gTesto.PostMsg 7 'ad esempio
End Sub
...
Private Sub gTesto_PostEvent(ByVal MsgId As Integer)
On Error Resume Next
Select Case MsgId
    Case 7
        mSERIALETESTO = gTesto.Columns(0).Text
        txtSelTesto.Text = " Segnatura: " & gTesto.Columns(6).Text & "
Testo: " & mID(gTesto.Columns(4).Text, 1, 40) & "...(etc)"
End Select
On Error GoTo 0
End Sub
mi da le info proprio del record della riga su cui clikko (perchč scatena un
evento al termine di tutti gli altri eventi della griglia...almeno
presumo!).....cosa che con una griglia normale...costringe a sforzarsi un po
di piů

 "costringe" ad avere macchine client più "performanti")
E cablature in fibra ottica! :(

 ha scritto nel messaggio
news:aqqiig$1a3e$1...@half.spin.it...

il problema da te segnalato non è assolutamente banale, in effetti, nel caso
di cursori lato client, bisogna sempre porre attenzione alla quantità di
dati caricati nel recordset (i "select * from nometabella" sarebbero proprio
da evitare) resta comunque il fatto che queste cautele sarebbero comunque da
applicare, al di là del tipo di cursore utilizzato.
Spesso mi rendo conto che apro tabelle senza "filtri" solo per la pigrizia
di scrivere un paio di righe di codice....
Salutoni
Sergio