Newsgroup: it.comp.appl.access
Titolo: Gestione CAMPI su QUERY da VBA

Ciao a tutti!
Devo scrivere una routine in VBA che mi permetta di scrivere un determinato
valore in un campo di una query.
Dietro vostro consiglio mi sono studiato il modo di accedere ad un recordset
ma ora mi sono bloccato nella gestione dei campi.
Come si fa?
Il codice è il seguente:
   Dim DBCorrente As Database
   Dim Rst As Recordset
   Set DBCorrente = CurrentDb()
   Set Rst = DBCorrente.OpenRecordset("Qry ESAMI", dbOpenDynaset)
   Rst.MoveFirst
   Do Until Rst.EOF
     Rst.MoveNext
   Loop
   Rst.Close
Ho effettuato varie prove ma non ci sono riuscito.
Qualcuno può darmi una mano?
Ringrazio anticipatamente tutti quanti

 ha scritto nel messaggio
news:9i5mdh$hmr$1...@lacerta.tiscalinet.it...

A meno che la tua query non sia una query parametrica (nel qual caso rifatti
vivo postando il codice SQL della query), il modo di aprire il recordset e
di impostare il ciclo Do ... Loop mi sembra corretto. Cosa non ti funziona?
Che errore ricevi da Access?
Comunque c'è una cosa che non quadra, ma è di tipo logico e non riguarda la
sintassi del codice VBA; una query è un recordset virtuale, pertanto puoi
aprirlo solo per leggerlo ma non puoi aggiornarlo con i metodi Edit e
Update: questo puoi farlo solo aprendo un recordset su una tabella, che è un
recordset reale.
--
Roberto
---------------------------------------------
il Sito Comune di it.comp.appl.access:
http://www.sitocomune.com
---------------------------------------------

Ciao Roberto,
il codice funziona ma quello che non ho ancora capito č come andare a
scrivere dei valori sui campi della query.
Sicuramente sbaglio la sintassi.
Quello che tu dici sulle query č vero ma a me va bene cosě in quanto devo
solo scrivere un valore temporaneamente. Una volta che, in base a questo
valore, riesco ad ordinarlo e ad effettuare la stampa posso anche scartarlo.
Cmq c'č una cosa che non ho ben capito:
se effettivamente una query č un recordset virtuale (come anch'io sapevo)
allora perchč quando faccio una query di una tabella e tramite maschera
modifico un dato la modifica mi si ripresenta sulla tabella?
Effettivamente ero convinto che estrapolando i dati potevo lavorarli senza
danneggiare la tabella ma invece cosě non č. Sai darmi qualche indicazione
in merito?
Grazie
FACE ONE


Si dice che una query è un recordset virtuale in quanto le sue righe
risultanti non hanno dei record equivalenti registrati su disco.
Ciò non toglie che, se un campo di una query è associato ad un campo della
tabella su cui la query è basata, se modifichi il valore del campo della
query verrà automaticamente modificato anche il relativo campo della tabella
sottostante; naturalmente ciò avviene a condizione che la query sia di tipo
aggiornabile.
Insomma, anche se improprio dirlo, è un pò quello che avviene con i
controlli di una maschera nei confronti dei campi di una tabella ad essi
associati.


Ciao Roberto,
ora mi è molto più chiaro. Facevo confusione.
Grazie dellaa spiegazione.
Per quanto riguarda l'accesso ai campi ci sono riuscito dopo vari tentativi.
Decisamente sbagliavo sintassi.
Grazie
FACE ONE

Ciao innanzitutto.
Perchč non apri un Recordset con istruzione SQL, in questo modo estrai solo
il Record o i Record che ti servono,
poi l'oggetto Recordset modifichi cosě:
Rs!Campo1=Valore1
Rs!Campo2=Valore2
Rs.movenext (se devi proseguire inserisci Do until Rs.Eof ......Loop)
ecc.....
Ciao Alex.
-- 
Posted from [212.141.54.103] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

Ciao.
Per quanto riguarda il discorso di accedere ai campi di una query sono
riuscito a risolverlo con le seguenti righe di codice:
   .......
   Rst.MoveFirst
   For C = 1 To N
        Rst.Edit
        Rst.Fields("ANNI").Value = V
        .........
        Rst.Update
        Rst.MoveNext
   Next C
   Rst.Close
Quello che non sono però riuscito a capire è cosa intendi per aprire un
Recordset con istruzione SQL.
Quello che faccio in questo momento è aprire un Recordset su di una query
che preleva i dati da una tabella. Quello che dici tu è un altro
procedimento?
Grazie del tuo aiuto
FACE ONE

Ciao, diciamo che ti ho fatto confusione, soprattutto perchè quello che 
ti dicevo ha senso se utilizzi oggetti DAO o ADO per l'accesso ai Dati 
in un altro DB.
Io solitamente separo l'applicativo in n°2 DB:
1)Interfaccia utente con Maschere e report
2)Dati, con tabelle e Query.
Il sistema è comodo perchè se devi fare modifiche sull'interfaccia 
utente hai meno problemi, di dimensioni per il trasporto e molti altri.
Questo a parte, quello che hai fatto va bene, io aggiungerei :
 
  rst.MoveLast
  N=rst.RecordCount
  Rst.MoveFirst
  For C = 1 To N
  Rst.Edit
  Rst.Fields("ANNI").Value = V
  Rst.Update
  Rst.MoveNext
  Next C
  Rst.Close
