RecordSource vs Filter - chi vince?

[RobertoA]

Supponiamo abbiate una form continua
Nel form load ci mettete

---------------------------------------
RecordSource=" select * from ARTICOLI where 1=0"

Filter="CODICE_ARTICOLO='123' "
FilterOn=true
--------------------------------------

Qual'e' la condizione buona, la prima o la seconda?
Voi come operate solitamente?
Usate il where direttamente nella stringa che viene impostata sul
RecordSource o je date giu' a colpi di Filter ?

[Simone Calligaris]

Meglio fare tutto direttamente nel recordsource, altrimenti prima viene caricato il Recordset origine della Form e poi applicata una "nuova query" sui dati (il Filter) per l'ulteriore estrapolazione.

Saluti

[Michele]

se si suppone che l'utente possa togliere il filtro e vedere gli altri record, uso filter
se voglio evitare che l'utente possa togliere il filtro uso recordsource

[RobertoA]

Ok, onde evitare doppia selezione, e quindi per migliorare le
prestazioni, e' meglio fare solo una delle due

Ma nel caso ci siano entrambe, chi vince?

[RobertoA]

Selezione si e no la puoi fare anche col RecordSource, basta che
modifichi quel che c'e' dopo il where
E quindi, perche' usi anche il Filter?

E per secondo, se c'e' la selezione sia sulla stringa del RecordSource
che sul Filter, chi vince?

[Simone Calligaris]

> Ma nel caso ci siano entrambe, chi vince?

???
Fai tutto una volta sola nell'origine dati e basta!

Saluti

[BFS]

con un db client-server ovviamente la prima
BFS

[RobertoA]

Ok, anch'io avrei risposto cosi' perche' il Filter non lo uso mai
Vorrei pero' capire se sto Filter c'ha la sua ragione d'esistere oppure
(come le macro) anche se non lo consideriamo viviamo bene lo stesso
E quindi la domanda e': supponendo di inserire i criteri di selezione
nella nostra RecordSource, il Filter a che potrebbe servire?
Voglio dire, se gia' col RecordSource si possono fare tutte le selezioni
possibili, e pure piu' veloci, che ce sta' a ffa' il Filter ?

[@Alex]

> Ok, anch'io avrei risposto cosi' perche' il Filter non lo uso mai
> Vorrei pero' capire se sto Filter c'ha la sua ragione d'esistere oppure
> (come le macro) anche se non lo consideriamo viviamo bene lo stesso
> E quindi la domanda e': supponendo di inserire i criteri di selezione
> nella nostra RecordSource, il Filter a che potrebbe servire?
> Voglio dire, se gia' col RecordSource si possono fare tutte le selezioni
> possibili, e pure piu' veloci, che ce sta' a ffa' il Filter ?

Su questo argomento si fece svariati anni fa una discussione abbastanza animata...

Considerando di avere un BE costituito da un RDBMS, a suo tempo era SQL_SERVER, la proprietà Filter sembra venga interpretata dal Driver SQL in modo intelligente se interpretabile lato SERVER, e restituisce solo i records coernti con il criterio, cosa che un po contrasta conquanto dice Simone.

Ora a suo tempo, mi pare fosse Giorgio ad aver verificato con gli strumenti di Managment di SQL_SERVER che effettivamente fosse così, ovvio che la scrittura e di conseguenza la risoluzione del Predicato è fondamentale, ma questo lo è anche nel caso si lavori sul RecordSource.

Se infatti si scrive una cosa simile:
SELECT * FROM T1 WHERE Id=Forms!NomeForm!Id
è evidente che puoi gestirla tramite Recordsource ma l'effetto finale è che il SERVER ti sputa tutta la tabella in locale e poi JET applica la WHERE CONDITION.

Da quanto ricordo, purtroppo però ho solo un ricordo, applicando la proprietà FILTER in modo Risolvibile lato server, quindi non :
Id=Forms!NomeForm!Id ---- ma Id=275, all'applicazione del nuovo Filter il RS finale è solo il Filtrato.

Servirebbe in effetti fare una verifica con SQL_SERVER MANAGMENT che se non ricordo male rende possibile controllare l'efficacia dell'interrogazione SQL, come viene risolto il predicato e quanti Records vengono restituiti lato SERVER, questo darebbe la chiara percezione della reale funzionalità del metodo.

@Alex

[Simone Calligaris]

> Considerando di avere un BE costituito da un RDBMS, a suo tempo era SQL_SERVER, la proprietà Filter sembra venga interpretata dal Driver SQL in modo intelligente se interpretabile lato SERVER, e restituisce solo i >records coernti con il criterio, cosa che un po contrasta conquanto dice Simone.

