Newsgroup: it.comp.programmare
Titolo: Consiglio per il seguente progetto utilizzando C#

Supponiamo avere N pc distribuiti in N stanze.
Supponiamo avere M operatori che possono spostarsi da una stanza ad 
un'altra.
Ciascun operatore gestisce una sua form per caricamento dati.In ciascuna
stanza ciascun operatore può caricarsi la sua form e continuare a 
caricare dati fino a quando non memorizza tutto.
In quest'ultimo caso l'operatore che ha memorizzato i suoi inserimenti 
può aprire una nuova form vuota.
Spero di essere stato chiaro.
Come ho pensato di agire ?
Ciascun operatore ha un codice.
l'operatore op1 apre una nuova form nella stanza ST1 ed inizia a 
caricare i suoi dati.
All'apertura della form (legata ad op1), sul server si crea un file xml 
identificato con il codice op1.
Da ciascuna stanza op1 può aprire il form o ricaricare il form sulla 
base dell'esistenza e del contenuto del file xml.
etc. etc.
Che ve ne pare di questa idea ??
Aspetti positivi e negativi.

 Che ve ne pare di questa idea ??
Che, spiegata cosě, sembra una web application senza il web. 
-- 
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non č valido)

 
In effetti hai ragione.
Si tratta di un'applicazione desktop che deve girare su macchine che 
fanno parte di una rete lan.

 fanno parte di una rete lan.
Scusa... ma usare un database e' contrario alle tue specifiche?
ciao
S

 S
Non è per questo che mi volevo indirizzare a un file xml ma per evitare 
di gestire dei dati continuamente connessi alla base dati, cosa 
contraria ai consigli di ado net che spinge nell'utilizzare dati 
disconnessi.

 dati disconnessi.
In questo caso mi pare di capire che dai diversi terminali è 
indispensabile che l'operatore veda dati coerenti tra loro e quindi la 
connessione è indispensabile, che sia per la condivisione del file XML 
o per l'accesso a un DB.
A meno di non mettere in piedi un sistema peer-to-peer dove ogni nodo 
può passare il documento corrente al nodo successivo dove si sposta 
l'utente. In questo caso non hai connessioni fisse verso il server, ma 
se la rete non funziona, comunque tutto si ferma.
-- 
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non è valido)

 se la rete non funziona, comunque tutto si ferma.
Questo è una soluzione che ho scartato perchè troppo pesante dal punto 
di vista della sincronizzazione.
In ogni caso se la rete non funziona il problema si porrà sempre sia che 
uso il db o xml a meno che non decida di utilizzare una logica disconnessa.

 logica disconnessa. 
Se realizzi una logica disconnessa parti dal presupposto che i dati 
non possono essere sempre coerenti e che, probabilmente, dovrai 
trovare poi un modo di "riconciliarli".
Se hai un operatore che, da terminali diversi, inseriscono 
informazioni che serviranno per generare, ad esempio, un unico 
scontrino, la logica disconnessa non va troppo bene... a meno di non 
inseguire il cliente per fargli pagare qualche cosa che era stata 
registrata su una postazione momentaneamente non in linea...
Forse se spieghi il tuo problema e non la soluzione che tu hai 
ipotizzato qualcuno ti darà qualche idea brillante. Non prenderla come 
un'offesa o uno sminuire le tue capacità, semplicemente considera che 
molte teste a volte ragionano meglio di una o, magari una delle molte 
teste ha già affrontato problemi simili al tuo e ti potrà dare una 
soluzione di cui ha già valutato (magari sul campo) pro e contro.


disconnessi.
Temo tu stia fraintendendo. Gestire i dati "disconnessi" non implica
affatto non doversi poggiare su un DB.

 
Hai ragione,
forse non ho spiegato benissimo il problema ma credo che hai compreso 
bene la problematica.
Lo rispiego:
Ho varie postazioni, supponiamo di parlare dei reparti di un ipermercato.
L'operatore puï¿œ spostarsi da un reparto ad un'altro richiamando sempre 
la sua form di inserimento (di dati parziali).
Alla fine conferma l'ordine e i dati da parziali diventano completi e 
pronti per essere messi in coda in una cassa.


 Spero di essere stato chiaro.
In questo caso credo che un DB (magari con tutta la ridondanza 
possibile compatibilmente con le dimensioni e il costo della 
soluzione) sia da prendere in considerazione per garantire la coerenza 
dei dati tra un passaggio e l'altro e, soprattutto, per garantire che 
quando si arriva alla cassa tutto quello che doveva arrivare sia 
effettivamente stato salvato e computato. Generalmente la gente tende 
a diventare pignola e irritabile quando c'� di mezzo la pecunia...
Il file condiviso in rete pu�, secondo me, creare pi� problemi di 
quanti ne risolva e credo che, comunque, i dati alla fine andranno 
salvati in un DB (non credo che per fare la contabilit�, statistiche 
di vendita o calcolare le giacenze sia comodo smazzarsi un tera di 
file XML...).
Un'altra possibilit� � quella di usare i webservices ragionando a un 
livello pi� alto rispetto ai semplici record del DB (ma questo dipende 
anche dalla complessit� dei dati e delle logiche che entrano in 
ballo). 
Anche in questo caso, comunque, il requisito � una rete affidabile al 
100% e sar� compito del server garantire la coerenza del tutto (le 
cose potrebbero complicarsi se devi, ad esempio, garantire che a 
magazzino ci siano davvero tutti gli articoli richiesti etc.).
-- 
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non � valido)

 
Non so se è fattibile ma un modo per convolgere il db marginalmente è 
quello di fare un clone della form in un istante x su un db e ricreare 
l'intera form con i dati su un'altro pc.
Non so se la cosa è fattibile ma in c# penso di si:
Si tratta di una sorta di serializzazione.

 Si tratta di una sorta di serializzazione.
Se aggiorni i dati nello stesso DB salvandoli in chiusura e 
ricaricandoli all'apertura della form non hai lo stesso risultato? 
Magari con la possibilità di usare le transazioni per poter annullare 
o salvare in blocco le modifiche.
Ovviamente dovrai gestirti bene il caso in cui l'utente modifica i 
dati su un PC e poi prova a riaprirli da un altra parte senza 
confermare o annullare le modifiche fatte in precedenza. Ma anche per 
questo basta un'informazione nel DB che ti dica se e dove i dati sono 
in modifica...


 confermare o annullare le modifiche fatte in precedenza. 
   Appunto,
   è questo il problema.
   A meno che ogni dato inserito non lo salvi nel db.


    A meno che ogni dato inserito non lo salvi nel db.
l'utente deve inserire i dati e memorizzarli quando si sposta.
I dati faranno parte di un ordine incompleto.
Quando confermerà, alla fine, l'ordine diventerà effettivo.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 
Esatto è il modo che avevo pensato.
Solo che sono indeciso se memorizzare la serializzazione degli oggetti 
oppure i dati passati tramite un datasetm (quindi dati disconnessi) 
oppure mantenere i dati connessi con il db.
Ecco i miei amletici dubbi.

oppure mantenere i dati connessi con il db.
Non capisco perché vuoi complicarti la vita. Usa il database.
(Ti ripeto con la logica "disconnessa" non impedisce affatto di usare
il database; č, di fatto, la logica usata con Delphi/DataSnap).