Newsgroup: it.comp.lang.delphi
Titolo: Organizzazione applicazione per funzionamento in rete

Ho sempre sbagliato le installazioni che funzionano in multiutenza:
 
Ho sempre proceduto installando una copia del software su ogni client ed 
il database solo sul server.
 
Non ho mai utilizzato un s.o. server così come non ho mai utilizzato un 
pc che fungesse *solo* da server. Le applicazioni finora realizzate sono 
piccolissime per cui non c'è mai stata l'esigenza di avere un server 
dedicato.
 
Ogni copia del programma durante l'apertura segnala se c'è un 
aggiornamento invitando ad eseguirlo per cui ogni utente è libero di 
eseguirlo oppure no e potrebbe accadere che alcuni client sono 
aggiornati mentre altri non lo sono.
 
Durante l'aggiornamento del programma potrebbe essere necessario 
modificare la struttura del database ed in questo caso viene eseguita 
anche questa.
 
Fin'ora non c'è mai stata una vera e propria modifica alla struttura del 
database che ha reso necessario che tutte le postazioni fossero 
allineate all'ultima versione del programma ma, mi rendo conto che 
soltanto adesso mi accorgo del madornale errore di impostazione del 
software, con l'ultimo aggiornamento *tutte* le postazioni *devono* 
essere aggiornate altrimenti potrebbero verificarsi malfunzionamenti 
dovuti alla mutata struttura del database.
 
 
Qual'è la corretta installazione del software che gira in multiutenza?
 
Bisogna, forse, necessariamente condividere una directory e lanciare da 
tutte le postazioni lo stesso eseguibile?
 
Grazie.
 
Ciao.

 Qual'è la corretta installazione del software che gira in multiutenza?
 
Questo è come opero io in una situazione dove ho N client che usano M 
software ed X database:
 
Su ogni client ci sono gli M software. Nella stessa cartella degli 
eseguibili c'è un file INI che punta ad un db Y.
 
Sul server ho gli X db più un ulteriore db (Y: quello a cui punta l'INI 
di prima) con un'unica tabella dove memorizzo i numeri di versione degli 
M software ed il path di ogni db.
 
Il primo client che usa la versione aggiornata del software aggiorna il 
numero di versione di quel software nel db Y. Quando il software (uno 
qualunque dei miei) viene fatto partire, controllo il suo numero di 
versione con quello memorizzato nel db Y. Se il numero di versione è 
obsoleto faccio apparire un messaggio che invita ad effettuare 
l'aggiornamento (un autoscompattante uguale per tutti i client) e chiudo 
il software. Non è la migliore soluzione perché può succedere che due 
client stiano usando versioni diverse se uno è stato aggiornato mentre 
l'altro era già attivo, ma finora ha funzionato.
 
Per l'aggiornamento della struttura dei database opero tramite SQL 
all'interno del codice facendo apparire un messaggio d'avvenuto 
aggiornamento per campi nuovi. Per la creazione di nuove tabelle impongo 
che operi un unico client sul database, altrimenti l'aggiornamento della 
struttura fallisce ed il programma si chiude.
 
Ripeto: non sarà la migliore soluzione possibile, ma finora ha 
funzionato e tanto mi basta. :)
 
-- 
@WarpTen10
 
---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
 
 

 tutte le postazioni lo stesso eseguibile?
Si, fai così che te la cavi.
 
-- 
Morde


 
Però, pensando meglio, se tento di aggiornare l'eseguibile mentre viene 
utilizzato da un altro utente l'aggiornamento fallisce.
 
Ciao.


 
Interessante :)
 
Grazie.
 
Ciao.

 il problema è che potrebbe danneggiarsi il database.
 >
Intendo dire che il database potrebbe perdere di consistenza non che 
possa danneggiarsi a livello di filesystem.
 
Ciao.
 


L'operazione di upgrade della struttura del db dovrebbe essere fatta da 
un programma di sistema (da te stesso, da una utility di manutenzione, 
ecc), non dai client. E' ovvio che rischi l'inconsistenza.
 
A questo punto puoi risolvere in due modi:
 
1- togli dai client la parte che fa l'upgrade sul db, e riportala in un 
nuovo programma di sistema che eseguirai solo tu.
Fai uscire tutti dal programma, lanci il tuo programmino che fa l'update 
del database, fai rientrare tutti in modo da costringerli a fre upgrade 
del client.
 
2- vai sul posto e fai eseguire l'upgrade uno alla volta.
 
 
 
-- 
Morde

 utilizzato da un altro utente l'aggiornamento fallisce.
 
