Gestire aggiornamenti di un software

di
nickbi78
il
18 risposte
N
nickbi78
Utente Attivo
Iscritto da
lug, 2014
Messaggi:
147

Gestire aggiornamenti di un software

Ciao a tutti
mi pacerebbe notificare all'apertura di un applicatvo access (2007) la presenza di un nuovo aggiornamento del FE.
avrei pensato di gestire il tutto con 2 file di testo, uno in locale con la versione installata ed uno sull'ftp privato dove è residente il programma di installazione.
Confrontando il contenuto, se la versione su ftp è maggiore di quella locale, viene notificato l'aggiornamento, chiede conferma dell'update ed il FE aggiornato viene sostituito previa chiusura...

avete da suggerirmi metodi alternativi?

grazie!

Nico

18 Risposte

  • P
    Philcattivocarattere
    Utente Famoso
    Iscritto da
    giu, 2014
    Messaggi:
    2241

    Re: Gestire aggiornamenti di un software

    nickbi78 ha scritto:

    ...avete da suggerirmi metodi alternativi?
    Sai già come scaricare da FTP?
    Per alternative o altro, una miniricerca sul web con i termini "ms access front end update" ti darà tutti i suggerimenti possibili (ovviamente potresti finire anche tra "prodotti commerciali"... il buon senso sta sempre al di qua del mouse)
  • N
    nickbi78
    Utente Attivo
    Iscritto da
    lug, 2014
    Messaggi:
    147

    Re: Gestire aggiornamenti di un software

    Si, per il download non c'è problema, i dati si trovano in un'area FTP ma il download viene effettuato tramite http come già faccio per altre procedure (aggiornamento dati di magazzino, aggiornamenti fotografici, ecc).
    ero solo curioso di capire se il mio ragonamento fosse valido o se ci fossero alternative fai-da-te senza dovermi buttare su prodotti esterni già pronti.
    Comunque do un'occhiata ai tuoi suggerimenti!

    grazie

    Nico
  • P
    Philcattivocarattere
    Utente Famoso
    Iscritto da
    giu, 2014
    Messaggi:
    2241

    Re: Gestire aggiornamenti di un software

    nickbi78 ha scritto:

    ... alternative fai-da-te ...
    Le alternative fai da te ci sono, nel senso che c'è già chi ha approntato una buona base di codice per fare la cosa, codice che trovi appunto facendo un po' una ricerca, da calare poi nella tua esigenza concreta. Siccome non ne ho mai verificata una, di quelle, non me la sento di evidenziarti link specifici.
  • N
    nickbi78
    Utente Attivo
    Iscritto da
    lug, 2014
    Messaggi:
    147

    Re: Gestire aggiornamenti di un software

    Cercando ho visto alcuni esempi interessanti e che sembrano fare al mio caso, voglio però prima provare con qualcosa di personalizzato, se non ci riesco prendo spunto dalle soluzioni online adattandole al mio caso.

    grazie ancora!
  • max.riservo
    max.riservo
    Molto attivo
    Iscritto da
    ago, 2016
    Messaggi:
    709

    Re: Gestire aggiornamenti di un software

    Prendendo spunto dalla tua idea (2 file di testo) e seguendo quanto faccio io, mi sento di consigliarti di inserire un campo versione direttamente nel db (BE) che confronti con il FE (che contiene nel form di avvio un campo con la versione dell'applicativo) ....
  • E
    ettore56
    Molto attivo
    Iscritto da
    mag, 2017
    Messaggi:
    661

    Re: Gestire aggiornamenti di un software

    Condivido pienamente il suggerimento di @Max, aggiungendo che potresti verificare sia le versione installata nel FE, sia quella installata nel BE, poiché spesso aggiornando il FE aggiungi e/o modifichi campi nelle tabelle residenti nel BE, oppure aggiungi ulteriori tabelle, sempre nel BE.
    In tal caso, per evitare crash dell'applicativo, attraverso codice dovrai verificare che le versioni FE e BE siano compatibili.
  • @Alex
    @Alex
    Super Famoso
    Iscritto da
    feb, 2012
    Messaggi:
    8752

    Re: Gestire aggiornamenti di un software

    ettore56 ha scritto:

    Condivido pienamente il suggerimento di @Max, aggiungendo che potresti verificare sia le versione installata nel FE, sia quella installata nel BE, poiché spesso aggiornando il FE aggiungi e/o modifichi campi nelle tabelle residenti nel BE, oppure aggiungi ulteriori tabelle, sempre nel BE.
    Il CLIENT non deve MAI modificare il Server ... questi sono concetti basilari che i meno esperti dovrebbero imparare a considerare.
    Figuriamoci se io che installo il client vado a modificare il Server magari mentre un collega lavora...? Dai queste cose le di fanno a casa con il DB delle ricette della moglie.

    Il server lo modifica l'amministratore del DB con procedure di inibizione all'accesso, backup e recovery... il client deve solo fare il client.

    ettore56 ha scritto:

    In tal caso, per evitare crash dell'applicativo, attraverso codice dovrai verificare che le versioni FE e BE siano compatibili.
    Se il Server richiede l'upgrade del/dei client il client non deve partire ma fare l'upgrade per questo si definiscono più proprietà per le modifiche... e si scrivono 3 righe di codice nel client.

    Le properties di norma sono:
    Version
    Major
    Minor
    Build
    Revision
    MajorRevision
    MinorRevision

    Ovviamente in questo caso autocostruito si ottimizza.
    Se, come ha spiegato Max nel server si gestisce la tabella delle modifiche la si realizza con i campi che, il client interpreta ed agisce... magari basta un campo Flag(si/no) che indica al Client di obbligare l'aggiornamento.
    Proviamo a non fare confusione...
  • +
    +m2+
    Utente Famoso
    Iscritto da
    mag, 2017
    Messaggi:
    3548

    Re: Gestire aggiornamenti di un software

    Beh qualche considerazione.
    molto più semplice due numeri di build, uno per il database, uno per applicazione, piuttosto che versioni e sottoversioni. 
    il primo scritto nel db, il secondo nell'applicazione.
    Per l'aggiornamento del database il client mantiene un elenco di tutte le modifiche da applicare per ogni build. 
    Così è in grado di aggiornare qualsiasi versione anche vecchia, applicando uno dopo l'altro le opportune variazioni. 
    Riguardo agli aggiornamenti del db dipende ovviamente da cosa si usa.
    Per access / jet ci sono un sacco di caveat, che in realtà non conosco
    In altri casi (mysql ad esempio) è nor altissimo che il client aggiorni il server 'a caldo' con delle alter table.
    il prerequisito è l'aggiunta di campi e tabelle, così da consentire più client in versioni diverse in esecuzione contemporanea.
    Ma è il mondo 'non access:

  • E
    ettore56
    Molto attivo
    Iscritto da
    mag, 2017
    Messaggi:
    661

    Re: Gestire aggiornamenti di un software

    @Alex ha scritto:

    .....Proviamo a non fare confusione...
    Tu vivi evidentemente e prevalentemente solo basandoti sulle teorie, io, a differenza, mi confronto quotidianamente con la pratica e con l'esperienza acquisita con diversi anni d'esperienza.
    La confusione la stai facendo tu!
  • @Alex
    @Alex
    Super Famoso
    Iscritto da
    feb, 2012
    Messaggi:
    8752

    Re: Gestire aggiornamenti di un software

    ettore56 ha scritto:

    @Alex ha scritto:

    .....Proviamo a non fare confusione...
    Tu vivi evidentemente e prevalentemente solo basandoti sulle teorie, io, a differenza, mi confronto quotidianamente con la pratica e con l'esperienza acquisita con diversi anni d'esperienza.
    La confusione la stai facendo tu!
    Distinguiamo la teoria dalla pratica sicuramente... ma la Teoria serve sia corretta, molti smanettoni sostengono la propria competenza non avendo basi di teoria... e creandosi logiche di ragionamento che per loro sono frutto di esperienza... ma non è proprio così... le soluzioni capestro le possiamo sempre fare, ma sostenere siano LA SOLUZIONE diventa poi complicato...
    La teoria, che si eve studiare e conoscere GUIDA, poi la pratica aiuta a superare i problemi.

    Innanzitutto Access JET, stiamo parlando di questo se non erro, a caldo è meglio non fare comandi DDL, e questo non perchè non si possa fare, ma chi sa come funziona JET, e lo dico per esperienza... non lo fa...!
    Access è un DB ad uso LOCALE non in Rete, questo è INDISPENSABILE NON SCORDARLO ed è privo di tutte quelle cose che un RDBMS mette a disposizione per i Ripristini ecc...

    Sempre chi conosce Access e chi conosce la gestione Client-Server di Access, sa bene che dopo una modifica STRUTTURALE alle Tabelle deve essere ripristinato il LINK in quanto 9 volte su 10 si generano anomalie, senza parlare che eventuali CAMPI aggiunti non verrebbero visti, questo ovviamente non solo per il Client che lancia il comando DDL ma per tutti i client collegati, e come indichi agli altri CLIENT che devono RELINKARE...?

    Questo accadrebbe anche se il Server fosse MySQL o SQLServer, perchè questo è generato dal Driver ODBC che gestisce la LINKED TABLE.

    Lavoro con Applicaizoni ERP tipo SAP/R3 da anni... e le modifiche lato Server vengono eseguite mettendo OFFLINE il sistema, creando dei BackUp conprocedure molto rigorose, ma sicure.
    Senza voler prendere in esame ambiernti di lavoro così strutturati, e rimanendo su Access, è bene tuttavia essere meno superficiali.

    Detto ciò è anche vero che ognuno fa quello che crede.
  • E
    ettore56
    Molto attivo
    Iscritto da
    mag, 2017
    Messaggi:
    661

    Re: Gestire aggiornamenti di un software

    @Alex ha scritto:

    ...Detto ciò è anche vero che ognuno fa quello che crede.
    Non essendo interessato a proseguire oltre con te questa sterile discussione basata su principi elementari che dovrebbero essere a conoscenza di chiunque si appresta a realizzare e gestire un applicativo di tipo gestionale, mi permetto di farti osservare che i consigli che mi appresto a dare a chi ne richiede sono ovviamente basati sulle conoscenze teoriche e pratiche acquisite, ripeto, con MOLTI anni d'esperienza.
    Ritengo assolutamente scontato che qualora si vadano ad aggiungere campi e/o tabelle sul server, ci debba essere, in fase d'aggiornamento, un controllo che verifichi l'eventuale connessione di qualsiasi client e che, in tal caso, ne inibisca l'operazione, come ritengo oltretutto scontato che ogni qualvolta un client si disconnetta dal server, tutte le relative connessioni alle tabelle debbano essere chiuse per poi essere riattivate in fase di nuova apertura. Non hai detto assolutamente niente di nuovo!
    Comunque lascio ad ognuno la possibilità di fare tesoro o meno delle esperienze altrui.
    Non ho la presunzione di essere depositario della verità assoluta!
  • +
    +m2+
    Utente Famoso
    Iscritto da
    mag, 2017
    Messaggi:
    3548

    Re: Gestire aggiornamenti di un software

    Lasciando stare jet (come accennato ho chiarito che non so cosa faccia, o non faccia) per il resto invece, cioè far applicare aggiornamenti a db mysql ad esempio o postgres, dai client, senza blocchi backup, nel mio piccolo da decenni lo faccio, in migliaia di clienti complessivi, senza il minimo problema.
    questo poiché il db consente di alterare la struttura delle tabelle mentre viene utilizzato.
    consente di fare backup dai client (meglio dump) a caldo, senza dover fermare servizi o altro.
    consente perfino di fare ripristini di tabelle 'al volo', tipicamente per caricare quelle anagrafiche pre compilate.
    tutto questo ha un nome e cognome (in realtà ne ha 3 su mariadb) ed è innodb.

    Quindi, ricapitolando, non metto affatto in dubbio che jet richieda di fare operazioni 'a freddo', che sia consigliabile farlo etc.

    D'altronde non metto in dubbio la possibilità di aggiornare 'a caldo' un db mysql innodb, o anche mariadb/aria, o magari xtradb, perché lo faccio tutti i giorni, l'ultima volta ieri.
    Certo, come in tutti gli ambiti, bisogna sapere come si fa, magari perché.

    Come ho accennato è prassi comune creare una 'querona' (in realtà non è una query, se proprio vogliamo essere precisi) che altro non è che una stringa con giustapposti ;
    Data una certa build del database, dentro al client c'è un vettore hard coded che ha per ogni build la stringa di aggiornamento alla build successiva.
    quindi ci sarà come aggiornare dalla versione 27 alla 28. Dalla 28 alla 29, dalla 29 alla 30 e così via.
    in questo esempio il client, rilevato ad esempio che il db è alla versione 27, concatenerà le stringhe del vettore [28],[29] e [30].
    Farà un backup a caldo (sempre il client) poi lancerà la 'querona', con o senza lock tables a seconda se transiton safe oppure no su acid.

    Il db sarà aggiornato alla versione 30 sul server e quindi 'a cascata' per ogni client.

    Quando si dovrà fare un aggiornamento al db basterà inserire nell'eseguibile del client, versione aggiornata, una nuova riga hardcoded [31].
    All'avvio si accorgerà che il db è in versione 30,capirà quindi di dover applicare da 30 fino al suo massimo, 31 o magari di più.

    Ecco quindi che un client del 2019 aggiorna tranquillamente un db diciamo del 2017 applicandoci magari 20 aggiornamenti, senza battere ciclio.

    In realtà c'è un caveat e riguarda aggiornamenti di tabelle grandi. Grandi sono quelle i cui indici sono più grandi della ram disponibile. In questo caso c'è il problema di limitare aggiornamenti a blocchi, scaldare la cache etc. 
    in questo caso procedo supervisionando personalmente, ma parliamo di 'veri' big data (molti terabyte), non degli archivietti quotidiani da qualche decina di gigabyte usati tipicamente in ambito aziendale.

  • @Alex
    @Alex
    Super Famoso
    Iscritto da
    feb, 2012
    Messaggi:
    8752

    Re: Gestire aggiornamenti di un software

    ettore56 ha scritto:

    @Alex ha scritto:

    ...Detto ciò è anche vero che ognuno fa quello che crede.
    Non essendo interessato a proseguire oltre con te questa sterile discussione basata su principi elementari che dovrebbero essere a conoscenza di chiunque si appresta a realizzare e gestire un applicativo di tipo gestionale, mi permetto di farti osservare che i consigli che mi appresto a dare a chi ne richiede sono ovviamente basati sulle conoscenze teoriche e pratiche acquisite, ripeto, con MOLTI anni d'esperienza.
    Ritengo assolutamente scontato che qualora si vadano ad aggiungere campi e/o tabelle sul server, ci debba essere, in fase d'aggiornamento, un controllo che verifichi l'eventuale connessione di qualsiasi client e che, in tal caso, ne inibisca l'operazione, come ritengo oltretutto scontato che ogni qualvolta un client si disconnetta dal server, tutte le relative connessioni alle tabelle debbano essere chiuse per poi essere riattivate in fase di nuova apertura. Non hai detto assolutamente niente di nuovo!
    Adesso stai iniziando a rendere più ragionato il discorso... e chiaramente quando ci si ragiona in modo concreto le cose banali prendono spesso una forma meno semplice...!

    Proviamo a vedere questo scenario... hai 1 Server e 10 Client.

    In 4 stanno lavorando, il 5 Client attiva la procedura di Modifica... il 5 Client che ha attivato, giustamente Relinka... gli altri 4 che fanno...?
    Come fai a far Relinkare i Client...? Forse lo puoi fare al successivo Riavviamento... nel quale relinkano le tabelle, ma ricordo che loro stanno lavorandoci... ORA, quindi il 5 Clinet ha già attuato la modifica...
    Io non credo sia vero che tu faccia questo.

    Ovviamente è sempre tutto fattibile come sempre, ma si parla di buona gestione...?
    Se vuoi apportare le modifiche in modo funzionale e non "disfunzionale"... serve ragionare su una gestione più completa, magari si attua una logica di LOGOFF forzato dei Client a tempo, oppure si pianifica l'aggiornamento al LOGOFF dell'ultimo CLIENT, ma non da Client... ServerSide, si inibisce il LOGIN nel mentre si fanno le modifiche ecc...!

    ettore56 ha scritto:

    Comunque lascio ad ognuno la possibilità di fare tesoro o meno delle esperienze altrui.
    Non ho la presunzione di essere depositario della verità assoluta!
    Vorrei solo che lasciassimo le Banalizzazioni a chi è in grado di capire... se banalizzi un tema simile con chi ha poca conoscenza, lui crede che veramente sia usuale e semplice fare quanto ipotizzato.
  • @Alex
    @Alex
    Super Famoso
    Iscritto da
    feb, 2012
    Messaggi:
    8752

    Re: Gestire aggiornamenti di un software

    +m2+ ha scritto:

    ....
    Penso sarebbero da tenere distinte le modifiche di STRUTTURA,quelle sostanziali, da quelle di Utilizzo del Client... una modifica sostanziale del DB concettualmente non ha senso sia invocata dal CLIENT... di solito avviene il contrario, ovvero si modifica la Struttrura dopo aver messo OFFLINE il sistema o di notte o nel We o quando è possibile, successivamente l'incompatibilità della BUILD tra il Client ed il NUOVO DB obbliga il Deploiement del Nuovo client.

    Per questo all'avvio viene Testata la Build e, si autoaggiorna prima di essere lanciato.
    Le modifiche di utilizzo invece hanno, o possono avere, logica, a mio avviso diversa come è il caso che accennavi tu di aggiunta campi su un RDBMS, questo renderebbe il DB compatibile sempre con i vecchi client... ma dipende dal CLIENT, o meglio da che tecnica/linguaggio si è usata e dipende se è ONLINE.
    In questo caso stiamo parlando di Access+JET(ma anche se fosse MySQL), che bene o male possa essere come accoppiata ha un modo di funzionare suo da conoscere...!
    La parola chiave sono le LINKED TABLE, estremamente comode ma hanno insidie... non si autoaggiornano... sicchè se fai una modifica alla Tabella lato Server, non la vedi ne tu che la fai ne gli altri che non lo sanno, ma non solo, questo contribuisce o può contribuire a far fallire gli aggiornamenti dei dati, di tutti i Client Linkati al momento, rendendo alcune volte READONLY il collegamento, ma te ne accorgi solo al tentativo di Commit, che in realtà Access fa ma che chi sviluppa non sempre conosce...

    Insieme a questi dettagli che solo chi ha una buona conoscenza del prodotto Completo Access[Client] e Jet[Server] sa, rimane che JET non è un DB per lavori in Rete, non ha modo di fare ripristini non fa BackUp dal Client, e capita in accesso concorrente in rete, che i comandi DDL facciano CRASHARE il sitema corrompendo il DB.

    Insomma l'argomento è decisamente meno liscio di quanto possa sembrare... eviterei di trattarlo da "praticone"...
Devi accedere o registrarti per scrivere nel forum
18 risposte