Newsgroup: it.comp.lang.visual-basic
Titolo: ACCESS IN MULTIUTENZA

CIAOO!
Sto sviluppando un prg che dovrà girare sia in single user sia multiuser
utilizzo ACCESS in single user... Qualcuno ha consigli, opinioni e/o
brandelli di codice?
Qualcuno ha sperimentato i componenti ADO con MDB in multiutenza?
Grazie in anticipo
PAMELA
--------------------------------
Inviato via 
http://usenet.libero.it

 Qualcuno ha sperimentato i componenti ADO con MDB in multiutenza?
idem.
ciao
ugo

[*Ugo Mangini* = 
ugoma...@tiscalinet.it
 in
news:bBCcb.119786$
hE5.4...@news1.tin.it
] ha scritto:

Questo appare, come spesso accade, una disfida fra Ugo e me. Non lo è, non
per mia intenzione.
Uso Access e DAO in multiutenze di circa 200 aziende, diciamo, 3/500
macchine.
Se escludiamo guasti hardware (rete/dischi) e cadute di tensione, nessun
problema, da anni.
E io, se permettete, non mi lamento se la mia auto si ferma solo perchè
manca il carburante...
E, come m'è già capitato di dire, prima o poi proverò a togliere la spina a
un SQL Server, + RAID.
Ok, ha un LDF (log) che è più grosso dei dati, ma non sono per nulla
convinto, pur col log, che non si scassi il database... Proprio per nulla.
Cerca in Google e questo NG le parole lock, blocco

 problema, da anni.
In effetti mi trovo nella stessa situazione di Lupo.
Noi abbiamo impianti in Access in multiutenza con anche decine di 
macchine che scrivono e leggono a manetta.
Se si escludono problemi di rete (cioč si ha una rete testata, e nessuno 
ti strappa i cavetti inciampando), di caduta di tensione e se nessuno 
spegne il server mentre le altre macchine ci stanno lavorando sopra di 
problemi non ce ne sono (incredibilmente!)
Poi occorre tener presente che access tende a gonfiarsi, quindi una 
ricostruzione ogni tanto non fa mai male.
E se Pamela usa ADO puň anche lavorare a Recorset disconnessi, cioč 
leggere il recordset, disconnettersi dal DB (quindi eventuali perdite di 
"contatto" non porterebbero a danni) lavorare sui dati, e eventualmente 
riconnettersi per scrivere le modifiche.
Ciao


Con buona pace tua e di Lupo, non ho detto che non funziona.
Anche noi abbiamo applicativi in multiutenza su base dati access che girano
senza problemi.
Ciò che dico è solo che _prestazionalmente_ non ci sono paragoni con un
motore client-server.
ciao
ugo

 ha scritto nel messaggio
news:xeTcb.169875$R32.5...@news2.tin.it...

Forse il nocciolo della questione è la quantità di dati da maneggiare.Se è
tale per cui Access la regge allora viva Access e DAO ma se è troppo grande
allora bisogna passare ad un'altro DBMS e ADO.
Altro fatto è che Access è un vero e propio piccolo gioiello ed abbandonarlo
a volte è dura.
SunRex

 allora bisogna passare ad un'altro DBMS e ADO.
Come dice Ugo, il problema è che se ci sono i DBM server un motivo c'è.
Prestazionalmente non saprei dire fino a che punto è più veloce un SQL 
server di Access/DAO.
Sicuramente un SQL server è più sicuro.
Ciao

 a volte è dura.
Personalmente l'unico motivo per cui lo uso è che si può programmarlo
in VBA :-)
Ciao
-- 
Giorgio

 Un limite di Jet è l'assenza di campi BLOB o simili.
Jet HA un tipo di campo BLOB, lui lo chiama OLE, ma in realtà non è ne 
più ne meno che un campo BLOB, anzi, usarlo come OLE è secondo me pure 
pericoloso (lui registra i riferimenti all'oggetto di default che 
manegga il dato se usato come OLE).
Ciao

 in VBA :-)
Mai usato VBA. Access (il motore Jet, non mi risferisco all'applicativo Ms
Access) è valido di per se.

 documento. Semmai, solo il link al file fisico.
Prova a far stampare a crystal report un'immagine indicandogli il 
persorso se ci riesci :)
Ciao

 all'applicativo Ms Access) è valido di per se.
Io parlavo dell'applicativo. Sul motore Jet in un server, riferendomi al
discorso sull'utilizzo di questo piuttosto che SQL Server per via dei costi,
non ho nulla da eccepire!
L'applicativo, invece, se devi utilizzalo come front end per il DB che gli
stà sotto (cioè nello stesso file mdb insomma) lo uso perché conosco tre
cosette di VB e mi risulta più facile automatizzare certe cose (magari
usando ADO).
Ciao
--
Giorgio


 all'oggetto di default che manegga il dato se usato come OLE).
Chiarisco che intendevo il caso in cui Jet sia usato come motore con Access
come front end per il DB Jet (cioè usando Access stesso per visualizzare il
DB!).
Ero convinto che fosse vero il contrario. Cioè che i campi OLE di Jet usati
come contenitori fossero pericolosi o per lo meno ci fosse un bug (di cui mi
aveva parlato qualcuno in un vecchio post che ora fatico a rintracciare, ma
forse era solo in Jet precendete al 4.0) che impedisce di usare AppendChunk
et similia.
E' sbagliato?
In definitiva se popolo un campo Ole tramite ADO usando
rs.Fields("TaldeiTali") = AppendChunk Qualsiasicosa
una maschera o un report di Access non mostra un bel niente.
Si può fare invece?
A parte che potri sbagliare anche su questo, la confusione l'ho fatta
mescolando il motore Jet con l'applicativo Access.
Ciao
--
Giorgio


 Si può fare invece?
Io ho avuto necessità (per fortuna) di farlo solo in DAO (3.6), ma mi 
sembra che ADO offra le stesse capacità.
Faccio un bell'AppendChunk del file fisico bmp aperto con Open Binary e 
incredibilmente CrystalReport lo vede come se lo caricasse da disco, 
solo che non permette di caricare l'immagine da disco sui dettagli!
Ciao

 persorso se ci riesci :)
Crystal Report? Cos'č?

 magari niente di tutto questo.
scena gią vista...
imvho, la scelta migliore resta quella del file system, come database per
oggetti che gią fanno parte del file system.
ciao
ugo

 > a volte è dura.
NI...
...Un gioiello, è vero, sia per aver portato i database relazionali alla
dimensione desktop, sia per le sue capacità di analisi dei dati.
Un po' meno se lo intendi come ambiente di sviluppo.
ciao
ugo

 ha scritto nel messaggio
news:bl1n8h$6slgp$3...@ID-184808.news.uni-berlin.de...

http://support.crystaldecisions.com/communityCS/FilesAndUpdates/cr8_vb_rdc_loadpic.exe.asp
ciao
ugo

 Crystal Report? Cos'è?
E' quello schifo di strumento per stampare che hanno deciso di usare.
Ciao
--
Math Parser : 
http://www.neodatatype.net
Sito Comune : 
http://www.it-lang-vb.net