Acquista i nostri libri consigliati su Amazon.it
+ Rispondi al messaggio
Visualizzazione dei risultati da 1 a 7 su 7

Aggiornamento automatico del FE con .vbs

  1. #1
    L'avatar di nman
    nman non è in linea Scribacchino
    Scusatemi se sarò lungo

    Ho messo a punto una procedura che aggiorna (sostituisce) automaticamente
    nei Client le applicazioni (FE) di Access superate
    Lo scopo è evitare al "povero" amministratore di girare sulle scrivanie di tutti gli utenti per sostituire i vari FE
    A me sembra che funziona bene,
    ma vorrei (prima di metterla in servizio) commenti negativi/costruttivi e/o proposte di miglioramenti ecc

    ------ La struttura base è cosi composta
    Nel Server in una cartella condivisa di nome "Store" metto e conservo i FE aggiornati e disponibili per il "DownLoad"

    Nel BE abbiamo una tabella a record unico di nome T1 con i campi
    ---- T1Ed -- Numerico -- Dove scrivo manualmente la edizione a cui aggiornare eventualmente il FE
    ---- T1Perc -- Testo -- Il percorso dove andare a prelevare il FE aggiornato
    ---- T1Nom -- Testo -- Il nome del FE aggiornato
    ---- T1Est -- Testo -- La estensione del FE aggiornto

    Nel FE abbiamo:
    - Un collegamenti alla tabella T1 del BE
    - Una tabella di nome T2 sempre a record unico con i segienti campi:
    ---- T2Ed -- Numerico -- La edizione attuale del FE
    ---- T2Log -- Testo -- Il nome dell'ultimo utente Logato che voglio trasferire nel FE che aggiornerò


    ------ il processo a grandi linee è questo:
    All'avviamento il AutoExec fa queste cose:
    - Legge la edizione richiesta dal BE
    - Legge la edizione del FE
    --- se corrispondono arresta subito la procedura
    --- Diversamente procede

    - Legge la edizione del FE disponibile nello Store per il DownLoad
    --- Se diversa dalla edizione richiesta dal BE arresta con avviso di errore
    --- Diversamente procede

    - apre un file .vbs passandogli dei parametri
    --- Il percorso del FE nel suo Client
    --- Il nome+estensione del FE nel suo client ( che potrebbe essere diverso )
    --- Il percorso del FE nello Store per il DownLoad
    --- Il nome+estensione del FE nello Store
    --- Il parametro testo contenente il nome dell'ultimo utente logato

    - dopo la apertura del .vbs segue immediatamente il Quit

    - il file .vbs fa queste cose:
    -- elimina il vecchio FE che nel frattempo si è chiuso ??????? (Questo è un punto delicato)
    -- preleva il FE aggiornato dallo Store e lo mette nel Client nel percorso del vecchio FE
    -- Rinomina il FE appena copiato dandogli il nome di quello eliminato (potrebbero essere diversi)
    -- UPDATA il nuovo FE mettendogli il nome dell' utente logato
    -- apre il nuovo FE


    ------ Il tutto tradotto in codice è questo:
    Public Function AggEdi02()
    'Stop
    
    ' ---------------------------------------------------------------
    ' Le dichiarazioni
    
    Dim intEdOld As Integer  ' La Vecchia Edizione
    Dim intEdNew As Integer  ' La Nuova Edizione
    
    Dim strPerFi As String     ' Il Percorso del File
    Dim strNomFi As String     ' Il Nome del File
    Dim strPerSt As String     ' Il Percorso dello Store
    Dim strNomSt As String     ' Il Nome dello store
    
    Dim intEdSto As Integer  ' La Edizione contenuta nello Store
    Dim strUtLog As String   ' Utente Logato
    
    ' ---------------------------------------------------
    
    intEdOld = DMax("T2.T2Ed", "T2")
    intEdNew = DMax("T1.T1Ed", "T1")
    
    ' ----------------------------------------------------------------
    ' esco SUBITISSIMO se non serve aggiornamento
    If intEdOld = intEdNew Then Exit Function
    
    ' --------------------------------------------------------------
    ' se devo aggiornare allora popolo le altre variabili
    
    strPerFi = CurrentProject.Path
    strNomFi = CurrentProject.Name
    strPerSt = DLookup("T1.T1Perc", "T1")
    strNomSt = DLookup("T1.T1Nom", "T1") & "." & DLookup("T1.T1Est", "T1")
    
    intEdSto = OpenDatabase("" & strPerSt & "\" & strNomSt & "").OpenRecordset("SELECT Max(T2.T2Ed) AS EdSt FROM T2;", dbReadOnly).Fields(0).Value   'Il Max(....) non servirebbe perche è una tabella a record unico,   Ma .......
    strUtLog = Nz(DLookup("T2.T2Log", "T2"), "")
    
    ' --------------------------------------------------------------------------
    ' Verifico che la copia dello Store sia effettivamente aggiornata,   diversamente esco con messaggio di errore
    
        If intEdNew = intEdSto Then
        Else
            MsgBox ("L'aggiornamento è stato interrotto " & vbNewLine & "   perche non è disponibile una copia aggiornata")
            Exit Function
        End If
    
    
    ' -------------------------------------------------------------------------
    ' lancio il  .vbs che si trova nella stessa cartella del FE  (si chiama zzvvv.vbs)
    
    Dim ApVbs As Object
    Set ApVbs = CreateObject("WScript.Shell")
    ' Racchiudo fra doppi (tripli) DoppiApici perche diversamente si incasina con le StringheDiLunghezzaZero oppure con i Null
    ApVbs.Run ("" & strPerFi & "\zzvvv.vbs """ & strPerFi & """ """ & strNomFi & """ """ & strPerSt & """ """ & strNomSt & """ """ & strUtLog & """")
    '  ApVbs.Close
    Set ApVbs = Nothing
    
    ' ---------------------------------------------------------------------------------
    
    
    Application.Quit
    
    
    
    End Function
    
    poi il File .vbs apena lanciato con 5 parametri è questo:
    Option Explicit
    On Error Resume Next
    
    ' ------- Acquisisco le variabili necessarie da Access -------------------------
    Dim WSA   'AS Object   ' Array per prelevare i parametri di apertura
    Dim PeFi  'AS String   ' Percorso del File da eliminare (e sostituire)
    Dim NoFi  'AS String   ' Nome del File da eliminare (e sostituire)
    Dim PeSt  'AS String   ' Percorso da cui prelevare il nuovo file in sostituzione
    Dim NoSt  'AS String   ' Nome del nuovo file in sostituzione
    Dim UtLo  'AS String   ' Utente logato
    
    Set WSA = WScript.arguments
    
    PeFi = WSA(0)
    NoFi = WSA(1)
    PeSt = WSA(2)
    NoSt = WSA(3)
    UtLo = WSA(4)
    
    Set WSA = Nothing
    
    ' ------- Se lancio per errore questo .vbs da EsploraRisorse -----------------------
    ' è certamente un errore quindi lo devo chiude senza fare nulla
    ' testo perciò la presenza di almeno 1 parametro che gli viene passato da Access 
    
    If Len(PeFi & "") = 0 Then
    	MsgBox ("Non puoi aprire direttamente questo file :( :( " & vbNewLine & "Chiudiamolo subito senza fare danni :) :) ")
    	WScript.Quit 
    End If
    
    ' --------------------------------------------------------------------------------
    ' MsgBox (PeFi)
    ' MsgBox (NoFi)
    ' MsgBox (PeSt)
    ' MsgBox (NoSt)
    ' MsgBox (UtLo)
    
    '  Devo dare tempo che si chiuda Access prima che questo .vbs mi elimini il .accdb
    '      Un MsgBox è sufficiente  (e doveroso)
    MsgBox ("Stiamo aggiornando la applicazione richiesta")
    ' Aggiungo per esagerare un timer di 1500 millisecondi
    WScript.Sleep 1500
    
    
    ' ------------- Attacco il cuore della movimentazione file ------------------------
    Dim FSO   ' As Object
    Set FSO = WScript.CreateObject("Scripting.FileSystemObject")   
    
    ' Cancello il File FE vecchio
    FSO.DeleteFile ("" & PeFi & "\" & NoFi & ""), True
    
    ' Copio al suo posto il File FE dello Store (con il suo nome originale)
    FSO.CopyFile ("" & PeSt & "\" & NoSt & ""), ("" & PeFi & "\")
    
    ' Lo rinomino mettendoci il nome del vecchio file appena cancellato
    FSO.GetFile("" & PeFi & "\" & NoSt & "").Name = "" & NoFi & ""
    
    'FSO.Close    
    Set FSO = Nothing
    
    ' -----------------------------------------------------------------------
    ' Copio nel file sostituito i valori del vecchi file gia eliminato  (valori memorizzati in variabili)
    
    Dim strSql    ' As String      La stringa di query
    strSql = "UPDATE T2 SET T2.T2Log = '" & UtLo & "';"
    
    Dim objCnn    ' As Object
    Set objCnn = WScript.CreateObject("ADODB.Connection")
    objCnn.Open "Provider = Microsoft.ACE.OLEDB.12.0; Data Source = " & PeFi & "\" & NoFi & ""
    objCnn.Execute (strSql)
    objCnn.Close
    Set objCnn = Nothing
    
    
    ' -----------------------------------------------------------------------
    ' Apro il file aggiornato e rinominato
    
    Dim ApAccdb
    Set ApAccdb = WScript.CreateObject("WScript.Shell")
    ApAccdb.Run ("" & PeFi & "\" & NoFi & "")
    '  ApVbs.Close
    Set ApAccdb = Nothing
    
    ' ------------ Finito  :)  -------------------------------------
    MsgBox ("Finito   :)  ")
    
    .

  2. #2
    L'avatar di @Alex
    @Alex non è in linea Moderatore Globale
    Ciao NMAN ... Non ho provato il tutto ma a livello descrittivo.... espongo qualche considerazione anche se confesso di essere estremamente arrugginiti essendo anni che non gestitlsco più nulla...
    Non avrei usato la tabella locale T2... a vantaggio del SetOption/GrtOption che salva nel registro... mentre concordo con la T1.
    Io all'apertura verifico la presenza dell'aggiornamento, ancora prima del login dal momento che il client è da distribuire a prescindere, e propongo all'utente se installarla subito... che però è operativa alla chiusura... di conseguenza non mi preoccupo del login.
    Non ho capito cosa intendi come fase critica quella della cancellazione... se il client viene rinominato correttamente... poi cancelli il precedente alla riapertura del client eventualmente...

    Io non usavo un VBS ma avevo un exe in vb6... ora non avendo più vb6 delegherei ad un linguaggio che consente debug e interfaccia....

    Nel server avevo la lista dei client su cji fare il deploy e registro per ogni client la versione e la data di installazione... con un Boolean che forza il reinstall ... a prescindere... da form managment che avevo io...
    ℹ️ Leggi di più su @Alex ...

  3. #3
    L'avatar di gibra
    gibra non è in linea Very Important Person
    Magari può essere utile, oppure no, perché non riguarda direttamente Access ma io lavoro con eseguibili, comunque io faccio così:

    1) l'utente non avvia mai il programma direttamente, ma un Launcher (exe)
    2) il Launcher che scarica sempre dal server l'ultima versione aggiornata
    3) il programma viene copiato in una cartella 'nascosta' insieme alla guida (ed altri file, se servono)
    4) a questo punto il launcher avvia il programma.
    5) anche i file di configurazione per l'utente sono (e restano) su una cartella preposta sul server, in tal modo saranno disponibili da qualsiasi postazione faccia il login ed anche se si 'rompe' il pc non perderà mai le proprie impostazioni.

    Parlando di programmi eseguibili, questo mi per mette di aggiornare l'eseguibile sul server quando e come voglio perché non sarà mai in uso.
    Quando aggiorno il programma, l'utente riceve un 'fumetto' sul pc che lo avvisa e può decidere di acquisire l'ultima versione (o meno) semplicemente chiudendo il programma e riavviare il Launcher.
    ℹ️ Leggi di più su gibra ...

  4. #4
    L'avatar di nman
    nman non è in linea Scribacchino
    Vi ringrazio entrambi per l'impegno e le idee,
    Mi hanno dato 2 spunti interessanti di lavoro

    Quote Originariamente inviato da @Alex Visualizza il messaggio
    .....Non avrei usato la tabella locale T2... a vantaggio del SetOption/GrtOption che salva nel registro... .....
    Si, era la soluzione alternativa a cui pensavo,
    ma io solitamente nelle mie applicazioni hi quasi sempre una tabella locale a record unico dove memorizzo di volta in volta quanto necessita
    Poi uso la T2 anche per verificare che la copia nella cartella condivisa del Server (Store) corrisponda a quanto richiesto dalla T1

    Quote Originariamente inviato da @Alex Visualizza il messaggio
    .....Io all'apertura verifico la presenza dell'aggiornamento, ancora prima del login dal momento che il client è da distribuire a prescindere, .......
    Si questo certamente anch'io
    Forse ho esposto male quel passaggio del utente logato di cui ho parlato
    Ma quello non è l'utente che si è appena logato,
    bensi è l'utente che si è logato mella ultima apertura,
    Serve come valore predefinito nella maschera di LogIn che arriva dopo
    in modo che si debba digitare solo la Pass

    Quote Originariamente inviato da @Alex Visualizza il messaggio
    ......Non ho capito cosa intendi come fase critica quella della cancellazione... .....
    Estraggo solo alcune rigne dal codice che ho postato sopra per isolare la criticità

    Dal File di Access VBA lancio il .vbs:
    ApVbs.Run ("" & strPerFi & "\zzvvv.vbs ............")
    Application.Quit
    End Function
    
    Subito dopo il .vbs elimina il Access che lo ha lanciato
    MsgBox ("Stiamo aggiornando la applicazione richiesta")
    WScript.Sleep 1500
    Dim FSO   ' As Object
    Set FSO = WScript.CreateObject("Scripting.FileSystemObject")   
    FSO.DeleteFile ("" & PeFi & "\" & NoFi & ""), True
    
    Succedeva che il .vbs arrivava alla elimivazione dell' Access quando ancora
    il file di Access non era arrivato al "Quit"
    Pertanto generava un errore non potendolo eliminare

    Io la ho rappezzata con un Messaggio e un Timer che mi danno qualche istante
    sufficente perche Access si chiuda da solo
    ...... ma è un rappezzo .....

    Pero in questo momento mi sta venendo una idea interessante
    Il Quit lo tolgo dalla parte Access,
    e delego al .vbs l'incarico di chiudere il File di Access
    in modo da non avere questi problemi di tempi

    Quote Originariamente inviato da @Alex Visualizza il messaggio
    ..... non usavo un VBS ma avevo un exe in vb6... ora non avendo più vb6 delegherei ad un linguaggio che consente debug e interfaccia.... ...
    Si il .vbs è molto scomodo da scrivere senza debug di interfaccia,
    ma ha il vantaggio di essere leggero, potente e manutenzionabile

    Proprio nei giorni scorsi ho trovato Questo VbsEditor
    è a pagamento, ma c'è un periodo di utilizzo libero, Sembra simpatico
    ( Non sto facendo pubblicità )

    Quote Originariamente inviato da @Alex Visualizza il messaggio
    ..... Nel server avevo la lista dei client su cji fare il deploy e registro per ogni client .......
    Questo per me sarebbe troppo,
    Mi basta non dovere piu fare il giro delle scrivanie dei coleghi

    Quote Originariamente inviato da gibra Visualizza il messaggio
    .......
    1) l'utente non avvia mai il programma direttamente, ma un Launcher (exe)
    2) il Launcher che scarica sempre dal server l'ultima versione aggiornata
    ..........
    Questa idea mi piace,
    Vista nel mio contesto diventerebbe:
    1) l'utente non avvia mai il programma direttamente, ma un Launcher (vbs)
    2) il Launcher verifica l'aggiornamento del FE e se necessario scarica la versione aggiornata
    3) eccetera .........

    Ci devo pensare su .......

    .
    Ultima modifica di nman; 28-08-2017 23:24 

  5. #5
    L'avatar di willy55
    willy55 non è in linea Scribacchino
    Nel passato una banale soluzione (applicabile non specificamente ad Access, ma ad una qualsiasi realizzazione client-server) era porre sul server una versione della applicazione (con cui si accedeva ai dati) uguale a quella standard, presente nel client, ed attraverso un semplice batch (file .BAT di pochi Kb) si controllava se fossero state apportate modifiche (nella data/dimensione) in modo da copiare (dal server al client, l'ultima versione aggiornata del software) oppure (essendo questa valida) si attivava la applicazione del client.
    In tal modo lo sviluppatore doveva solo porre (sul server di rete) l'ultima release in rilascio (nella specifica directory/drive di accesso). e la copia avveniva, prima di una successiva riattivazione. in modo da assicurare una sequenzialità nelle operazioni. Inoltre l’impiego di un batch, contenuto e compatto, permetteva di operare in qualsiasi ambiente e offriva ridotti tempi di risposta.
    Con il tempo, nella evoluzione dei sistemi crescevano le esigenze ed il batch doveva supportare una maggiore complessità.
    Ad esempio, nella specificità di Access si potevano gestire le versioni impiegabili (MDB/MDE o ACCDB/ACCDE) in base al software disponibile nelle postazioni della rete locale.
    Da un semplice launcher (con il controllo del file di attivazione aggiornato) si è passati, al crescere della complessità, alla esigenza di tenere traccia delle release rilasciate a ciascun utente e, magari, ai criteri con cui si accede dalle diverse postazioni. In tal caso, l’esigenza a dover gestire queste informazioni ha portato ad appoggiarsi, direttamente, alle tabelle di un DB come Access,
    Pertanto, partendo da applicativi che potevano essere eseguiti da riga di comando (DOS) nel prompt dei comandi e/o inseriti in un file batch (.BAT) si è passati all’impiego di VBScript quale linguaggio per la scrittura di Windows-oriented file batch tramite il Windows Scripting Host (WSH).

    Ritornando alla problematica prospettata nei post precedenti, a mio parere è preferibile la memorizzazione dei dati centralizzati sul server (nella tabella T1) e qualora sia proprio necessario avere dati in locale è preferibile l’impiego di una tabella (T2) rispetto a salvare nel registro (con SetOption/GrtOption) in quanto i dati sono accessibili con qualsiasi applicazione che acceda al DB.
    Nello scripting l’impiego di VBS rispetto ad un semplice batch command line offre maggiori potenzialità e controlli sulla esecuzione, in quanto sono impiegabili costrutti più potenti ma, nel contempo, è più oneroso di risorse. Su ciò si innesta l’impiego di una applicazione VBA che svolga il compito di automazione del processo e magari automatizzi il VBS o da questo ne acquisisca dei parametri.
    Per cui la scelta dello strumento può essere dovuto a diversi aspetti (ad esempio può essere legata alla immediatezza del riscontro oppure alle possibilità di integrazione fra i diversi applicativi).

    Ora nel merito alla “fase critica quella della cancellazione” precedente indicata che faceva riferimento a:
    Quote Originariamente inviato da Nman
    … elimina il vecchio FE che nel frattempo si è chiuso ??????? (Questo è un punto delicato)
    si deve assicurare la sequenzialità delle operazioni del VBS per cui è possibile:
    - controllare che l’applicazione VBS sia conclusa impostando, con .Quit, un valore al termine dello script;
    https://ss64.com/vb/quit.html
    https://community.ivanti.com/thread/4563
    - stabilire un evento che scateni la gestione degli errori alla effettiva conclusione della applicazione;
    https://stackoverflow.com/questions/...of-a-condition
    https://stackoverflow.com/questions/...-from-vbscript predisposto:
    Read current errorlevel value inside a vbscript - VBScript - Tek-Tips
    - fornire all’uscita un errorlevel (come per il passaggio di variabili fra un Batch File e uno script in VBS);
    https://gallery.technet.microsoft.co...0-c22a8dc56fc0
    Get an exit code from a vbs - Real's WSH VBS How-to
    https://stackoverflow.com/questions/...le-application
    - stabilire una tempistica (valutando le alternative all’istruzione Do Events,non disponibile in VBS) impostando un ammontare di tempo prestabilito per concludere il processo oppure impiegare direttamente il VBA;
    Avoid Using DoEvents to Wait in Microsoft Access, VBA, and VB6
    https://social.technet.microsoft.com...ipt?forum=ITCG
    https://www.mrexcel.com/forum/excel-...ts-solved.html
    ℹ️ Leggi di più su willy55 ...

  6. #6
    L'avatar di muttley005
    muttley005 non è in linea Topo di biblioteca
    mi aggrego alla discussione proponendo una soluzione diversa e aspettandomi considerazioni in merito (anche critiche perchè no)
    Io in un centro per cui ho sviluppato un gestionale, ho impostato una ROOT (esempio F:\MUTTLEY) all'interno ho N sottocartelle ognuno corrispondente agli utenti di dominio (esempio F:\MUTTLEY\mario_rossi) abilitati in cui replico copia del programma. Ai vari client distribuisco solo un link in cui lancio l'accde della cartella utente (ricavato da %username%) a cui ho impostato l'icona del programma.

    A mio avviso ho questi PRO:
    • posso aggiornare direttamente collegandomi al server
    • tutti hanno sempre la versione aggiornata
    • ho ulteriore controllo sugli utenti di dominio (oltre al login da software)
    • per aggiungere il programma ad un pc (ovviamente deve avere il runtime, i driver di collegamento a mssql e l'odbc creato) mi basta copiargli il link sul desktop (all user) una volta, in modo che chiunque si autentichi sul pc ha l'icona e lancia "la sua" copia programma

    ... e questi CONTRO:
    • per poter aggiornare devo chiudere o attendere che siano chiuse le copie (avendo una ventina di potenziali utenti ho comunque predisposto un bat di copia del sw in tutte le sottocartelle utente per far prima)
    • il programma è in realtà in copia sul server e non sui client (anche se non sono certo sia un contro a livello di prestazioni)
    • (questo è l'unico veramente critico) se un utente accede a due pc potenzialmente usa la stessa copia ... in merito a questo pensavo di non avere un link ma un bat o altro che verifichi prima che l'accde non sia già aperto.


    attendo riscontro
    Ultima modifica di muttley005; 31-08-2017 09:12 

  7. #7
    L'avatar di gibra
    gibra non è in linea Very Important Person
    Quote Originariamente inviato da muttley005 Visualizza il messaggio
    ... e questi CONTRO:
    • per poter aggiornare devo chiudere o attendere che siano chiuse le copie (avendo una ventina di potenziali utenti ho comunque predisposto un bat di copia del sw in tutte le sottocartelle utente per far prima)
    • il programma è in realtà in copia sul server e non sui client (anche se non sono certo sia un contro a livello di prestazioni)
    • (questo è l'unico veramente critico) se un utente accede a due pc potenzialmente usa la stessa copia ... in merito a questo pensavo di non avere un link ma un bat o altro che verifichi prima che l'accde non sia già aperto.
    Mi pare che i contro siano un po' troppo onerosi.
    Io preferisco (ed anche Willy l'ha evidenziato) usare un launcher che copi in locale, in modo da non aver nessuna limitazione relativa agli aggiornamenti.
    Con il launcher, l'aggiornamento è l'utente stesso che 'se lo fa da solo', ogni volta che avvia il programma.
    Può usare qualsiasi PC, perché copiando in locale non vi sono limitazioni di alcun tipo.
    ℹ️ Leggi di più su gibra ...

+ Rispondi al messaggio

Potrebbero interessarti anche ...

  1. Aggiornamento automatico sottomaschera.
    Da Teo's nel forum Microsoft Access
    Risposte: 7
    Ultimo Post: 23-03-2017, 14:30
  2. Aggiornamento automatico risultati
    Da ZaraBoss87 nel forum Visual Basic .Net
    Risposte: 47
    Ultimo Post: 02-12-2014, 22:01
  3. Aggiornamento automatico risultati
    Da ZaraBoss87 nel forum Microsoft Word
    Risposte: 5
    Ultimo Post: 30-11-2014, 08:05
  4. Framework - Aggiornamento automatico
    Da AlbertoM nel forum Altri linguaggi e strumenti
    Risposte: 6
    Ultimo Post: 30-11-2007, 19:32
  5. Aggiornamento automatico per i software installati
    Da Fb85 nel forum Microsoft Windows
    Risposte: 3
    Ultimo Post: 23-10-2005, 16:01