Newsgroup: it.comp.appl.access
Titolo: impostare a -1 campo si/no dei record filtrati nella form

ho una maschera in visualizzazione record continui e apllico un filtro alla 
form usando vari filtri nella parte altra
avrei poi necessit� di impostare a -1 il campo di nome selezionato di tipo 
si/no dei soli record filtrati
 
qualcuno sa indicarmi la via?
 
grazie. 
 

Puoi usare  "RecordSet.Clone"  che è appunto una copia identica del 
set di record contenuti in quel momento dalla maschera e ti tiene conto di tutti i filtri applicati nei piu svariati modi
( praticamente solo quello che vedi a schermo )
 
Dim RSx As DAO.Recordset
Set RSx = Me.RecordsetClone
 
    Do Until RSx.EOF
        RSx.Edit
        RSx.Fields("NomeCampoBooleano") = True
        RSx.Update
        RSx.MoveNext
    Loop

Dim strSQL As String
strSQL="UPDATE T1 SET NomeCampo=TRUE WHERE " & Me.Filter
Dbengine (0)(0).Execute strSQL
 
Ovviamente sistema T1 ed il NomeCampo.....
Saluti
@alex

Grazie a entrambi, le sapete tutte!!!
 

Spero però tu abbia compreso l'enorme differenza tra i 2 metodi proposti.....
Solitamente nei Newsgroup si incentivato gli scambi tecnici spiegando le cose.... tu quale soluzione hai usato..? Perché. ..?
 
Saluti
@ALEX

Grazie a entrambi, le sapete tutte!!!
 
la seconda perch� pi� concisa, quali altri differenze ci sono? puoi 
illuminarmi?
 

> Spero però tu abbia compreso l'enorme differenza tra i 2 metodi proposti.....
 
Provo a rispondere anch'io che sto cercando di capire la differenza fra i 2 metodi
 
Faccio solo delle considerazioni che non vogliono essere risposte:
 
---- 1° considerazione:
qui  
http://msdn.microsoft.com/en-us/library/office/aa207086(v=office.10).aspx
   leggo che 
RecordsetClone corrisponde identicamente al RecordSource  ( origine Dati ) e non menziona
minimamente i filtri applicati ( o non applicati )
quindi sembrerebbe che usando il RecordSetClone  imposto a True TUTTI i record della tabella 
( mentre vogliamo impostare a True solo i record filtrati )
 
ma in effetti ho testato che non è cosi ......
 
---- 2° considerazione ( La ritengo fasulla,  comunque la cito  )
Abbiamo a che fare con un clone ( che sia filtrato o non )   poi eseguiamo
delle modifiche record per record al clone.
 
pertanto il clone si scosta dal suo originale .......
 
potremmo generare un errore imprevisto,   ma da test effettuati non mi è 
successo anche nel caso peggiore che il filtro sia proprio sul campo booleano
che stiamo aggiornando
 
---- 3° considerazione
Contrariamente a quanto citato da msdn ( punto 1 ) sperimento che il ciclo di aggiornamento
del RecordSetClone interviene NON su tutto il RecordSource ( la tabella di origine dati )  bensi solo 
sui record filtrati A CONDIZIONE CHE IL FILTRO SIA APPLICATO   ( ApplyFilter = True )
quindi agisce solo sui record "visualizzati a schermo"
 
---- 4° considerazione
Con UPDATE invece che e molto piu diretto preleva la stringa del filtro dalla proprieta Filter
pertandi si svincola dal fatto CHE IL FILTRO SIA APPLICATO O NON
 
 
Posso aggiungere che sia nel 3° che nel 4° caso il filtro puo essere modificato
dall'utente con i pulsanti di default della maschera ( se non inibiti )
pertanto un utente "sbadato" potrebbe .....
 
 
 
Quali sono le altre differenze che ci sfuggono ??
 
 
Grazie
 
 
 

 Quali sono le altre differenze che ci sfuggono ??
Per un "pugno di record" non dovrebbe essere rilevante la maggior 
velocitï¿œ di esecuzione della soluzione proposta da Alex.
Per "qualche record in piï¿œ" la differenza dovrebbe farsi sentire in 
modo evidente.
Se arriviamo sui 10000 record la soluzione Mancini non dovrebbe 
giungere a conclusione, salvo modificare nel Registry di Windows il 
parametro
MaxLocksPerFile.
 
Bruno
 
 

Santo Bruno.... meno male che esisti. 
 
La considerazione ovvia che si dovrebbe fare, a prescindere dal numero di Records pertinenti è di metodo....
È indiscutibile che ciclare RECORDS è meno efficiente che far eseguire l'azione al Server.....!
Se poi qualche utente invece di usare Jet usasse un qualsiasi altro RDBMS l'idea di ciclare in LOCALE invece di far lavorare un server fatto per questo sarebbe Assurda a dir poco.
Ne consegue per tutte queste considerazioni che l'uso di un predicato SQL rende anche il codice PORTABILE....!
 
Saluti
@alex