Newsgroup: it.comp.lang.visual-basic
Titolo: Gestionale multiutente

Dovrei implementare un db multiutente in una rete locale che prevede circa 8
posti di lavoro.
Vorrei dei pareri sull'opportunità di usare un db (o più di uno, ovviamente)
access su file server o un db SQL come MS SQL Server o mySQL.
L'idea di fondo è di avere comunque un temporaneo mdb in locale per poter
annullare le operazioni di modifica di documenti e dati vari da parte degli
utenti.
I problemi di sicurezza sul db sono relativi, mentre risultano determinanti
aspetti legati alle performance e alle transazioni.
Grazie.
--
********************************************
Giorgio B. - P.S. elettronica srl - Udine
email: 
giorgio....@ps-elettronica.it

 Grazie.
un solo consiglio: lascia stare access;
ciao

 un solo consiglio: lascia stare access;
diavoletto, non centellinare :)
tu che usi in un sistema con nt4 al centro e tanti 95/98 intorno ?
NON DIRMI LINUX CHE URLO !!!
:)))


Rispondo qua perché mi sono perso il msg originale.
Se puoi scegliere e non te la senti di fare una scelta molto coraggiosa come
mySQL dato il basso numero di utenti puoi sempre buttarti su MSDE: stesso
motore di SQL Server, costo 0, facilità d'uso come Access2000 (dicono perchè
non ho provato con mano) o se disponi cmq di SQLServer come quest'ultimo
perché dal suo enterprise manager sono gestibili anche db MSDE, non ho
ancora capito come si installa, performance discrete rispetto al numero di
utenti che devi far lavorare, ottima scalabilità verso il fratello maggiore
in un prossimo futuro.
Per quanto riguarda il db locale per le transazioni mi sembra un po' un
ca__ata, esistono le transazioni sia su access (dove non funzionano molto
bene per la verità) sia su MSDE (che da questo punto di vista si dovrebbe
comportare come il fratello maggiore) e mi sempra logico usarle. Non vorremo
mica tornare a quei modelli con i file temporanei di dati da trasferire a
fine giornata alla base dati centrale vero? Siamo nel 2000 in fondo! (Guarda
che sto scherzando ;-). Ognuno è libero di sbagliare come meglio gli pare,
solo che io so sbagliare molto bene e quindi mi sento in grado di dare
consigli. Correggimi se sbaglio....
Ciao, Rick.

 :)))
se non ricordo male a suo tempo gia ti dissi cosa ne penso di access: _non è
un database_ ma un _file_ che contiene dati strutturati in modo che le varie
librerie DAO/JET riescano ad _emulare_ il funzionamento di un database;
access è valido in modalità workstation stand alone (della serie il file mdb
è sul mio pc e lo uso solo io) o al massimo in situazioni con pochi o
pochissimi client "fidati" (in ogni caso tanti auguri);
in una situazione Win 9x/NT/2000, le alternative sicure sono molte, eccone
alcune
1) se i client non sono molti e magari sono poco affamati di dati è
possibile utilizzare con successo MSDE (gratis);
2) se i client sono tanti, se si ha voglia di performance e (soprattutto) si
hanno soldi da spendere (....) SQL Server rappresenta sicuramente la
soluzione migliore
3) esistono altri db commerciali (Oracle, Informix, Sybase, ecc.) ognuno con
caratteristiche positive e negative; personalmente ho usato Sybase e devo
dire che va benone;
4) se si ha voglia di sperimentare, si può anche tentare la strada di
PostgreSQL (open source) per NT o al limite di MySQL (stesso discorso, ma
molto più incompleto di Postgres); p.s.: non ho mai utilizzato MySQL o
Postgres in ambiente NT.... se qualcuno ha tempo di provarci e riesce a
tirar fuori qualcosa di buono mi faccia sapere
ciao
p.s.: ah, pal, ho da pochi giorni disinstallato NT4 dal mio server di
casa... indovina qual è adesso il "motore" del mio server adesso? vuoi
sapere se funziona? tu che ne dici? .... ok, urla pure :))

 sapere se funziona? tu che ne dici? .... ok, urla pure :))