Questo e' ovvio ....
Se l'applicazione e' stata aperta anche da un solo client risulta 
"occupata".
Prima di fare l'aggiornamento dovresti controllare se il file e' in uso, se 
non lo e' allora lo aggiorni.
Se usi InnoSetup lo puoi fare agevolmente.
Nel mio, limitatissimo caso, copio brutalmente l'eseguibile nella directory; 
Al primo avviamento della versione nuova (da qualsiasi client) se ci sono 
modifiche da fare sul db le fa.
Quando gli altri client partono, trovano gia' il DB aggiornato.
 
Come vedi ... sono molto lontano dallo sviluppo "pulito" di Alberto, Morde e 
tutti gli altri esperti che qui hanno la bonta' di aiutarci.
 
Ciao
 
Daniele 
 

 tutte le postazioni lo stesso eseguibile?
 
Dipende...
 
1) L' applicazione non parte lanciando un exe locale ma un file .bat locale che per prima cosa tenta una copia dei file eseguibili da una cartella di rete alla cartella locale.
Ovviamente la copia è condizionata al fatto che i file contenuti nella cartella 
di rete siano più recenti rispetto a quelli in locale.
Questa cosa evita a priori tutti i casini legati all'update di file eseguibili in uso.
 
2) Nel database hai da qualche parte un campo che contiene un valore che è la versione minima del file exe compatibile col database.
L'applicazione, all'avvio, fa un confronto tra il valore di questo campo e la propria versione: se il check fallisce, la applicazione si chiude segnalando il problema all'utente.
Questa cosa impedice che un exe obsoleto usi un db aggiornanto
 
3) Nella maggior parte dei PRODOTTI ai quali ho collaborato, solo in un caso l'aggiornamento del db è automatizzato. 
Negli altri casi, data la particolare natura e complessità questo lavoro è sempre stato eseguito a mano da un installatore che da una console lancia degli script.
Per i PROGETTI, compresi i miei, sta cosa l'ho vista sempre fatta manualmente.
Volendo automatizzare questo lavoro, io punterei su un "qualcosa" di esterno che aggiorna il db, magari un servizio windows, che ogni n unità di tempo configurabili o ad un orario fisso controlla se da qualche parte ci sono degli script di aggiornamento del db da eseguire.
Questo "qualcosa" che aggiorna il db altera, per prima cosa, una stored procedure il cui scopo è restituire un valore 1 (operativo) oppure zero (aggiornamento db in corso). Alla fine dell'aggiornamento si ripristina la stored procedure in modo da far restituire il valore 1 e si aggiorna il campo di cui sopra. 
Ovviamente (ma non per tutti) il servizio deve essere progettato per leggere sempre dal database un nome host/indirizzo IP e fare un check tra questo valore e quello relativo al pc sul quale è in esecuzione. Se il check fallisce il servizio si chiude. Indovina un po il perchè..? :-D
Ancora, i parametri di funzionamento dovrebbero essere letti non all'avvio ma ad ogni iterazione del thread del ervizio stesso.
Indovina un po il perchè..? :-D
 
 
4) nel db hai una tabella ad uso interno nella quale si scrive un record per ogni operazione descritta al punto 3 eseguita
In questo modo hai uno storico delle operazioni eseguite sul database
 
5) l'applicazione ogni n unità di tempo configurabili fa un check chiamando questa stored procedure.
Se il valore restituito è zero, la app si blocca magari dando all'utente solo la possibilità di uscire. 
Appena la app si sblocca esegue nuovamente il check fatto all'avvio sulla compatibilità di versione.
 
Una soluzione del genere è in uso per un prodotto c/s mission critical 24*365/366 al quale ho collaborato qualche anno fa (delphi7 + oracle).
La soluzione è utilizzata non per modificare la struttura del db ma per spostare qualche milione di record da alcune tabelle "live" a tabelle di storico, impendendo nel frattempo l'uso della applicazione da parte degli utenti per ovvi (ma non per tutti) motivi.
In circa 3 anni, su qualche centinaio di installazioni sparse in tutta l'area EMEA non ho MAI visto questo sistema incepparsi, salvo che l'istanza oracle non avesse qualche problema.
 
A.

 2)
 
Questa l'avevo già implementata ma ... in modo incompleto/sbagliato :(
 
Grazie.
 
Ciao.

 tutte le postazioni lo stesso eseguibile?
 
No. Ogni volta che rilasci una nuova versione/patch, inserisci in un database apposito (usato SOLO per le installazioni) il setup dell'applicazione client (.exe) come campo blob di una tabella indicizzata per numero di versione in formato major.minor.build. 
 
