Newsgroup: it.comp.lang.visual-basic
Titolo: [LUNGO] ADO e mdb, quesiti vari....

Ciao, premetto che il concetto è un pò "astruso" forse perchè è la prima
volta che utilizzo ocx e ADO.
Ho realizzato un OCX contenente una 20ina di textbox ciascuna collegata ad
un ADODB.Recordset
L'ADODB.REcordset è una variabile interna all'ocx e fa riferimento ad un
ADODB.Connection esterno all'ocx.
Io lancio il progetto creo la connessione:
   Dim db As ADODB.Connection
   Set db = New ADODB.Connection
   db.CursorLocation = adUseServer
   db.Mode = adModeShareDenyRead
   db.Open "PROVIDER=Microsoft.Jet.OLEDB.4.0;Data Source=" & App.Path &
"\Collaudi.mdb;"
e fin qua tutto ok.Poi questa connessione la passo attraverso una property
al mio ocx anzi ai miei ocx (48)
   For i = 0 To 47
      DettaglioPompa1(i).nome_Connessione = db
   Next i
All'interno dell'ocx gestisco così la property:
Se voglio che i 48 ocx facciano riferimento ad una connession è giusto
mettere ByRef oppure è indifferente?
Public Property Let nome_Connessione(ByRef dbOCX As ADODB.Connection)
   Dim oText As TextBox
   Dim i As Integer
   Set adoPrimaryRS = New ADODB.Recordset
   'apro la connessione col record
   adoPrimaryRS.Open "SELECT * FROM Bollettini WHERE NumBollettino = " & num
& " Order by NumBollettino", dbOCX, adOpenStatic, adLockBatchOptimistic,
adCmdTableDirect
   'Associa le caselle di testo al fornitore di dati
   Set UserControl.labelCorrente_Ist.DataSource = adoPrimaryRS
   For i = 0 To txtFields.Count - 1
     Set UserControl.txtFields(i).DataSource = adoPrimaryRS
   Next i
end property
Praticamente ogni OCX fa riferimento ad un riga della tabella Bollettini del
file Collaudi.mdb.
Il tutto però risulta essere lento e le modifiche nel database le vedo a
scatti di 5 secondi. E' una propietà modificabile? Oppure lo devo tenere
così?
Il database è Access e alla fine lo collego ad una pagina html consultabile
da un qualsiasi pc in rete, vorrei una cosa quasi in tempo reale.

 così?
Non mi intendo molto di ocx e roba simile.
Ma come mai assegni a circa 48*20 txt altrettanti recordset?
Non dovresti collegare ogni txt ad un campo dello STESSO recordset?
-- 
DBMS Firebird
VB6 + Ado

"Andrea" <nos...@invalid.invalid> ha scritto nel messaggio
news:1of69lceinzd6$.1wqd3f2smsdom$.dlg@40tude.net...

Forse mi sono spiegato male, io collego 48 ocx ai 48 record di una tabella
ogni txt è collegato ad un campo del record puntato dal suo ocx.
In altre parole un ocx gestisce una riga della tabella, e un txt gestisce un
campo della riga gestita dall'ocx.
Cmq forse ho scoperto come mai è lento.....
sbaglio metodo di debug. Cioè per vedere il db che si aggiorna ho creato
velocemente un form con una MSFlex, un controllo DAO e un timer a 200ms.
Ora ho rifatto il form usando una MSHFlex però stavolta uso un controllo ADO
sempre col Timer a 200ms...
Aggiornamento a 1-2secondi

 Aggiornamento a 1-2secondi
Per il motore Jet ~2 secondi di latenza sono normali: il jet ha una cache 
che di default può arrivare a 2 secondi prima di scrivere fisicamente i dati 
su disco.
Per forzare la cosa devi guarare i parametri per DBEngine.Idle: uno di 
questi forza proprio il flush dei dati.
Non so se esiste qualcosa di simile via ADO.
Ciao 

 campo della riga gestita dall'ocx....
