Newsgroup: it.comp.lang.delphi
Titolo: Update di un programma occupato

Ciao a tutti,
   ho un problema su come aggiornare un programma residente sul server 
ma lanciato dai client.
 
Il programma all'avvio cerca un file ("newrelease.exe") e se presente si 
autocancella e avvia l'installazione del file nuovo.
Funziona bene *se* il programma e' lanciato la prima volta da un client 
qualsuasi e sugli altri ancore non e' stato eseguito (forse mi sono 
spiegato male).
 
Infatti se su un client, per caso, il programma e' in esecuzione inizia 
il festival delle eccezioni.
 
Ecco cosa mi piacerebbe ottenere.
 
Il programma si avvia da un client, controlla che non ci siano altri 
client con il programma in esecuzione e:
CI SONO ALTRE ISTANZE: Il programma avvisa su quali pc sta girando cosi' 
da poterle chiudere
NON CI SONO ALTRE ISTANZE: Si aggiorna.
 
PREMESSA:
Lavoriamo con 3 gestionali diversi di 3 software house (italane) diverse 
e quando arrivano gli aggiornamenti (uno per l'altro) esce una bella 
finestrona che dice, a caratteri cubitali, di SPEGNERE tutti i client 
PRIMA dell'installazione degli upgrade perche' se cosi' non si fa ed i 
db sbarellano .... loro si lavano le mani!! (situazione che e' successa 
lo stesso con i client spenti !!)
Quindi presumo che non si possa fare (almeno non da me !!)
 
Grazie per l'attenzione
 
Ciao
Daniele

 NON CI SONO ALTRE ISTANZE: Si aggiorna. 
 
Ciao a tutti,
ho lo stesso problema ma al momento non ho trovato una soluzione "definitiva".
 
Riesco a verificare se ci sono altre istanze attive perché il nostro programma tiene un file aperto sul server durante la normale elaborazione (ci serve per il controllo del numero delle licenze attive contemporaneamente) ma volte capitano comunque dei problemi al momento dell'aggiornamento.
 
Anche l'utilizzo del server come client non semplifica i controlli.
A volte il problema deriva dall'antivirus, che blocca le procedure di installazione
 
Sono interessato alla discussione per migliorare la gestione dell'aggiornamento, anche se non si tratta di un problema solo di Delphi
Devo comunque ammettere che i problemi che riscontro sono tutto sommato saltuari: su cento aggiornamenti i problemi si verificano non più di 2 o 3 volte
 
Alessandro

 ma lanciato dai client. 
 
Una applicazione web in queste situazioni ha molti problemi in meno.
Ovviamente (ma solo per pochi), ci sono altri svantaggi.
Ed è bene ricordare che  la gestione di un web server è cosa da SISTEMISTI e non da SVILUPPATORI...
 
Riguardo il tuo problema...
 
1) aggiungi al db della tua applicazione una tabella tipo sessionlist con almeno i seguenti campi
sessionid integer autoinc primary key
clientname varchar(256) not null 
clientip varchar(64) not null
domainusername varchar(128) not null,
applicationusername varchar(128) not null,
leasedatetime datetime not null
additionalinfo varchar(256)
 
 
2) la tua applicazione, all'avvio, per 1a cosa farà una delete dalla tabella al punto precedente.
Suggerisco di usare nella where il clientname e non l'indirizzo IP... i nomi macchina cambiano meno di frequente rispetto agli indirizzi IP...
La delete sarà del tipo:
delete from sessionlist where clientname= <nome del pc su cui ti trovi>.
 
 3) nella tua applicazione aggiungi un thread
Questo thread avrà per(ovvi...)  motivi tecnici una propria connessione al database e si limiterà ogni n unità di tempo configurabili (file ini, ad esempio) a fare sta cosa qua:
 
a) se in sessionlist non esiste un record per quel client, lo inserisce:
b) se in sessionlist esiste un record per quel client, lo aggiorna modificando il valore del campo leasedatetime:
 
update sessionlist set leasedatetime = now where where clientname= <nome del pc su cui ti trovi>
 
4) in chiusura della applicazione per 1a cosa termini il thread e fai :
 
delete from sessionlist where clientname =<nome del pc sul quale ti trovi>
 
5) Modificare il programma che lancia gli aggiornamenti.
L'avvio sarà condizionato al fatto che la seguente select ti dia zero come risultato:
 