Sul client avrai due applicazioni: uno "starter" e il client vero e proprio. Il collegamento all'applicazione (per es. quello sul desktop) e` quello dello starter. Lo starter parte, preleva la versione corrente dell'applicazione client ed esegue una query sull'install db per verificare che vi sia una nuova versione. Se c'e`, la scarica e lancia il setup, chiudendosi. Se non c'e`, esegue il client corrente.
 
Il setup ha il vantaggio di poter aggiornare lo starter stesso, distribuire file aggiuntivi, ecc...
 
L'install db ha il vantaggio di contenere una storia dei tutti i tuoi setup, indicizzati per numero di versione. Ma se non ti serve mantenere questa storia, puoi cancellare il vecchio setup, non appena ne aggiungi uno nuovo. Il fatto di usare un database, e non accedere ad una cartella o usare un server TCP/IP ti consente di riutilizzare il metodo di comunicazione col server, che e` poi il protocollo del db che utilizzi. 
 
Io ho usato questo metodo in passato senza alcun problema.

 possa danneggiarsi a livello di filesystem.
 
L'upgrade del database non e` compito del client.


 
Infatti, per questo mi sono reso conto di utilizzare una impostazione 
errata.
 


 
Ottimo metodo, mi segno anche questo :)
 
grazie.
 
Ciao.

 utenti per ovvi (ma non per tutti) motivi.
 
Per curiosità, perché non partizioni la tabella?
 
Enrico

 formato major.minor.build. 
 
Orribile, veramente orribile...
 
Enrico

 gestionali che lavorano su un megafile di 3-4 GB).
 
Più che altro mi viene da dire che si tratta di una soluzione raffazzonata per
evitare un vero RDBMS (seriamente, l'unico motivo per cui mi viene in mente un
comportamento come quello da te descritto è perché stai usando un file di
"database" creato da te o qualcosa tipo Access)
 
Enrico

> Per curiosità, perché non partizioni la tabella?
 
Non posso dire di piu': NDA.
 
A.

> Orribile, veramente orribile...
 
Perchè dici che è orribile?
 
A.

Ma, giusto per sapere, che db usi?
 
A.

Ciao Enrico,

Niente di particolare, come librerie di gestione uso le turbodb della 
dataweb che (in tempo ormai remoto) mi ha permesso di passare dalle librerie 
delphi 6 a queste senza battere ciglio.
Adesso sto aggiornando un mio progetto con le firedac per intefracciarmi ad 
un db firebird dove recupero le informazioni + turbodb per la gestione dei 
dati dal mio lato.
Naturalmente la base dati (struttura dei record) quella e' certamente 
personalizzata.
 
Ciao
 
Daniele 
 

 Orribile, veramente orribile...
 
Sarebbe anche bello che tu motivassi certe critiche sul tecnico, e magari offrissi la tua brillante soluzione - dal momento che tu ne hai una, vero? Io non propongo mai soluzioni che non siano state collaudate e validate sul campo. Quel che ho proposto e` stato utilizzato da un cliente che, 15 anni fa, aveva piu` di 60 sedi in tutta Italia. Funzionava egregiamente, mai dato il minimo problema. Il vantaggio di usare un DB e` che non si deve ricorrere ad altri protocolli, nella comunicazione col server; il nuovo setup lo si scarica con una semplice query. Ma evidentemente, le soluzioni semplici per te sono "orribili" e chissa` quale accrocchio raffazzonato proporresti. Sono tutto orecchi.


mi ricordo che sta soluzione l'ho vista e applicata da qualche parte. 
non ricordo dove. fammi mente locale.
...approposito ma da quando sei stato infettato col java?
cazzo ma allora se arrivi da delphi vuol proprio dire che java va 
bene...mo mi impegno e cercpo di caèpire dove sbaglio.
 
-- 
Quando la dittatura è un dato di fatto, la rivoluzione diventa un diritto.
(Victor Hugo)

 mo mi impegno e cercpo di caèpire dove sbaglio.
 
Finalmente l'hai capito.
 

 Ma evidentemente, le soluzioni semplici per te sono "orribili"
 
Per me questa soluzione è orribile proprio perché non la vedo semplice e,
soprattutto, non standard. Ci sono delle metodologie standard collaudate e
utilizzate ampiamente per l'installazione e la distribuzione del software sui
pc di una LAN, e questa non lo è
 
Enrico

La soluzione basata su AD che proponi per windows l'hai mai utilizzata di persona?
 
A.
 
 

  di persona?
 
No, perché anche in questo caso preferisco usare Ansible (che si interfaccia a
Windows via WinRM: 
http://www.ansible.com/windows
 )
 
Enrico

 Windows via WinRM: 
