Newsgroup: it.comp.os.dibattiti
Titolo: Le nuove frontiere dell'informatica... le applicazioni creative

Salve
Ieri mi telefona un collega... direi un pelino preoccupato
mi espone un problema: e' andato da un cliente che deve fare una wan con
applicazioni su thin client, niente di che... poi pero' dice che altri
consulenti di questa ditta hanno proposto un software in grado di continuare
a girare anche nel caso che le varie adsl, hdsl, vpn che collegano le sedi
alla sede centrale crollino
in pratica, parlando di un disconnected cursor, asserivano che era possibile
continuare a lavorare sul database sql anche senza la connessione con
esso...
onestamente, o io mi sono perso qualcosa e in questo caso saro' grato a chi
mi insegnera' qualcosa di nuovo che ora non conosco, o qui si parla di
software 'creativo', ovvero di materializzare dal nulla un dbsql e di
lavorarci anche se non connesso, cosi', immaginandolo :-)
al momento, tentando di interpretare quello che era stato riferito, avrei
pensato ad una pseudo soluzione con xml... ma gradirei dei commenti....

 connessione con esso...
Thin client e terminal server? Non capisco dov'è il problema, se cade la 
connessione si disconnette il client, ma il programma può rimanere in 
esecuzione (volendo) e di conseguenza saldamente connesso al database. 
Quando il client si riconnette riprende da dove era rimasto.

 Quando il client si riconnette riprende da dove era rimasto.
allora, senza nessun intento di flame, ma
1) mi devi spiegare come in un thin client puo' rimanere attivo il programma
(io per thin client intendo un thin client vero,  non ha manco il disco
questo eh... funziona proprio da terminale) e quindi l'applicazione in
realta' gira sul server... ora se la linea e' giu' qualcuno mi spiega come
fa il programma ad andare sul terminalino? mah... ok
2) ammesso e non concesso che il thin client viva di vita propria, se la
connessione con il database non c'e' piu', come cazzzzzzzarola recupera i
dati?

 fa il programma ad andare sul terminalino? mah... ok
Chiedo venia, ma ho il sentore che tu abbia frainteso... se la linea 
cade, cade, ed col terminale ci fai ben poco, ma ovviamente appena la 
linea ritorna hai di nuovo il terminale com'era prima che la linea cadesse.
Almeno credo che sia questa la situazione.
Fabio Alemagna

Chiedo venia, ma ho il sentore che tu abbia frainteso... se la linea
cade, cade, ed col terminale ci fai ben poco, ma ovviamente appena la
linea ritorna hai di nuovo il terminale com'era prima che la linea cadesse.
Almeno credo che sia questa la situazione.
ok questo lo so, d'accordo
ma i tipi asseriscono di poter continuare a lavorare sul db anche a linea
caduta...
e tu capisci che qui o parliamo di negromanzia o di informatica (anche se a
onor del vero talvolta si mescolano...)
:-P

 caduta...
E' proprio questo il punto: credo che tu abbia frainteso. Sei sicuro che 
asserissero _esattamente_ quello?
Fabio Alemagna

 asserissero _esattamente_ quello?
si :-|

 dati?
Il thin client NON vive di vita propria, anzi vive di vita riflessa... sul 
thin client di solito non c'è alcun software tranne il sistema operativo 
embedded (di solito windows CE) e il client per terminal server. Quando 
esegue un programma è come se facesse una "telnet grafica" sul server. E' 
possibile configurare l'utente affinchè alla disconnessione la sessione 
viene "uccisa" oppure rimane appesa finchè non fa una logoff esplicita. In 
quest'ultimo caso la sessione rimane in esecuzione (ovviamente come se non 
avesse interazione utente) e ritorna disponibile al successivo accesso 
dell'utente stesso.
Tutto quà. 

 Tutto quà.
ehm guarda
lo so
li vendo pure :-)
li installo
li uso
il problema e' che c'era qui diceva che
1) il thin client viveva di vita propria
2) poteva interagire con i dati del db della sede centrale anche se la
connessione cadeva...
(forse mi ero spiegato male)

 (forse mi ero spiegato male)
