Newsgroup: it.comp.lang.visual-basic
Titolo: [?] Indicare un campo con ADODB.Recordset

Ciao ragazzi,
una piccola riflessione. L'altro giorno mi è successo questo problemino, che
ho risolto come dirò dopo, ma vorrei sapere se qualcuno l'ha già incontrato
prima di me. Dunque, ho aperto una connessione ad un db Access con
ADODB.Connection, poi ho aperto un recordset con ADODB.Recordset. Per
referenziare un campo di solito io faccio:
Tabella("Descrizione")=Me.txtDescrizione
dove Tabella è la mia ADODB.Recordset, "Descrizione" è un campo della mia
tabella. C'è anche un altro sistema per fare la stessa cosa, cioè:
Tabella!Descrizione = Me.txtDescrizione
Io di solito uso la prima sintassi; considero quest'ultima antiquata (la
usavo con VBA di Access 2.0 e compagnia bella).
Però l'altro giorno sono rimasto di stucco, perchè usando la solita sintassi
(la prima), il mio exe eseguiva un'operazione non valida (non mi ricordo in
che modulo, purtroppo), mentre correggendo l'istruzione con la seconda
forma, tutto si risolveva.
Era proprio una cosa sistematica, perchè ho continuato a fare un po' di test
e il bug si ripeteva: mettendo
Tabella("Descrizione")=Me.txtDescrizione
l'eseguibile (mentre da debug no), il programma si chiudeva inesorabilmente.
Come mai? Può essere che il compilatore tratti diversamente l'istruzione?
Sapete dirmi qualcosa?
Grazie, e good coding a tutti!!!
-- 
Damiani Liborio Igor
ig...@igordamiani.it
 - 
soft...@igordamiani.it
 - 
idam...@hotmail.com
http://www.igordamiani.it
ICQ : 11847262

Come mai? Può essere che il compilatore tratti diversamente l'istruzione?
In effetti e' curioso. Io uso indifferentemente l'una e l'altra forma,
ma non ho mai incontrato una situazione del genere. A dire il vero,
specifico *sempre* la proprieta' Value e non assegno praticamente mai
il contrenuto di un controllo senza prima averlo validato.
Potrebbe essere che nel tuo caso vb faccia casino con le proprieta'
predefinite.
Quindi:
Tabella!Descrizione.Value = Me.txtDescrizione.Text
anche perche', se ci pensi bene, esplicitamente Tabella!Descrizione
e'una reference ad un oggetto Field, mentre Me.txtDescrizione e' una
reference ad un oggetto TextBox. Se non si specifica la proprieta' cui
realmente ci si riferisce si mette il proprio destino nelle mani del
compilatore ;-)
-- 
ciao, hal

 forma, tutto si risolveva.
Mai successo, anche se uso sempre e solo la seconda (quella con !)
Domanda: il nome del campo era proprio "Descrizione"? Se no qual era?
E il valore assegnato poteva essere troppo lungo, contenere crt strani,
etc.?

il campo era proprio Descrizione e giusto per fare i test avevo provato a
salvare anche una semplice stringa fissa come "A". Cioè, per esteso:
Tabella("Descrizione") = "A"        (errore)
Tabella!Descrizione = "A"              (OK)
mah, veramente strano.
good coding!!!


 ha scritto nel messaggio
news:bbirb6$9rf3s$1...@ID-134521.news.dfncis.de...


 Tabella.Fields(I_Descrizione) = Me.txtDescrizione
Cioè? Se domani cambia, perchè ristrutturi una tabella dovendo
togliere/aggiungere campi, quel che in DAO si chiama OrdinalPosition, devi
rincorrere tutti i numeri dei campi?
No, mi sembra sinceramente masochistico, assurdo e concettualmente errato.

 Cioč? Se domani cambia, perchč ristrutturi una tabella dovendo


già, anche io lo trovo scomodo.....
piuttosto che usare banali costanti, a questo punto userei gli Enum, no?
cmq per le prestazioni è sicuramente meglio usare valori integer per far
riferimento ai campi, è sicuramente più veloce!!!
good coding!!!


 Cioč? Se domani cambia, perchč ristrutturi una tabella dovendo


 memorizziamo ecc...ecc...