hai messo win2000 come server ? bene, bene :)
uno come te era il minimo che dovesse fare. se linux non lo mettete a punto
voi bravi, noi zucconi chi ci aiutera' poi, quando ci passeremo in blocco ?
pero' non so se hai visto le considerazioni nell'altro thread. impressione
mia e' che ms abbia mirato _esattamente_ al target di gente nella mia
situazione, e ci abbia pure preso... ma, a differenza del tempo, le vie di
linux sono infinite -- tu intanto fai esperienza, mi raccomando, quando
dovro' far riscrivere le mie schifezzine vb in c a qualcuno affidabile
almeno so a chi rivolgermi. almeno un client di casa magari lascialo con un
windows, pero'... :)
e grazie davvero epr le considerazioni sul db. provero' msde appena
possibile, magari con l'interfaccia del nostro montanari. cosi' poi passare
a sqlserver sara' quasi indolore...
ciao, a.

 wrote in message
8uprf6$278$1...@lacerta.tiscalinet.it...

Purtroppo mi avvicino a VB solo ora. Ho sviluppato parecchio su Access 97
negli ultimi tre anni con grosse soddisfazioni. In quell'ambiente, per
ottenere delle form in cui l'utente potesse recedere dalle modifiche
effettuate, gli unici sistemi erano o le maschere slegate o spostare i
record da modificare in un temporaneo, aggiornando poi i dati alla chiusura
della form.
Vorrei poter risolvere la cosa più semplicemente, evitando di scrivere molto
codice, magari usando delle transazioni *automatiche*.
Della serie: se in una form access legata a un'origine dati inizio una
transazione, non posso aprire una seconda form legata iniziando un'altra
transazione, perchè MS Jet supporta una sola transazione per workspace.
Vorrei invece disporre di un ambiente in cui legare semplicemente i data
source ai controlli, avendo la libertà di iniziare una transazione per ogni
form e confermarla o annullara alla chiusura del form.
Tra le altre cose, ho provato ad accedere a dei file mdb ma con scarso
successo:
- se è attivata la protezione a livello di utente, non riesco a creare il
workspace perchè il metodo DAO.CreateWorkspace mi segnala un errore;
praticamente mi indica che non riconosce il system.mdw. In effetti io uso un
mio system.mdw che ha un nome diverso e una diversa collocazione.
- se non è attivata la protezione a livello di utente ma il db è protetto
con password, il metodo dao.opendatabase mi segnala una violazione di
password.
Come posso fare?


 aggiornando poi i dati alla chiusura della form.
[...]
--
Ciao.
Maurizio
--------
?SPQR(C)
 X
--------

 [...]
Idem c.s.



Scusa l'ignoranza, MSDE è la versione *SQL Server Like* che MS dà con VB6
per gli sviluppatori?
Io uso la 5.0 al momento e MS non la fornisce con questa versione!
Non sarebbe un problema passare alla 6.0 se fosse così.
Il db è multiutente e liberamente distribuibile come il jet?
O uno deve per forza comperarsi SQL Server per ridistribuire l'applicazione?


 wrote in message
8urcmf$s7r$1...@pinco.nettuno.it...

Mi sono risposto da solo andando a spulciare il sito microsoft. Il problema
sembrerebbe essere il n° max di Client che è di 5 utenti! Avete provato per
caso se dal 6° dà un messaggio di errore?
Bye.


 uno dei 5 abbia finito).
che abbia finito la transazione, la connessione specifica (scusa, non so che
termine usare), o che si sia proprio scollegato ?

 :-))
oddio, gia' stentavo col diavoletto... non vale, state impallando (*) un pal
se non morto certo abbastanza male in arnese :)
(*) con 2 (due) l (elle).

 >

 Il discorso che andrebbe aperto a questo punto è piuttosto lungo ma temo