http://www.ansible.com/windows
 )
 
Appena ho un attimo approfondirò questa cosa.
 
A.

 Per me questa soluzione è orribile proprio perché non la vedo semplice e soprattutto, non standard [...]
 
Non esiste alcuna soluzione "standard", non dire sciocchezze. Ogni soluzione e` comunque proprietaria. La mia soluzione e` standard perche` cross-platofrm. Se sposti il db su Linux, UNIX, o Windows, la logica rimane esattamente la stessa; e non hai bisogno di smanettare con configurazioni varie. Ti va di smanettare con Active Directory? In bocca al lupo.

On Thursday, 21 January 2016 23:23:53 UTC, Enrico Bianchi  wrote:
 
[...]
PS.: oltretutto tu stai dando per scontato che in ogni contesto si possa usare Active Directory o Ansible - e questo non e` sempre possibile. Con la mia soluzione (che, lo preciso, e` semplice, per chi vuol qualcosa di funzionante senza sbattersi troppo), il problema del deploy lo risolve lo sviluppatore, senza installare nulla sul sistema del cliente, senza dar per scontato nulla di aggiuntivo sul sistema del cliente, senza configurare nulla sul sistema del cliente, e sopratutto senza coinvolgere gli IT guys del cliente, che sono notoriamente dei grandissimi rompicoglioni.

 Appena ho un attimo approfondirò questa cosa.
 
Ho dato un occhio veloce al sito di ansible.
Magari ci sono altri pacchetti a costi inferiori, non so.
Fermo restando che do per scontata l'affidabilità della soluzione, se il prezzo minimo è 5000 USD, mi chiedo:
 
1) 5000 euro se non di più per NON avere una cartella condivisa come dicevo io o un db coi blob come suggerito da Andrea? 
 
2) applicare questa soluzione implica il coinvolgimento dell' IT del cliente?
 
3) chi paga?
 
A.

 2) applicare questa soluzione implica il coinvolgimento dell' IT del cliente?
 
Ovvio che si`. Non puoi mettere in piedi un'infrastruttura di deploy senza che il cliente ne sia al corrente. 
 

> Non puoi mettere in piedi un'infrastruttura di deploy senza che il cliente ne 
 
 
Intendevo dire se e quanto DEVE essere coinvolta l'IT del cliente per mettere in piedi e MANTENERE IN FUNZIONE una cosa del genere.
 
A.
 
 
 
 
 

 Intendevo dire se e quanto DEVE essere coinvolta l'IT del cliente per mettere in piedi e MANTENERE IN FUNZIONE una cosa del genere.
 
Ti ripeto: "Non puoi mettere in piedi un'infrastruttura di deploy senza che il cliente ne sia al corrente". O pensi di entrare a gamba tesa sui sistemi del cliente ed imporre le tue regole? L'IT DEVE essere coinvolto e dovra` MANTENERE IN FUNZIONE una cosa del genere, per il semplice motivo che e` installata sui loro sistemi.

 persona.
 
Non sono d'accordo. Io non so cosa ha a disposizione il mio interlocutore, io
so solo che la soluzione  da lui utilizzata, per come la vedo io, è sbagliata,
soprattutto in virtù del fatto che esistono soluzioni migliori e più compliance.
Per fare un esempio, Ansible richiede una macchina Linux anche per gestire
macchine Windows (in teoria potresti usare Cygwin per installarlo, ma mi sembra
una porcata), con tutte le conseguenze del caso (potresti non avere
amministratori che sappiano gestire quel sistema operativo). Pertanto non posso
limitarmi alla mia esperienza, perché sarebbe come ammettere che la soluzione
adottata sia corretta (e no, lo ripeto, non lo è)
 
Enrico

 2) applicare questa soluzione implica il coinvolgimento dell' IT del cliente?
 
Qualsiasi ( *qualsiasi* ) soluzione implica il coinvolgimento dell'IT del
cliente. Soprattutto in caso di grandi aziende. Perché se tu sviluppatore fai
un applicativo che si aggiorna in automatico, nel momento in cui c'è qualcosa
che non va, il primo che ci va di mezzo sono io sistemista che devo capire cosa
sta succedendo
 
Enrico

 Ti va di smanettare con Active Directory? In bocca al lupo.
 