select count(1) from sessionlist 
 
Se la count è maggiore di zero fai uscire un avviso del tipo "..strunz, chiudi che si deve aggiornare il kaz di software!"
 
6) avere sotto mano uno strumento esterno per forzare la delete di tutti i record della tabella sessionlist...che non si sa mai.
 
 
Quanto descritto non è sicuro al 100%, sopratutto a causa degli utenti che spesso lanciano le applicazioni e poi se ne vanno in piscina o altri posti...ma li non c'è soluzione software che tenga.
Ancora, se gli utenti usano piu' istanze di una stessa macchina virtuale il nome pc non servirebbe a un kazzen e potrebbe valere lo stesso per i nomi utente....
 
Infine, c'è un presupposto che non è vitale ma è meglio rispettare: che i client siano sincronizzati come orario a livello di dominio/active directory...Dovrebbe essere scontato ma purtroppo non lo è.
 
Preciso che tutte le query devono essere parametriche e che le sintassi vanno adeguate a ciò e al db che usi.
 
A.
 
 

 A volte il problema deriva dall'antivirus, che blocca le procedure di installazione 
Si...L'unica è mettere gli eseguibili tutti in una sola cartella e fare in modo che l'antivirus ignori tale cartella.
Quante volte ho visto istanze Oracle incasinate a causa della mancata esclusione delle cartelle dei datafile dall'antivirus....
 
 
A.

forse adottando un processo diverso, il programma appena lanciato sul server crea una copia di se stesso in locale e lo esegue, chiudendo l'applicazione. in questo modo non rimangono istanze aperte sul server. l'unico problema un certo ritardo all'avvio
 

 > 
ad esempio,  il solito "inopportuno" che mi apre il programma mentre sta partendo la procedura di aggiornamento
 

Ciao Alberto,
    Ti ringrazio per la tua risposta super precisa e dettagliata e, devo 
dire, mi hai spaventato !!!
Inizio a capire il perche' gli altri (software house) hanno messo 
l'avviso di SPEGNERE i client.
 
Data la mia impreparazione tecninca sull'argomento:
- Al momento metto anch'io tale avviso
- Sul mio PC TENTO ( e sottolineo "tento" = Studio) un approccio al tuo 
suggerimento (con quali esiti esiti ... non lo so !!
 
Mi devo ancora riprendere ....
 
Questa volta il mio ringraziamento e' COLOSSALE !!!
 
Grazie
 
Ciao
Daniele


 Riesco a verificare se ci sono altre istanze attive perché il nostro programma > tiene un file aperto sul server durante la normale elaborazione
 
Ho provato anch'io questa strada ma ho trovato delle difficolta' perche' 
ho alcuni colleghi che per spegnere il pc non usano la procedura di 
spegnimento ma pigiano il pulsante del computer per 5 secondi .....
"E' piu' veloce" dicono.
Oltre che ad essere sbagliato (e fanno finta di non capire , soprattutto 
quando sono le 19.03) il file rimane; Quindi si deve fare la gestione 
del file ecc...
 
Forse per i piu' preparati e' una banalita', ma per me .. mica tanto !!
 
Grazie
 
Ciao
Daniele
 
 

 
 
Tanti anni fa, avevo avuto lo stesso problema, ma su un altro sistema 
operativo.
 
La cosa funzionava così:
- il mio programma, quando partiva, creava un file civetta nello stesso 
percorso in cui c'era l'eseguibile.
- il nome di tale file era qualcosa tipo "NomeEseguibile_IDUtente"
- quando si chiudeva il programma, cancellava il file civetta
- quando dovevo fare un aggiornamento, verificavo che non ci fosse 
nemmeno uno dei files civetta, ignorando quelli che non erano del giorno 
stesso (per scongiurare il problema di chi spegneva il PC senza aver 
prima chiuso il programma)
 
Nel momento in cui mi rendevo conto che nessuno era nel programma, un 
utente "superuser" eseguiva queste operazioni:
- lanciava un comando che faceva in modo che l'unico utente a poter 
accedere ai percorsi in cui c'era il programma fosse lui (in questo modo 
nessuno poteva aprire il programma fino a quando questo utente non aveva 
portato a termine l'aggiornamento)
- eseguiva l'aggiornamento vero e proprio
- ripristinava i permessi corretti ai percorsi in cui c'era il programma
 
Ciao, Mario