che tu abbia un'idea lievemente distorta di cosa sia una transazione. Una
transazione è insieme di operazioni su uno o più database e su una o più
tabelle logicamente collegate tra loro. Talmente collegate che il fallimento
di una di queste operazioni richiede che anche tutte le altre siano
annullate per mantere la coerenza dei dati su db. E fino a questo punto
immagino tu stia dicendo:"Bella scoperta! M'hai preso per scemo?"
Assolutamente no. Ma credo che sarebbero in molti quelli pronti a dirti che
in nessun caso devi aprire una transizione quando apri la form e chiuderla
quando chiudi la form perché il concetto di transizione implica anche in
qualche modo il blocco di tutti i dati coinvolti nelle varie operazioni. E
se nel mentre l'utente si va a bere un caffé? Suppungo che quando il suo
capo cercherà di estrapolare un'analisi dai dati e non potrà farlo perché
non gli è consentito l'accesso gli gireranno non poco le p....
Di norma durante una transazione il programma non offre alcuna possibilità
di interazione con l'utente se non un pulsante di annulamento delle
operazioni.
Per fare quello che dici tu è obbligatorio scrivere del codice (e
possibilmente non usare i controlli associatio ai dati se non in read-only).
Questo perché i controlli associati ai dati ti consentono di risparmiare
tempo ma creano fastidiosi blocchi in ambienti multiutente. D'altro canto
siamo programmatori, quindi....
Se proprio ci tieni tanto puoi tentare la strada dei record disconnessi ADO,
ma sicuramente la cosa non funziona se ti limiti ad usare Access (che
dovrebbe essere un database e non un ambiente di programmazione, per quello
hanno inventato il vb).
Se ti pare che il mio tono sia troppo polemico, mi scuso subito. Non era mia
intenzione, ma il sonno inizia ad avere il sopravvento.
Ciao, Rick.


Che abbia finito la sua sessione di lavoro? O che altro?


sapere se funziona? tu che ne dici? .... ok, urla pure :))
Verra' il giorno, un magnifico giorno, che pal non fara' altro che urlare
heheheeh
Ciao
                Dbg

che abbia finito la transazione, la connessione specifica (scusa, non >so
che termine usare), o che si sia proprio scollegato ?
Secondo me che sia proprio finito, terminato, nel senso vitale del termine.


non si tratta di una questione puramente implementativa (tanto, gira che ti
rigira, un database è contenuto sempre in uno o più file) ma di una
questione logica e funzionale;
se utilizzo un vero database, la comunicazione tra il motore del database
(server) e il client è fatta in SQL, nel senso che il mio client non ha
nessuna visibilità dei files fisici di database;
la mie richieste SQL viaggiano in rete e come risposta ho dei dati
restituiti da un processo che gira sulla macchina server;
nel caso di access invece per rete passano delle normali richieste di
read/write su file, ed il server database (il processo che si preoccupa di
gestire SQL per intenderci) gira sulla macchina client;
questo comporta un degrado di prestazioni notevoli in caso di multiutenza;
il perchè è presto detto: se devo eseguire una query su una tabella, dal
momento che il motore database è sul client, ho necessariamente bisogno di
leggere _tutta_ la tabella dal server, per operare tutte le selezioni del
caso.... come conseguenza di questo ho un traffico di rete spaventoso;
prova ad immaginare cosa potrebbe significare una "SELECT * FROM Anagrafica
WHERE Nome = 'Mario' AND Cognome = 'Rossi';" nel caso in cui in Anagrafica
esistano più di 100 mila record...
lasciamo inoltre perdere il caso di query più complesse, dove sono coinvolte
diverse tabelle;
inoltre, il fatto che ogni client legga e scriva direttamente sul file MDB
rappresenta implicitamente una grossa difficoltà per le operazioni di
locking, demandate a stratagemmi di lettura e scrittura di flag che nella
migliore delle ipotesi sono tutt'altro che performanti;
e di cose ce ne sarebbero ancora da dire, ma penso di aver toccato tutti i
punti caldi della questione;
ribadisco quindi che access è ottimo in situazioni workstation in cui il
programma e il database sono entrambi sullo stesso PC senza che ci sia alcun
client ulteriore;
in una situazione piccola (2, 3 client max) in cui lo scambio dati sia basso
la soluzione può funzionare ancora, ma se la dimensione del tutto cresce,
beh, è il caso di pensare seriamente ad un vero database server;
ciao

