Newsgroup: it.comp.appl.access
Titolo: ADP + form + WhereCondition

Ho appena imparato una cosa ed ho pensato di riportarla qui, visto che non 
ho trovato messaggi in italiano sulla questione.
Lavorando con gli ADP, se si utilizza l'istruzione DoCmd.OpenForm specificando 
una WhereCondition, questa non va ad impostare la proprietà Filter della 
form che si sta aprendo, bensì la proprietà ServerFilter.
In più, questo comportamento è persistente, quindi il valore della proprietà 
ServerFilter viene mantenuto una volta chiusa la form.
Questo può essere vietato gestendo a mano la chiusura della form con l'istruzione
DoCmd.Close Me.Name, acSaveNo
Salutoni.
--
PBsoft di Gabriele Bertolucci
www.pbsoft.it
skype:pbsoftsolution



Non so se le due cose sono collegate, ma a volte succede che aprendo una
maschera in un adp con un filtro come sopra, se la stessa genera un errore,
il filtro rimane e quella maschera aprirà sempre il record per il quale si è
verificato l'errore, indipendentemente dalla clausola where con cui viene
aperta successivamente, mi è capitato di compilare il tutto in ade e di
riscontare questo fastidioso comportamento, qualche idea per risolverlo?
Ungi

 DoCmd.Close Me.Name, acSaveNo
Tutti questi (e molti altri) comportamenti riguardano anche gli .MDB.
La cosa migliore per evitarli è distribuire il programma come MDE/ADE.
Saluti.

 comportamento, qualche idea per risolverlo? Ungi
Hai riscontrato il problema anche con un file ADE?
Avrei giurato che in quel caso non sarebbero stati problemi, visto che gli 
oggetti di Access non sono modificabili in un ADE.


 La cosa migliore per evitarli è distribuire il programma come MDE/ADE.
Questo è un grandissimo cruccio che mi porto avanti da ormai quasi un decennio.
Io distribuirei molto volentieri il file in formato compilato, ma non sono 
mai riuscito ad ottenere le stesse funzionalità; ad esempio, nei report io 
utilizzo pesantemente l'oggetto Printer, modificandone delle proprietà in 
fare di apertura del report. Questo non è possibile con i file compilati.


 fare di apertura del report. Questo non è possibile con i file compilati.
Ti sbagli, certo che è possibile: quantomeno con Access >= XP...
Saluti.

> Ti sbagli, certo che è possibile: quantomeno con Access >= XP...
Allora, probabilmente sto facendo degli errori nella libreria che utilizzo 
per gestire le stampe.


 per gestire le stampe.
D'altra parte ti basta provare questo esempio (che è solo MDE):
http://www.alessandrobaraldi.it/DettaglioFaq.asp?IdFAQ=198
Saluti.

 
http://www.alessandrobaraldi.it/DettaglioFaq.asp?IdFAQ=198
"Purtroppo" lo conosco.
So che hanno utilizzato una tecnica che non prevede la manipolazione dell'oggetto 
Printer.
Solo che quei malandrini degli ideatori non vogliono farmici mettere il naso...ehm...il 
mouse dentro :-)


 --
Infatti non sono modificabili, il problema è che a volte provi la maschera 
in adp, va in errore per qualche motivo, compili in ade e rimane memorizzata 
la clausola where relativa al momento in cui si è verificato l'errore. 
Servirebbe una funzione che riesca in automatico a scandagliare le maschere 
per trovare quelle che hanno ancora il filtro prima di compilare.
Leggendo i post successivi ho letto che di solito non compili il file, penso 
che la compilazione sia irrinunciabile per evidenti motivi di salvaguardia 
del codice, dando per scontato che i file mde/ade riescano in ciò
Ungi 

 mouse dentro :-)
Concordo totalmente con la definizione data agli ideatori    ;-)
Saluti.

 del codice, dando per scontato che i file mde/ade riescano in ciň
Mi sono espresso impropriamente: intendevo dire che non distribuisco mai 
un file MDE/ADE come applicazione, per i motivi che ho esposto nei miei post 
precedenti.
Io compilo il VBA ad ogni modifica importante e, comunque, sempre prima di 
provare un oggetto di Access-
