Newsgroup: it.comp.lang.visual-basic
Titolo: [?] Stampe in multi-utenza

Ciao ragazzi,
obiettivo: gestire correttamente le stampe con più utenti contemporanei
1) usare un'unica tabella sul db lato server, e filtrare i record con un
campo ID_Utente
2) usare tante tabelle temporanee (esempio Tabella_X, dove X è l'ID
dell'utente)
3) usare recordset disconnessi. In questo caso tutto è in RAM e non ci sono
problemi sul db.
quale preferite delle altre? nell'applicativo che sto curando per la società
è adottata la soluzione 1, però adesso questa app deve girare in modalità
terminal server. possiamo continuare a gestire la cosa così, ma ci è stato
consigliata la 3. Io non sono d'accordo: come ho detto prima, i record
disconnessi non si appoggiano su alcun db, tutto è in RAM, e in modalità TS
hai un unico PC che deve mantenere le sessioni aperte di *tutti* gli utenti
(15-20 utenti al massimo), con stampe anche di 30 e passa pagine.....
voi come avete risolto questa problematica?
grazie!!!
-- 
Damiani Liborio Igor
ig...@igordamiani.it
 - 
soft...@igordamiani.it
 - 
idam...@hotmail.com
http://www.igordamiani.it
ICQ : 11847262

 ha scritto nel messaggio
news:bi4i8r$57hih$1...@ID-134521.news.uni-berlin.de...


sì, giusto, come facciamo adesso. se ho 4 client e un server, sul server ci
sono i db condivisi, e qui ok.
sui 4 client, invece, ho un piccolo db di appoggio per le stampe. Come
faccio a gestirlo in modalità terminal server? non posso, per questo stiamo
studiando una soluzione alternativa.....
in modalità TS, infatti, tu l'applicazione la installi SOLO sul server. I
client sono puliti, e usano l'app tramite una sorta di desktop remoto,
capisci? sui client quindi non c'è più nulla, è tutto sul server.
Il server ha il compito di gestire più sessioni della stessa app, una per
ogni PC client connesso in quel momento.
aiuto....
good coding!!!


 ci sono problemi sul db.
Premesso che non so esattamente perchè ti serva una tabella per una stampa,
ma immagino che ti faccia comodo appoggiarvi i risultati di qualche
elaborazione, ti dico la mia.
Per cose analoghe, ho sempre utilizzato due strade:
1) Ogni client apre una connessione ADO al server. Fintanto che la
connessione è aperta, ogni connessione può creare e tenere aperte delle
tabelle temporanee, visibili solo a livello di connessione.
Ad esempio, se io faccio Select * Into #tabella1 from tabella_dati, la
tabella #tabella1 non è fisicamente scritta sul disco del server, ma viene
mantenuta nella sua ram. Il bello è che tu la puoi usare come vuoi, anche in
join con altre tabella 'vere', e che ogni client avrà la sua #tabella1,
diversa dalle altre, ma sfruttabile sempre con lo stesso nome (questa
sintassi vale per Sql-server, ma cose analoghe valgono anche per MySql e
Oracle).
2) Per Sql-server, tu puoi utilizzare tabelle che hanno lo stesso nome, ma
proprietari diversi. Quando crei la tabella, anzichè fare un semplice create
table pippo, fai un Create Table nome_utente.Pippo
In questo modo, se ogni client si connette con un utente diverso (utente del
db, non login del server...), ogni client avrà una sua tabella su cui
lavorare. E' evidente che occorre però che la tabella venga poi eliminata,
altrimenti rimangono sul db tabelle di utenti che non esistono più, ecc...
Ciao
Alberto

 ha scritto nel messaggio
news:bi4i8r$57hih$1...@ID-134521.news.uni-berlin.de...

io terrei la soluzione 1 e come "id_utente" la coppia hostname-user

bene, ok, ci siamo capiti.....
la soluzione (2) per adesso non mi interessa. Per ora l'app gira sotto
Access.
Allora, va bene, uso tabella temporanee usando il #davanti al nome e rimane
tutto in RAM.
Sebbene questa rappresenti la soluzione, d'altro canto è proprio questo il
problema. Come ho detto prima, il tutto dovrà girare sotto TS: un unico
server (magari anche con 1GByte di RAM), dovrà avere in RAM nel caso
peggiore le stampe di 20 utenti, dove ogni stampa è composta magari da 15-20
o più pagine.....
fino a che punto posso adottare questa soluzione?
quanto mi occupa in RAM una stampa? mi conviene?
è proprio questo, credo, il problema.....
grazie, cmq, bene o male sto snocciolando il problema.....
good coding!!!


 rimane tutto in RAM.
