Newsgroup: it.comp.programmare
Titolo: Consiglio

Linguaggio di programmazione utilizzato c# (Visual Studio 2005)
Spiego velocemente il mio quesito:
2 postazioni di lavoro  : Postazione A, Postazione B:
Postazione A  : crea e gestisce una sequenza di Lavoro.
Appena la sequenza in A termina, allora il risultato dovrà essere 
manipolato in una particolare schermata nella Postazione B.
Se la schermata è impegnata, allora il processo verrà messo in coda.
Spero di essere stato chiaro.
Secondo voi è necessario la gestione di Thread ??
Attendo fiducioso vostri consigli.

Hinoki ha scritto:

Quindi B fa da server
Quando A ha finito la procedura invia a B il risultato.
B lo mette in coda e quando e' pronto lo processa.
Le due macchine come sono connesse? TCP/IP?
Il risultato da inviare alla postazione B in che cosa consiste?
Intendo dire quanta roba e'?
Ci sta in un XML?

 Secondo voi � necessario la gestione di Thread ??
La soluzione al tuo problema si chiama "Remoting". Trovi tutto quello
che ti serve su MSDN:
http://msdn2.microsoft.com/en-us/library/kwdt6w2k.aspx
Saluti,
The Librarian

 che ti serve su MSDN:
http://msdn2.microsoft.com/en-us/library/kwdt6w2k.aspx
Se non sei molto pratico con l'inglese puoi anche usare la traduzione
automatica in italiano che e' davvero molto buona:
http://msdn2.microsoft.com/it-it/library/kwdt6w2k.aspx
Saluti,
The Librarian

7h3.l1...@gmail.com
 ha scritto:

Grazie.
Ci do un'occhiata.
Buona giornata a tutti.

7h3.l1...@gmail.com
 ha scritto:

Capisco di essere stato un pò vago nella mia spiegazione.
Cercherò di entrare nel particolare.
Premetto che tutte le operazione che mi appresto ad elencare possono 
avvenire sulla stessa macchina sfruttando 2 applicazioni diverse che 
puntano allo stesso database.
Immaginati il seguente scenario:
Ho un supermercato diviso in 2 zone
Zona A dove vengono conteggiati i prodotti acquistati dal cliente.
Zona B dove avviene il pagamento con eventuale rilascio di fattura.
Ebbene io devo ricreare questa situazione:
Mediante un'applicazione A vengono conteggiati i prodotti acquistati.
Il risultato viene memorizzato su un db (chiamiamolo ordine).
Quando il cliente si reca nella zona B, il commesso deve già avere in 
coda l'ordine per il pagamento ed eventuale rilascio fattura.
Mi chiedevo quale fosse la soluzione migliore.
Avevo pensato ad una sorta di timer che permettesse il refresh dei dati 
letti dal db ma non so se è la soluzione migliore.
Spero di essere stato + chiaro.
Buon lavoro a tutti

 letti dal db ma non so se รจ la soluzione migliore.
A scrive in una tabella i dati dell'ordine, rilasciando un codice di
riferimento.
B recupera dalla tabella i dati dell'ordine mediante codice di riferimento.
Una procedura notturna spazza via tutti gli ordini inevasi.
Niente timer, niente client/server, niente di niente.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 
Ok.
Metti però che voglia fare caricare automaticamente questi ordini in una 
schermata già aperta, come fare ?
E' in questo punto che interviene la gestione di un timer che fa una 
sorta di requery (se esistesse in c#)

schermata già aperta, come fare ?
Se vuoi fare in modo che queste due applicazioni siano sempre
allineate, scrivi i dati su db e poi fai notificare la presenza di una
nuova informazione, facendo comunicare A con B via socket. Bada che in
generale questo non è il modo migliore di lavorare. Le schermate non
fanno vede circa la bontà dei dati; quello che fa fede è il db.
Nel tuo caso, però, una segnalazione via socket può aiutarti ad
aggiornare una maschera che deve sempre restare aperta.

 generale questo non è il modo migliore di lavorare. 
Bhè se mi suggerisci il modo migliore ne tengo conto.

 sorta di requery (se esistesse in c#)
Da quanto ho capito:
1 Il cliente nella zona A fa gli acquisti
   che vengono registrati su DB usando
   come chiave (ad esempio) il suo nome e
   cognome.
2 Il cliente va nella zona B e da' il suo
   nome e cognome all'impiegato che usa
   un'altra applicazione per recuperare
   i dati dal DB e fare la fattura.
Dov'e' la necessità di sincronizzare le due applicazioni?
Anche se il passo 2 fosse:
2' Il cliente va nella zona B. Il primo
    impiegato libero trova il suo ordine in
    coda e lo chiama per fare la fattura.
Non ci sarebbe bisogno di timer o altro: l'applicazione della zona A 
mette l'ordine nello stato "da fatturare" e registra un un timestamp. 
L'applicazione B fa una select del primo ordine in stato "da fatturare" 
ordinando per timestamp.
Cosa manca rispetto a quello che serve a te?
Remo D.

Mi fai un esempio di comunicazione via socket ? 
GIYF

Dov'e' la necessità di sincronizzare le due applicazioni?
Per Hinoki: per capirci, quello che illustra Remo è il modo migliore
di lavorare e cioè affidarsi al DB quale unica fonte di informazione.
Per Remo: credo che Hinoki abbia bisogno di un sistema che mostri le
informazioni sulla coda degli utenti, a video, allineate in tempo
reale, quindi dispensando l'operatore dal fare dei refresh manuali dal
DB. Questo è l'unico caso in cui ammetto l'uso di una sincronizzazione
forzata tra A e B.

 forzata tra A e B.
Esatto,
questa è la mia esigenza.

Hinoki ha scritto:

Capisco. Pero' anche in questo caso la sincronizzazione avviene tra 
l'applicazione B ed il DB, non tra A e B.
Semplicemente B fa il polling sul DB ogni tot secondi ed aggiorna la 
lista sul video dell'operatore. A lavora in modo completamente asincrono 
da B, sono accoppiati solo sul DB.
Meglio ancora, spezza B in due parti: B1 gestisce la lista di ordini e 
B2 processa un ordine. Anche loro accoppiati sul DB.
L'unico caso in cui mi sentirei di creare un collegamento tra A e B è se 
A puo' segnalare a B che deve smettere di fare qualunque cosa stia 
facendo perche' c'e' un urgenza. E anche in questo caso cercherei 
un'alternativa via DB se solo fosse possibile.
Considera che se vuoi fare le cose per bene devi gestire delle code  di 
messaggi nell'applicazione B (mica vorrai perderti qualche segnalazione 
da A, visto che sono cosi' urgenti ...). E poi A vorrà avere qualche 
forma di acknowledgment da B, magari deve rimandargli il segnale ...
Nel frattempo A che fa lo mettiamo in attesa dell'ack?
Volendo possiamo complicare a piacere.
Certo, nulla che non si possa fare via socket con TCP/IP (o UDP) ma ne 
vale la pena?
Remo.D

da B, sono accoppiati solo sul DB.
No, il polling su DB lo eviterei. Si rischia di produrre un mare di
interrogazioni inutili. Una bella notifica asincrona da A a B è una
cosa orribile, ma in alcuni casi necessaria (non la userei mai per un
gestionale che non avesse di tali esigenze specifiche).


Questo è un metodo *assolutamente* pulito di fare la cosa (e logicamente
corretto), ma sui due piedi non saprei dire se è abbastanza flessibile.
Oh beh, non è SQL standard, beninteso.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.