Memorizzare (numeri o stringhe)? Perchè? Non capisco... :-(
Quel campo si chiama Pippo e tale si chiama ovunque, non c'è bisogno di
memorizzarne il nome (o il numero) in una costante.

 ha scritto nel messaggio
news:bbkplh$amec5$1...@ID-174464.news.dfncis.de...


 dappertutto...
Ma il nome di un campo è già "costante" di per se stesso, no?!

 ha scritto nel messaggio
news:bbkr9e$ajhgh$1...@ID-174464.news.dfncis.de...


ok, ragazzi, basta cosě!!! la mia era una semplice domanda per capire un
problema che avevo avuto!!!! qui sta diventando una disquisizione
tecnica....
:-))) mi ci metto in mezzo anche io, allora, dato che ci siamo
cmq, trovo piů logico usare i numeri solo per motivi di prestazione. se ho
un ciclo Do...While che si fa passare 10.000 record fatto cosě:
Do while Rs("Descrizione")
    Msgbox Rs("Descrizione")
    Rs.Movenext
Loop
il compilatore ad ogni ciclo deve "capire" tramite il nome del campo la sua
posizione ordinale nella struttura della tabella, per cui (specialmente se
la tabella č molto grossa) potrebbe essere un poco dispendiosa in termini di
ciclo macchina. Se invece uno mette Rs(12), per dire, č tutto piů veloce.
good coding!!!


 Do while Rs("Descrizione")
intendi:
Do while not Rs.EOF  ? ;-))


pignolo!!!!!
e impara a quotare, se no qui un sacco di gente si arrabbia.....
riporta solamente la parte *clou* del post, altrimenti........viene quasi
plonkato!!!!!
:-))))


 ha scritto nel messaggio
news:bbkv7m$ai7ev$1...@ID-134521.news.dfncis.de...


 variabile che si chiama Descrizione)
Lascio anche il resto, sotto.
Il campo si chiame "Descrizione", giusto?
Bene, si chiamerà sempre "Descrizione", in questo senso (sempre fra
virgolette) è "costante".
Se devo riferirmi al campo mi basta rs("Descrizione") o rs!Descrizione.
Mi spieghi qual è l'utilità di fare:
Const Campo_Descrizione=123
rs(Campo_Descrizione)
Io, insisto, vedo solo svantaggi. Credo che se quel 123 (immagino delle
Select senza * che possono cambiare nel tempo per diverse esigenze) deve
cambiare, tu impazzirai, mentre il nome del campo non cambia mai.


 ha scritto nel messaggio
news:bbl1sk$aec1q$1...@ID-174464.news.dfncis.de...


partendo dal presupposto che sono d'accordo con te, però immagina:
nel codice hai scritto centinaia di volte rs("Descrizione")
oltre alla perdita di performance che ho detto prima, se definisci una const
globale che fa riferimento al campo, basta che vai lì, modifichi la const e
tutto il codice è corretto. Io a questo punto preferirei però usare gli
Enum.
sono d'accordo con i rischi di cui accennato, come il cambiamento
dell'ordine dei campi in un'eventuale "select *". Non solo: supponendo di
modificare la struttura del db via codice, con alter table, per
aggiungere/rimuovere campi, effettivamente c'è un bel rischio.....mah!!!!
Non per niente io alla fine me ne sbatto di queste considerazioni tecniche e
prediligo la leggibilità del codice, senza star lì a dichiarare const e
compagnia bella.
Però i suoi vantaggi ci sono.
good coding!!!


 che un campo esistente cambi di nome...
Ok, mettiamola così: Dov'è la maggiore probabilità?
Comunque, e qui finisco, ognuno decide come meglio crede.
La mia scelta l'ho detta.

prediligo la leggibilità del codice, 
Questo e' un ragionamento sensato :-)
-- 
ciao, hal
ma chi e' cosi' matto da cambiare i nomi dei campi nei database?

 Questo e' un ragionamento sensato :-)
hal, l'uomo dai mille volti... :-(

hal, l'uomo dai mille volti... :-(
Questa non arrivo a capirla...
-- 
ciao, hal

[*hal1961* : 
aldoc...@inwind.it
] ha scritto:

Intendo dire che spesso ti ho visto (giustamente, nessuna obiezione)
"Non sbattertene affatto di considerazioni tecniche"

"Non sbattertene affatto di considerazioni tecniche"
Be', nelle considerazioni tecniche inserisco anche il deployment, la
manutenzione e l'estensione del software oltre al confronto fra costi
e benefici di eventuali ottimizzazioni.
-- 
ciao, hal