No, direi che non ci siamo capiti.
Tu parlavi di 'lato server', nel tuo primo post, e questo mi ha fatto
pensare tu usassi un dbms server.
Se usi Access, cancella il mio post, perchè la soluzione serve a mettere
nella Ram del server Dbms, che nel tuo caso, usando Jet, coincide con il
server applicativo TS.
In alternativa, considera che ogni utente TS ha una propria cartella
documenti, all'interno della quale tu puoi generare un mdb, da usare come
appoggio per le stampe. Creare un mdb da codice è banale, al limite ne metti
uno di modello in app.path, e lo copi nella cartella documenti dell'utente
TS (cartella che, se ben configurato TS, sarà non visibile agli altri utenti
e accessibile da ciascuno sempre con lo stesso percorso.
Rimane valido un consiglio: se puoi passare a db un filo più 'pro',
soprattutto entrando nel merito di terminal server che ha delle peculiarità
nell'assegnazione di risorse e Ram che potrebbero incasinarti la vita,
fallo.
Ciao
Alberto

Io penso che tutto dipenda da quanto tempo devo rimanere
persistenti i tuoi dati. Se queste tabelle temporanee le usi solo
per appoggiare dei dati i l tempo materiale di create il layout
e fare il rendering dei dati sul canvas object, penso che la
soluzione delle tabelle temporanee non ti andrà mai a creare
problemi a meno che non incomincia a crescere in maniera
spropositata il numero di utenti/pagine ... ma anche li credo
sia un limite abbastanza elevato.
Access riesce a gestirti con una certa elasticità anche 1
milione di record ... quindi se l'applicativo non è pesantissimo
penso che puoi stare tranquillo anche fino a 50 utenti.
Alternativa che vedo è quella di utilizzare l'adox creare dei
piccoli database paralleli per sessione stampa e segarli
quando hai finito.
In questo modo il thread di lavorazione della stampa lo
puoi scaraventare su un oggetto connection parallelo.
Soluzione magari poco pulita da un punto di vista logico
perchè 20 utenti significano 40 connessioni, ma se è solo
per la stampa è un piccolo compromesso che puoi sopportare.
Oppure, io mi butterei su un altro sistema di stampa ancora,
quello dei prefilled. Non sò cosa scriva e cosa faccia il
tuo applicativo, ma potresti - tipo con AR 2.0 pro - fare
dei modelli salvati come file frx, quindi caricarci dentro un
file di testo con i dati proprio come se fosse un prestamapato.
Allora li niente più connessione. Una routine scrive il file
con i dati, una ti apre il report con il file dati, li associa e stampa.
Dipende da dove sei arrivato e cosa vuoi andare a buttar
via.
-- 
Saluti
Andrea Moro

sì, hai ragione, scusa......con "lato server" intendo che ho tutta una serie
di MDB in una directory condivisa sul server, punto e stop. poi, su ciascun
client, ho un piccolo mdb di appoggio per le stampe.
scusa per il malinteso, cmq hai afferrato al volo la situazione.....
stavo già provando velocemente le tabella temp con Access, ma a quanto pare
con Jet non sono supportate, perchè mi dà un errore nella query in
corrispondenza del carattare '#'.
in effetti una (4) possibilità sarebbe quella che hai detto tu, cioè
mantenere in qualche modo il db di appoggio per ogni utente, copiandolo
nella dir home di ogni utente ad ogni connessione, partendo da un modello
vuoto del db.
potrebbe funzionare.....
per quanto riguarda il database, effettivamente Access è scarso, per cui è
già stato pensato di preferire Oracle, che viene già utilizzato dalla nostra
app, anche se in altri ambiti. Sicuramente con questo db le prestazioni sono
migliori; però mi rimane sempre il dubbio su che meccanismo scegliere per
questo discorso.
l'architettura del db infatti non dipende da noi. l'applicazione viene
venduta ai comuni piccoli/medi/grandi, alle ASL e ad altri organi della PA.
Chi può spendere molto, prende Oracle, altrimenti Access. Io consiglio,
ovviamente, ma alla fine l'aspetto economico la fa sempre da padrona.
Per cui, dovrei implementare lo *stesso* codice in ambedue i casi. L'anello
più debole è quello che fa rallentare un po' tutti, per cui mi sa che terrò
il db di appoggio in formato Access, uno per ciascun utente e via così.....
se hai altri consigli o dritte, io sono qua....
grazie per la consulenza!!!


 sempre da padrona.
E tu dagli MSDE. Se il livello di multiutenza è potenzialmente tollerabile
da Access, con MSDE sei comunque un gradino sopra, sia come stabilità che
come performance.
E, soprattutto, il codice che scrivi per MSDE, è compatibile al 99% con
Sql-Server, e, se lo scrivi con della testa, al 90% anche con Oracle, per
cui teoricamente, evitando certe keyword non supportate da uno o dall'altro,
riesci a scrivere codice che può permettersi di scegliere il db a runtime.
Ciao
Alberto

 Ciao ragazzi,
ADO 2.5 permette di costruire e leggere file xml e trattarli come recorset
Potrebbe essere una soluzione ?
giusppeD

proprio negli ultimi 15 minuti stavo valutando anche questa idea......
non l'ho mai fatto, mi leggo bene su MSDN e poi sperimenterò qualcosa......
thanks, good coding!!!
