Buongiorno,
come da oggetto sto avendo a che fare con un'applicativo windows form installato su un server; tramite rdp un certo numero di utenti apre il programma, quindi eventualmente ci possono essere n istanze attive contemporaneamente;
da quanto so ogni istanza dovrebbe essere isolata rispetto alle altre, avendo in comune i dati presente nel/nei database utilizzati;
dato che non ho avuto a che fare molto spesso con applicazioni di questo tipo questo è del tutto vero? siamo sicuri che ogni istanza vive per conto suo? ci sono delle cautele da adottare nel codice? a parte ovviamente gestire le concorrenze sui dati?

inoltre questa applicazione ha la possibilità di aprile lo stesso form più volte creandone istanza multiple; in uno scenario del genere ci sono degli accorgimenti particolari da seguire? grazie

Sulla "concorrenza" ottimistica, apriamo un problema grosso quanto una casa, almeno per me che provengo da altri "ambienti".
Non sono mai riuscito a comprendere perchè un database come SQL Server che dovrebbe essere il punto di riferimento nel campo, non riesca a gestire (o anche segnalare) l'accesso in modifica di un record.
Uso da oltre 30 anni come DB, dei semplici file .DAT, ed il mio linguaggio gestisce perfettamente la concorrenza.

La soluzione segnalata (quella del timestamp) infatti ha un neo alla base.
Lato utente, io mi metto a modificare una mascherina con 2000 campi, e dopo quando salvo mi dici che non lo posso fare, in quanto i campi sono cambiati, o anche solo 1 campo. A quel punto l'unica scelta è di annullare le modifiche, per ricaricare il record aggiornato e tutto il lavoro che ho fatto ?

Non sarebbe più opportuno invece avvisare l'utente che quel record è "bloccato" da un altro utente che lo sta variando PRIMA di entrare in variazione ? Attenzione, parlo di utente che entra in variazione e non in visualizzazione.

Così, con un semplice file .DAT posso dire, "devo leggere il file" oppure "devo aggiornare il file" ed il resto della logica dei bloccaggi me la gestisce il compilatore del linguaggio .
E questo vale (per quel che può valere su un Forum di strumenti microsoft) sia che sono su UNIX, sia se mi trovo su un ICL, oppure su un IBM AS/400 o un IBM S/38 (giusto per andare un poco indietro nella memoria), o ancora su un DOS del 15/18' o anche su Windows a 16, 32 o 64 Bit eheheheh ....

Invece microsoft con tutta la sua tecnologia, ancora oggi mi obbliga ad inventare (e gestire a manina) i semafori ! ... si ci sono i cursori, ci sono i bloccaggi di pagine, cioè io leggo un rigo e lui mi blocca tutta la pagina con i righi adiacenti, ve lo immaginate ?

Andiamo avanti, per tornare indietro !

Quindi per tornare al questito in calce, oltre al timestamp, ti consiglio di usare i semafori, e scriverti a manuzza tutto il codice di contorno; un pò più lungo, ma più funzionale per l'utente.

Poi se qualcuno mi svuole smentire, io sono in fase di apprendimento e "prendo".

Grazie.

BrightSoul ha scritto:

Oggi abbiamo gli strumenti per fare pure l'editing collaborativo in tempo reale. Sei sicuro che non sia tu ad ostinarti ad usare sempre gli stessi vecchi approcci?

Sto abbandonando i vecchi strumenti, e mi sono registrato in questo Forum, perchè spero di imparare ad utilizzare i nuovi. Nessuna ostinazione. Quello che ho scritto, è il risultato delle mie ricerche, e diverse giornate a studiare la documentazione ufficiale microsoft (sempre molto dispersiva ed autoreferenziata).

Come ho detto se ci sono altre soluzioni, non ho nessun pregiudizio, io mi adeguo.
In questo senso dai post che leggo il tuo contributo è sempre molto importante ed "autorevole", e quindi apprezzato.

Il problema principale qui è che non hai modellato correttamente la maschera ma hai buttato semplicemente dei controlli a schermo per semplificarti il lavoro. Stai riversando sull'utente un importante sovraccarico cognitivo che potresti evitargli realizzando delle Task Based UI.
Moreno

Ho semplificato l'esempio, ad ogni modo mi sembra più logico (e funzionale) bloccare all'utente la variazione, con la sola possibilità di visualizzare i campi, piuttosto che permettere di variare il tutto e poi magari scoprire delle collisioni, in genere sono gli stessi campi che si correggono; la ragione sociale di un cliente o l'indirizzo, piuttosto che un prezzo di un articolo o la sua descrizione.

Ma siamo sempre lì, il DB non gestisce queste "collisioni".

Poi ripeto, io sono aperto ...
Non conosco Task Based UI, non so se magari l'ho realizzato incosciamente. Di cosa si tratta ?
Sto realizzando, anzi convertendo il mio "vecchio" applicativo in .NET e (ovviamente) non è una semplice conversione, ma una completa ristrutturazione, partendo da zero.
Se ci sono dei riferimenti o link, posta pure ... possibilmente in italiano, il mio inglese si è molto arruginito, sai ho una certa età .. eheheh ....

Grazie.

;-)

Ogni volta che fai doppioclick sull'applicazione per aprirla, essa viene eseguita come un processo separato, che dispone di un proprio spazio di memoria, isolato da quello degli altri processi.
https://en.wikipedia.org/wiki/Process_isolation

Il fatto che vengano usati gli stessi eseguibili e le stesse librerie non rompe l'isolamento.
In generale, lo stato di un'istanza non influenzerà lo stato di un'altra istanza, almeno finché non vanno a collidere verso una risorsa comune (es. il database, il filesystem, il registro di windows, e così via).

Ho semplificato l'esempio, ad ogni modo mi sembra più logico (e funzionale) bloccare all'utente la variazione, con la sola possibilità di visualizzare i campi, piuttosto che permettere di variare il tutto e poi magari scoprire delle collisioni,

Usando la concorrenza ottimistica, il lavoro dell'utente non viene perso. Semplicemente, gli puoi notificare che un certo campo è cambiato e gli fai decidere se integrare i cambiamenti oppure scartarli.
Se supporti l'editing collaborativo in tempo reale, l'utente vedrà che qualcun altro sta modificando una casella senza che debba attendere il salvataggio per saperlo.
Con la concorrenza pessimistica poni un blocco alla produttività degli utenti. Spesso, utenti che modificano in maniera concorrente la stessa anagrafica lo fanno per motivi diversi: c'è chi modifica un errore nella ragione sociale, c'è chi aggiunte un estremo di pagamento, c'è chi cambia la classe del cliente e così via, secondo la propria mansione. Per questo motivo dovresti spezzare la mega-form in parti più piccole e, in caso, bloccare solo quelle. Le task based UI hanno proprio il compito di assecondare il comportamento degli utenti con comandi specifici, anziché avere 100 campi e un tasto "Salva" alla fine. Questo è un esempio di Task Based UI, in cui i pochi cambi che compongono l'anagrafica dell'utente viene spezzata in 3 parti, ciascuna con il proprio comando di aggiornamento.
https://jsfiddle.net/cg7ggmo1/1/


ciao,
Moreno

---

Modificato da BrightSoul il 23 novembre 2017 20.07 -