O meglio:
 With Rst 
  Do Until .Eof
   .Edit
   .Fields("ANNI").Value = V
   .Update
   .MoveNext
  Loop
 end With
Il campo Fields può essere indicizzato (Es. Rst.Fields(0).Value=xx)
Dove l'indice è chiaramente ordinato in base all'indice dei campi nella 
tabella, ti può tornare utile se devi fare cicli in cui hai indicizzato 
anche delle TextBox(1 to x) allora quando editi o aggiungi un Record o 
esegui la dichiarazione campo per campo o indicizzi tutto. 
With Rst
  dim x as Integer
  Do Until .Eof
   .Edit
   .Fields(x).Value = TextBox(x).text
   .Update
   .MoveNext
   x=x+1
  Loop
 end With
 In questo modo ti crei una maschera di controlli non associati, il 
ciclo come vedi è cortissimo in questo modo, se avessi avuto 20 campi 
avresti con il tuo sistema dovuto dichiarare singolarmente ogni campo e 
ogni TextBox.
Come sempre spero di non aver distrutto un tuo mito o sconquassato 
troppo il terreno.
Ciao Alex.
-- 
Posted from 146.133.1.30 by way of 
smtp2.libero.it
 [193.70.192.52] 


Avevo inviato la risposta dall'ufficio, ma non si è collegata bene,
RIPOSTO....
Ciao, diciamo che ti ho fatto confusione, soprattutto perchè quello che
ti dicevo ha senso se utilizzi oggetti DAO o ADO per l´accesso ai Dati
in un altro DB.
Io solitamente separo l´applicativo in n°2 DB:
1)Interfaccia utente con Maschere e report
2)Dati, con tabelle e Query.
Il sistema è comodo perchè se devi fare modifiche sull´interfaccia
utente hai meno problemi, di dimensioni per il trasporto e molti altri.
Questo a parte, quello che hai fatto va bene, io aggiungerei :
  rst.MoveLast
  N=rst.RecordCount
  Rst.MoveFirst
  For C = 1 To N
  Rst.Edit
  Rst.Fields("ANNI").Value = V
  Rst.Update
  Rst.MoveNext
  Next C
  Rst.Close

-- 
Posted from [212.141.54.103] 


Ciao Alex,
scusa se ti rispondo dopo alcuni giorni ma ho avuto dei problemi con il PC.
Innanzitutto ti ringrazio per la risposta.
Attualmento l'applicazione è stata divisa in due DB:
uno contenente il FRONT END, quindi maschere e report mentre sul DB vero e
proprio ho messo tutte le tabelle.
Domanda: ho messo le query sul DB e non sul FE. E' giusto? o è meglio
mettere, come mi suggerisci tu, le query sul FE?
Per quanto riguarda l'accesso ai campi non immagini che favore mi hai fatto!
innanzitutto il metodo ce dici funziona perfettamente ma l'indicizzazione
dei campi che mi hai suggerito mi ha risolto un altro problema o meglio me
lo ha semplificato di molto.
GRAZIE
FACE ONE

Ciao, sono contento di aver contribuito.
Se leggi bene il mio Post precedente ho scritto che nel DB_Dati metto
Tabelle e Query.
Il collegamento cosě come ti ho illustrato č anche rovesciabile, ovvero se
utilizzi uno scorrimento di record puoi utilizzate le TextBox per
visualizzare il contenuto del record corrente.
Buon Lavoro Alex.
-- 
Posted from [212.141.54.102] 


Ciao Alex,
grazie del tuo aiuto.
Quello che non mi è ancora chiaro è se mettere le query nel FE o nel DB
DATI. Quali sono le differenze?
Io pensavo che fossero meglio metterle nel front end ma tu mi suggerisci il
contrario. E indifferente oppure no?
Grazie
FACE ONE

Io metto le QRY nel DBDATI.mdb.
Questo perchè in realtà io non utilizzo ACCESS, ma Visual Basic, quindi non
ho alternative, ma credo, sia molto più veloce recuperare un pacchetto dati
filtrato, quindi ridotto rispetto ad una Tabella Piena, e filtrarlo poi nel
FE.
Sostanzialmente non dovrebbe cambiare altro, perchè i DATI rimangono la
parte fondamentale ed è quella nel DBDATI.
In Visual Basic è molto più veloce una Query già esistente nel DB piuttosto
che ralizzare una Query SQL per l'estrazione dati.
In più è possibile gestire le varie possibilità che si danno all'utente
direttamente leggendo le QUERY presenti nel DB, e nel caso si debbano
prevedere altre condizioni basta inserire una nuova QUERY nel DB e non
toccare il FILE.EXE, che comporta grossi problemi, ricompilazione sarebbe il
minimo, più che altro le modifiche magari dopo qualche anno, sono molto
dispersive.
In questo modo metti una Routine che legge le Query (Nominare appositamente
per essere gestite) nel File.EXE ed il gioco è fatto, quanto impieghi ad
aggiungere una QRY in DB??? 2minuti.