Direi che dipende da quanto "thin" e`
questo "client".
Magari ha un discreto e scaltro sistema
di caching...
In generale, pero`, mi pare una contraddizione
in termini...
bye,
-- 
piergiorgio

 in termini...
esatto
cache=0.

 I DATI MICA SE LI POSSONO INVENTARE :-D
Gia`, ma se i thin client invece di chiedere
dati, li mandano, il tutto puo` continuare senza
alcun sentore della caduta della connessione.
Poi, che vuol dire, magari il thin client ti
dice:
"Attende Prego"
E ti fa attendere, no?
D'altronde ci siamo abituati...
bye,
-- 
piergiorgio

 connessione cadeva...
Sembra un indovinello da settimana enigmistica: "Qual'è quella cosa che gira 
su thin client e interagisce con i dati del db anche quando cade la 
connessione?"
E come tutti i quiz vedrai che c'è il trucchetto sotto :-) Un software che 
lavora con i dati in differita risponde all'indovinello, pur essendo una 
soluzione elegante come una discarica abusiva :-)

 pensato ad una pseudo soluzione con xml... ma gradirei dei commenti....
Ado fa queste cose dalla versione 2.5. Certo che però, dipende dalle
dimensioni
dei recordset disconnessi. 2 Gb di dati in XML non sono proprio il massimo
della leggerezza , senza contare che poi devono arrivare sui dischi del
client :-).
Saluti.

 recupera i dati?
è il server che si connette al database, non il client. Il client si 
limita a prestare il suo hardware per emulare una console
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.20. C, C++ and ASM developers
                              and beta testers are welcome!

 D'altronde ci siamo abituati...
rofl :-)

 limita a prestare il suo hardware per emulare una console
ok, lo ammetto vostro onore, mi sono spiegato alla cazzo
allora, per rimettere le cose a posto
alcuni sostenevano che:
1) le sedi anche ad adsl crollata potessero comunque lavorare con i thin
client (che erano collegati alla sede centrale sia per l'applicazione che
per il database)
2) che poteva continuare l'iterazione con il db
(sempre a linea crollata)

 client :-).
ecco, allora mi confermi la mia ipotesi ok
e poi voglio vederli 2 gb di xml su 1 thin client....
che se ha 16 mega di flash e' gia' tanto...

 esso...
Ciao..
Se parli del "disconnected Recordset" crea un "memory mapped file" per
immagazzinare i dati, ma non č pensato per permettere a un applicazione di
funzionare anche quando il sever sql č down, ma servono per alleggerire il
carico per le applicazioni WEB.
Se dovessi gestire una fault tollerance io penserei piů a un uso di
Microsoft Message Queque.
MAX

 (sempre a linea crollata)
Hai fatto indagini anche sul dolcificante che usano per il caffe'?
Non tutta la roba bianca e' zucchero... :-)
C:\>iao Angelo
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Non tutta la roba bianca e' zucchero... :-)
e' uno dei sospetti...

 e' uno dei sospetti...
 
Infatti io pago ogni mattina 50 euro di caffè, e non sono un gorilla :p 

 wrote in
news:asf4g0$qd6sb$
1...@ID-167090.news.dfncis.de
: 

Occhio che non stiamo parlando di thin client. Un thin client come intendo 
io non ha software che gira in locale, quindi è perfettamente assurdo che 
si porti un solo byte di dati sul client qualunque sia la tecnica.
Poi per carità, windows embedded è programmabilissimo e niente vieta di 
caricarci sopra il software client, tutto l'ambaradan, ado (adoce?) e due 
giga di dati usandolo come se fosse un normale client (non so nemmeno se 
abbia senso, ipotizzo). A che pro? Per avere un client senza disco, che può 
lavorare disconnesso ma che in compenso ha un solo, grosso pulsantone che 
appena lo pigi ti ricorda quanto è effimero questo modo di lavorar 
disconnesso dal database... :-)