Newsgroup: it.comp.appl.access
Titolo: Access in modalità PUSH

[questo messaggio è stato inviato nei seguenti gruppi:
  - it.comp.appl.access
  - microsoft.public.it.office.access]
Oggi mi sono ritrovato a parlare con un cliente per il quale ho realizzato 
un progetto ADP con Access XP, basato su SQL Express.
La procedura è installata su numerosi client.
Ero tanto contento del fatto che il progetto funziona tranquillamente, quando 
il mio cliente ha voluto cercare il pelo nell'uovo.
In una form a maschere continue vengono visualizzati degli appuntamenti.
Il mio cliente mi ha fatto notare che, quando da una postazione viene inserito 
un nuovo appuntamento, le altre postazioni non lo vedono se non dopo un requery 
della form.
Ovviamente mi ha chiesto se la cosa è evitabile.
Al momento, l'unica idea che mi viene in mente è inserire un timer nella 
form, disabilitandolo durante l'inserimento di un record e riabilitandolo 
subito dopo, ma non mi piace molto perché, comunque, si tratta di fare il 
requery diverse centinaia di record ogni volta e se il cliente mi chiedesse 
un aggiornamento quasi "in tempo reale", finirei con l'uccidere il server.
Voi come risolvereste il problema (a parte far capire al cliente che evitare 
il refresh sarebbe meglio)?
--
PBsoft di Gabriele Bertolucci
www.pbsoft.it
skype: pbsoftsolution


sai bene che non esiste un evento a livello di inserimento di tabella
su timer tu devi solo verificare se è stato aggiunto il record non certo
requerizzare la form:
nel caso aggiorni
-- 
_ _
Ciao
MAssimiliano Amendola            
www.accessgroup.it
Cisa - Conferenza Italiana per Sviluppatori Access
Info:  
www.donkarl.com/it

 certo requerizzare la form: nel caso aggiorni
Giusta osservazione la tua, e così potrei sistemare il caso dei record aggiunti 
e di quelli cancellati, ma sono convinto che subito dopo il mio cliente mi 
chiederebbe: "e per quelli modificati?"
E qui cascherei di nuovo.


 E qui cascherei di nuovo.
beh sui cancellati o modificati potresti crearti una tab di appoggio
in cui ti riporti l'id e l'operazione (canc/Mod)


 ha scritto nel messaggio 
news:dvpa9i$pt8$1...@area.cu.mi.it...

Se no nella stessa maschera aggiungi una casella "STATO" dove a seconda 
dell'evento vi sarà scritto AGGIUNTO MODIFICATO CANCELLATO ecc... e magari 
anche da chi...
Ciao
Roberto 

 ecc... e magari anche da chi...
Ti ringrazio per la proposta, ma questa soluzione non può funzionare, perché 
mi troverei nuovamente con lo stesso problema: dover aggiornare la maschera 
per intercettare il cambiamento eventuale dei valori dei campi che indicano 
lo stato e l'autore della modifica.


"Gabriele Bertolucci" <in...@REMOVEpbsoft.it> ha scritto nel messaggio 
news:875ea35510bdb8...@news.virgilio.it...

Così su due piedi mi verrebbe da dire di fare un requery Su Timer in una 
mschera di sola lettura...diciamo che in questo caso avresti un LOG in tempo 
reale, ma chi è così malato da volerlo???
Prova con il blocco a livello record...magari potrebbe essere una 
soluzione...
Ciao
Roberto 

 E qui cascherei di nuovo.
Io userei una tabella con un solo campo numerico long. Ogni maschera che
lavora sui dati si incaricherà di incrementare di uno quel valore ogni
volta che viene aggiunto/cancellato/modificato un record.
All'apertura della maschera leggi il valore del campo e lo metti in una
variabile; su evento timer rileggi quindi un unico valore, con una
frequenza che devi stabilire tu, e se lo trovi più alto di quello che c'è
nella variabile fai il requery e aggiorni la variabile. Così eviti i
requery inutili e li fai solo quando sono realmente necessari.
Ovvio che quando una maschera aggiorna il contatore in tabella deve
aggiornare anche la sua variabile interna, così al prossimo timer evita di
fare il requery visto che ha i suoi dati già aggiornati.
2 miliardi di operazioni dovrebbero bastare, non dovresti sforare i limiti
del long. Per scrupolo comunque se hai una funzione di compattazione puoi
prevedere in quella sede anche un azzeramento del contatore.
Ciao.
-Marco-
-- 
namor at inwind punto it
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 prevedere in quella sede anche un azzeramento del contatore.
Non ho una mia routine di compattazione, ma credo che non utilizzerò l'idea 
del contatore. Piuttosto, nella tabella di cui sopra utilizzerò dei flag.
Grazie mille per il tuo suggerimento.


Gabriele Bertolucci ha scritto:






Buona l'idea di estenderla alle altre maschere, così le gestisci tutte con
lo stesso sistema.
La variabile la puoi definire a livello di maschera, in modo che ciascuna
maschera abbia la sua variabile separata dalle altre. Potresti anche usare
variabili globali anziché locali se hai maschere distinte che lavorano
contemporaneamente sugli stessi dati, la scelta dipende dall'architettura
del tuo db che non conosco.
Se hai tante maschere da monitorare puoi usare withevents per
centralizzare il codice che aggiorna e testa i flag, senza doverlo
ricopiare in tutte le form. Così risolvi con poche righe di codice e
inoltre ti semplifichi la manutenzione futura. Vedi il mio esempio sul
sito della CISA1, se non hai mai usato withevents.