In realtà ho contestato a RobertoA un'altra cosa: nel suo esempio fa eseguire ad Access due "query": prima quella che carica il l'origine Dati della Form e poi una successiva (sebbene mascherata) che effettua un secondo filtro sui dati.
Nell'esempio che lui ha fatto è una soluzione svantaggiosa, il che non significa che la proprietà .Filter operi sempre lato Client (e ci mancherebbe: se potessimo vedere i Sorgenti di Access possiamo star certi che .Filter invia al Server ODBC una normale Query SQL, eseguibile lato Server alle giuste condizioni).

Ciao: Simone

[Simone Calligaris]

> Ok, anch'io avrei risposto cosi' perche' il Filter non lo uso mai
> Vorrei pero' capire se sto Filter c'ha la sua ragione d'esistere oppure
> (come le macro) anche se non lo consideriamo viviamo bene lo stesso
> E quindi la domanda e': supponendo di inserire i criteri di selezione
> nella nostra RecordSource, il Filter a che potrebbe servire?
> Voglio dire, se gia' col RecordSource si possono fare tutte le selezioni
> possibili, e pure piu' veloci, che ce sta' a ffa' il Filter ?

Filter è una proprietà utilissima per un mucchio di cose (pensa agli strumenti di "Filtro Avanzato" che si possono creare tramite essa, utilizzabili anche nelle Anteprime dei Reports).
Ma nell'esempio che tu hai fatto è una soluzione ridondante, svantaggiosa.

Saluti

[@Alex]

Magari ho capito male, ma Roberto credo voglia aprire la Tabella con nessun Record per ottimizzare i tempi di apertura ed applicare poi un criterio...
Tantè che la SELECT impostata avendo WHERE 1=0 non restituisce nulla.
Purtroppo a quel punto FILTER non restituirà mai Nulla, quindi non so se definirlo "svantaggioso" con l'esempio specifico postato fatto sia giusto, a mio avviso così scritto, il FILTER viene applicato in concatenazione alla WHERE del Recordsource e non restituendo mai nulla è proprio sbagliato.

Se eventualmente si sta parlando di velocità di caricamento, si lascia il RecordSource vuoto e lo si applica in un istante specifico a richiesta, e poi di conseguenza i FILTER.

Non so magari ho frainteso io tutta la questione...
@Alex

[RobertoA]

La domanda sostanziale e': supponendo di lavorare SOLO col RecordSource,
ci perdiamo qualche funzionalita' particolare se non usiamo il Filter?
Mi sembra di capire che la risosta sia: NO non ci perdiamo niente, si
puo' fare tutto col RecordSource

[Simone Calligaris]

> La domanda sostanziale e': supponendo di lavorare SOLO col RecordSource,
> ci perdiamo qualche funzionalita' particolare se non usiamo il Filter?
> Mi sembra di capire che la risosta sia: NO non ci perdiamo niente, si
> puo' fare tutto col RecordSource

Su apertura Form puoi implementare qualunque "filtro" nella condizione Where della stringa recordsource, quindi in tale contesto non ha senso aggiungere un .Filter.
Comunque, sono quasi certo che anche in questo caso è la seconda o terza volta che poni la questione.

Saluti

[@Alex]

La Where condition di Openform va a popolare proprio la proprietà FILTER infatti.
Per il resto concordo... 😉

@Alex

[RobertoA]

Lo faccio per voi ehhh, altrimenti vi dimenticate le cose
Come con le dram, un colpetto di refresh ogni x anni

[Bruno Campanini]

RobertoA expressed precisely :

Je damo giù a colpi di Filter!
Ho un ponderoso elenco telefonico con 26 buttons, ciascuno
coi propri:
FilterOn = True
DoCmd.ApplyFilter...
Diversamente dovrei modificare un'espressione SQL all'interno
del Form, indi con quella andare a sostituire il RecordSource.
La quale query del RecordSource, se deve portarti dentro
qualche tonnellata di dati, ti fa anche balenare brevemente
il video.
La qual cosa non capita con l'azione Filter.
Naturalmente se il filtro non fosse così semplice come esposto,
ma comportasse sequenze di AND, OR, Between etc, il cambio di
RecordSource dovrebbe essere la scelta migliore.

Saluto tutti i vecchi amici coi quali da tempo non dialogo su
questo NG.
Compresa quella vecchia zimarra che comincia per @.

Bruno