Ma è orribile tutto ciò!!
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/


....è orribile tutto ciò,  secondo me ti converrebbe........
Continua pure, so benissimo che tutto ciò è orribile

 Continua pure, so benissimo che tutto ciň č orribile
Non ti merita mettere tutti i dati in una grid invece che in delle txt?
Oppure caricare di volta in volta un record sulle txt e non tutti insieme?


 > Ma è orribile ...
Dunque, spero che tu sappia già le cose che ti dico adesso, altrimenti il
problema non è davvero la lentezza del tuo programma.
Un database nasce per poter contenere un numero *variabile* di record: può
contenerne solo uno, o essere vuoto, o contenere centomila record (come il
titolo del romanzo di Pirandello, "Uno, nessuno e centomila", che però non
parla di database...). Quindi è estremamente improbabile, anzi
concettualmente inutile avere una tabella in un database con un numero fisso
di record: è come se uno creasse una tabella DitaUmane, che contiene
1-pollice sx, 2-indice sx, 3-medio sx, .... ecc. Questa tabella non
aumenterà mai i suoi record, quindi non serve una tabella, basta un normale
file di testo per memorizzare queste informazioni, o al limite possono
essere anche memorizzate nel codice stesso.
A onor del vero, ci sono dei casi in cui certi gruppi ben precisi di dati
vengono memorizzati in una tabella, per comodità di programmazione. Ad
esempio le provincie italiane potrebbero venire archiviate in un file di
testo, ma di solito viene creata una tabella Provincie. Tra l'altro sono
state recentemente aumentate, quindi la tabella si è rivelata utile e il
file di testo dovrebbe invece venire aggiornato.
In nessun caso però un programmatore dovrebbe strutturare un'applicazione
database come se i record fossero sempre la stessa quantità, perché verrebbe
meno il principio stesso dei database.
Tu assegni un controllo ad ogni record. In una applicazione database il
numero dei record potrebbe variare, e di conseguenza gli ultimi aggiunti non
avrebbero il loro controllo, e quelli eliminati lascerebbero i loro
controlli non assegnati. Cioè, il caos.
In una applicazione strutturata come la tua devi prevedere anche un sistema
per impedire all'utente di aggiungere o rimuovere record, perché altrimenti
manderebbe un pappa tutto l'ambaradàn. E ciò significa: "...hai un database,
ma non lo usi come un database...", cioè, io ti installo tutto il software
per gestire il db, lo carico in memoria, lo avvio, e poi lo tengo fermo: é
come andare a comprare il giornale con la ruspa.
Per ogni record devi fare un'assegnazione, aprire una connessione, e
caricare un recordset. E naturalmente alla fine ricordarti di chiudere e
distruggere tutti i recordset, le connessioni e le istanze degli ocx. Mi
meraviglio che sia soltanto lento: io mi aspetterei un messaggio di errore
del tipo "MSADO Error [ODBC] -1234567890: EHI, ZIO, PER CHI MI HAI
PRESO?!..."
Utilizza una grid, e UN SOLO recordset, come ti è già stato suggerito.
Qualunque sia la funzionalità aggiuntiva che ha il tuo ocx, puoi sempre
cercare di simularla da codice per applicarla alla grid. Vedrai dopo il
programma come fila.
Se invece quello che ho scritto non lo sapevi, bisogna partire con un buon
libro sui database.
Spero ti sia utile. Ciao.



Certo è grazie a te che c'è un ignorante in meno sulla terra!
Ciao


 Certo è grazie a te che c'è un ignorante in meno sulla terra!
Per così poco? Grazie ma non merito tanto. Ciao.


 Lodevole intento. Cosa c'entra l'OCX?
Sia OCX che ADO sono new entry,  poi, visto che il lavoro è stato affidato
ad uno stagista (= si accettano anche tempi lunghi di sviluppo), ne ho
approfittato...
Ciao