Penso che questo sia un punto da chiarire. Io sono un sistemista, mi occupo
della gestione e la manutenzione dei computer presenti nella mia LAN. Tu sei
uno sviluppatore, ti occupi di implementare applicazioni che io andrò a
distribuire sulla LAN che gestisco. Il tuo compito pertanto è di fornirmi un
software e le istruzioni per installarlo, il resto è compito mio, che seguirò
in base a delle policy che ho concordato con i miei superiori (differenti dai
tuoi). Pertanto, sì, è compito mio "smanettare" con Active Directory per
distribuire il software da te sviluppato (se Active Directory è il sistema di
distribuzione e di installazione del software scelto in accordo alle policy
aziendali, ovviamente). Se implementi un sistema tutto tuo di distribuzione e
di installazione del software, oppormi al suo utilizzo è il mio primo commento,
proprio perché non si adegua alle policy aziendali. Se poi mi sarà imposto di
installare comunque il software come da te sviluppato (ovvero con il tuo
sistema di distribuzione e installazione), allora pretenderò come minimo la
firma da parte tua di una assunzione di responsabilità in caso di problemi.
Perché, come ho già detto prima, iol sistemista sono io, e sono il primo che
sarà messo alla gogna nel momento in cui qualcosa scoppierà (e, l'esperienza
mi insegna, che quando si reinventa l'acqua calda senza cognizione di causa,
qualcosa andrà sicuramente male)
 
Enrico

 sviluppatore,
 
E no! Il punto è proprio questo. Il problema non lo deve risolvere lo
sviluppatore, ma quel "rompicoglioni" dell'IT guy, perché è pagato per questo.
Se poi lo vuoi risolvere tu sviluppatore, va bene, ma ti prendi anche la
responsabilità se qualcosa va male (e ne conosco un fottiliardo di sviluppatori
che scaricano i problemi causati dalle loro applicazioni al "rompicoglioni"
dell'IT che si è trovato scavalcato nella gestione delle sue mansioni)
 
Enrico

Nota che la mia non era un critica a TE, sia chiaro.
E' solo che tanti "guru" o presunti propongo soluzioni non provate da loro e poi sarà chi li segue a dover fare un lavoro bynight per togliersi dalla cacca.
Ancora peggio, forse, è proporre qualcosa che si è provato tralsciando alcuni dettagli che potrebbero poi riverlarsi come non secondari.
 
Devo riflettere su ciò che hai scritto.
 
A.
 
 
 
 

 dell'IT che si è trovato scavalcato nella gestione delle sue mansioni)
 
Quoto. 
Ma ovviamente non siamo tutti cosi, come non tutti i sistemisti a volte "giocano" con le policy e poi quando non funziona piu' un kazzen NOI stiamo li a fare le nottate e quando si scopre cosa è successo il sistemista attiva la modalità "paraculo" del "noi non abbiamo toccato nulla!"...
 
Se solo ci parlassimo di più e ci ascoltassimo di più, molti problemi sarebbero evitati a priori.. :-((
 
A.

 sarebbero evitati a priori.. :-((
 
Ti dirò, il problema secondo me non è parlarci, ma capirci. Per esempio, oggi ho
quasi litigato con uno dei consulenti perché lui pretendeva di connettersi al
database mediante IP piuttosto che nome host, e questo perché si era impostato
i DNS di Google invece che farseli assegnare dal mio DHCP (a nulla è valso
dirgli che il problema era il suo, e alla fine gli ho dato quello che voleva
solamente perché il mio capo mi ha detto di farlo)
 
Enrico

 solamente perché il mio capo mi ha detto di farlo)
 
A Napoli diciamo "attacca 'o ciucco a 'ddove vvo' 'o padrone!"
("attacca l'asino dove dice il padrone")
 
 
 
A.

 distribuire sulla LAN che gestisco.
 
Quoto questo perchè racchiude il senso della questione.
Andrea ha creato una soluzione da sviluppatore, che taglia fuori il 
ruolo del sistemista.
 
Le obiezione qui espresse da Enrico non fanno una grinza. La 
responsabilità è del sistemista (se c'è).
 
E questo va al di là della bontà della soluzione creata da Andrea.
 
 
-- 
Morde

 sviluppatore, ma quel "rompicoglioni" dell'IT guy, perché è pagato per questo.
 
In 25 anni di carriera una delle regole che ho imparato è quella di 
riconoscere che ogni ruolo ha le sue responsabilità: scavalcarle non è 
mai corretto, ma è altresì vero che le cose vanno viste da caso a caso.
 
-- 
Morde

 Ma mi incuriosisce il perchè di questa storia dei dns di google.
 
Fondamentalmente perché l'utente si crede furbo quando in realtà è stupido.
Personalmente avrei chiuso qualsiasi connessione verso l'esterno che non
provenisse dai miei DNS, ma anche qui mi hanno dato del fondamentalista e sono
riuscito ad ottenere solo un compromesso (ovvero redirect di tutte le
connessioni DNS verso i miei server)
 
Enrico