ribadisco quindi che access č ottimo in situazioni workstation in cui
Tu intendi il programma access o il database access?
Perche' se intendi il programma access ritiro tutto, e aggiungo alle tue
critiche le mie maledizione e mcumbe varie.
Ciao
                Dbg

 heheheeh
si', di gioia -- davvero:)
ma vorra' dire che _voi.bravi_ avete finalmente messo linux su un cd che io
lo metto dentro, vado a fare colazione, e lui e' li' bello pronto. io da
user bravo-pravo aspetto..

 pal ha scritto



abbia o sia ?
e il target del marketing ms dove va a _finire_ cosi' ?

ma vorra' dire che _voi.bravi
In quel voi bravi io non ci sono (specialmente su linux), a meno che non
intendi i bravi manzoniani ....
Ciao
                    Dbg

 >ribadisco quindi che access è ottimo in situazioni workstation in cui


 intendi i bravi manzoniani ....
cioe' (facolta' di lettere) quelli che seguono in modo intelligente gli
insegnamenti di don lisander, e.g. c.e.gadda ?
:)

Grazie molto gentile, se posso evirare opss evitare :).
Si hai ragione
Ma se hai diciamo 5 -10 utenti con quella mole di dati succede un massacro,
errori casuali, blocchi del motore, danneggiamento dei dati delle tabelle
per operazione non completate, ecc.
Salve
                Dbg
pal ha scritto nel messaggio


 il programma e' filing assistant ibm, non so se avete presente... (la
versione 2, se non altro, rel. date 1989 se ricordo :)
1987. Se non ricordo male: 2 aprile 1987.


 1987. Se non ricordo male: 2 aprile 1987.
scoperta di ieri. anche il word della segr. datava 98.
"p.f. prova a portare il mouse sull'orologino in basso a destra"
"24 aprile 1998"
domani e' la liberazione ?

 vocabolario piu' aggiornato se vai avanti cosi'!)
piu' aggiornato, specie in informatica, me lo devo prendere io. e magari
capirlo. tu devi invece cercarne uno molto _meno_ aggiornato, diciamo di
quando la nonnalingua cominciava a involgarirsi... (hanno anche messo il
castiglioni-mariotti su cd, e il bastardo gira solo su cd, mentre quelli
garzanti si possono ricopiare su hd per le parti cruciali e essere sempre
inlinea)
grazie anche a te per tutte le precisazioni.
ora si' che sono in un marasma di pianificazione :)

 castiglioni-mariotti su cd, e il bastardo gira solo su cd,
Questo mi ricorda un thread del mese scorso sulle protezioni.
Sicuramente non comprero' il castiglioni-mariotti. Non mi va di apettare
eterni secondi mentre ravana il lettore cdrom.
Mi viene pero' in mente di aver visto in giro un prg chiamato FakeCD che
prometteva di far credere al pc che una certa unita' logica fosse in realta'
un cdrom, ma non l' ho mai provato.
Ciao
Aldo


 un cdrom, ma non l' ho mai provato.
si', mi e' venuto in mente subito dopo avere postato. ne sto discutendo in
ufficio, sulla versione tedesca. si chiama virtualcd e direi che funzioni.
il casino e' mettere molti cd in una lan, prob servira' win citrix ecc
ecc. -- il vantaggio e' che se li piazzi tutti su hd i tempi si abbreviano,
lo svantaggio che gli hub diventeranno roventi. col castiglioni non ho
ancora provato, ma prob in quel modo va, specie in locale.
ciao, a.

 domani e' la liberazione ?
Dalle mie parti funzionerebbe cosi`:
"p.f. prova a portare il mouse sull'orologino in basso a destra"
"24 aprile 1998"
domani e' San Marco ?


 Tu come faresti?
[...]
Scusa se non mi son fatto vivo prima ma ero impegnato. Poi ho visto che
altri colleghi erano intervenuti nel discorso dicendo piu` o meno le stesse
cose che avrei detto io e me la son presa comoda. :-)
Che conclusioni hai tratto da tutta la faccenda?



... che dovrň scrivere un sacco di codice!!!! :-((
La cosa mi scoccia parecchio e speravo di poter rsiolvere il problema piů
velocemente.
Bye.