Newsgroup: it.comp.lang.visual-basic
Titolo: concorrenza su accesso a file mdb

Uso un controllo data per aprire un file mdb su un nt (in una dir.
condivisa)
ho settato exclusive=false
uso un recordset di tipo dynaset (non credo sia importante)
vado via jet
Quando lancio il mio prg. da + di 1 pc mi dice che non riesce ad aprire
il file: //host+path
(se lo lancio solo da 1 funziona, da qualsiasi pc)
Non riesco a capire dove sbaglio, la condivisione del file e' everyone
read senza limiti di connessioni.
Penso comunque che sia un problema di vb.
Non vorrei passare da ODBC (ma se e' l'unica soluzione, pazienza) a
proposito che differenza c'e' fra jet e odbc?
Grazie
Roberto

 proposito che differenza c'e' fra jet e odbc?
su quanto hai chiesto prima al momento non mi viene in mente niente, sulla
differenza invece ti dò qualche informazione
Inanzittutto la differenza principale è che Jet è un vero e proprio motore
sql a se stante e di solito da vb si usa in modo nativo, cioè facendo
riferimente direttamente alle sue istruzioni. ODBC non è propriamente in
motore, ma semplicemente qualcosa che fa da tramite tra il motore nativo e
la tua applicazione (se guardi sul pannello di controllo ti puoi fare
un'idea), in pratica con ODBC ti crei una specie di collegamento con un
provider (che può essere jet, ecc... oppure alcuni provider prodotti per
casi particolare come recuperare dati da un AS400 ecc. ecc...).
Devi cmq tenere presente che jet non è l'ideale per applicazioni client -
server perchè ha dei limiti sia "fisici" che di prestazioni (se una query
supera i 150.000 record i tempi di attesa diventano lunghi, se ci sono più
di 5-6 utenti collegati allo stesso mdb possono succedere cose
"strane",stessa cosa se l'archivio supera il giga e mezzo) quindi non è
consigliabile se non per piccole applicazioni con un numero ristretto di
utenti. Altrimenti invece di passare via ODBC ti consiglio ADO.
By Zolfo

Cos'e' ado? (domanda stupida ma necessaria)
Io ho sentito parlare di dao (che dovrebbe essere il metodo di accesso ai dati
con odbc)
Roberto

 wrote in message
37E8BC10...@netsurf.it...

...ehm..non esattamente o meglio ODBC non è l'unico modo con cui ti puoi
collegare ad un server dunque sarò un pò più chiaro (...se mi riesce :-))
Prima una piccola distinzione tra applicazioni File - Server e una  Client -
Server
dunque la prima consiste in piccole applicazioni che normalmente  fanno
corrispondere il server con il client (ossia il database risiede sullo
stesso PC dell'applicazione, questo non è obbligatorio ma è preferibile).
Per questo tipo di applicazione di solito si usa Jet con il controllo data
oppure in maniera "nativa" se si vuole un controllo più diretto di quello
che l'applicazione deve fare. (nativa significa che invece di usare il
controllo data, il tutto viene fatto via codice).
Comunque di solito queste applicazioni anche se messe su una rete, sono di
piccole dimensioni (non più di 5-10 utenti e con archivi inferiori al GB e
mezzo)
La caratteristica principale è che il grosso del lavoro viene fatto dal
client, mi spiego meglio, se faccio una query in cui richiedo un tot di dati
anagrafici, sarà il client che si procurerà i dati necessari sul server, e
poi questi dati saranno analizzati sul client. Se questo può essere un
vantaggio (i dati sono già sul client) gli svantaggi sono ancora più pesanti
(basta pensare se devo scaricare la tabella anagrafica con 200-300 mila voci
dal server in rete il tempo impiegato e altissimo, soprattutto se magari ne
voglio solo 1 di questi dati......:-(((
Al contrario le applicazioni client-server lavorano un po al contrario,
ossia il client manda una richiesta al server che la elabora e poi manda
solo il risultato con evidenti vantaggi di "decongestione" della rete.
Allora nella applicazioni che gestiscono i dati ci sono due componenti :
1- Il server
2- Il o I client
Dunque il server può essere di qualunque tipo e forma cioè può essere
montato su nt winzoz AS400 e qui più ne ha più ne metta. Normalmente vi è un
gestore che può essere più o meno serio, da Access a SQL server a Oracle
ecc..
cmq sia attualmente i metodi per connetersi al server e ottenere dati sono 3
anzi 4..
1- Via API.....non ci credete...oppure si può fare non mi dilungo perchè non
ne so tanto e poi è un bel casino.....^___^
2- DAO (Data Access Objet) che è il motore usato da Jet e che se da una
parte ci ha abituati bene, dall'altra, scusatemi il termine, è un po
"atipico" ossia il metodo per ottenere i dati, l'slq ecc... non sono quelli
standard o meglio non sono portabili da un motore ad un'altro, soprattutto
se si utilliza quella gran cosa che sono gli'indici per fare delle seek
 comando che è inesitente in RDO e ADO, e che mi crea spesso e volentieri
dei bei grattacapi il convertire le seek in sql per ADO....) cmq sia per
applicazioni senza troppe pretese è più che sufficente, e se le query non
devono restituire più di 150.000 record circa anche i tempi di attesa sono
acettabili, sopra le cose cominciano a diventare critiche
3- RDO uno sviluppo di DAO, molto più portabile anche se non ne so molto
visto che non ho ancora mai avuto occasione di programmare con questo
motore.
Prima di continuare vorrei specificare un attimo cos'è ODBC...dunque non è
come gli altri sopra descritti e come ADO a cui arrivo dopo, un motore di
database (tanto per intenderci un motore di database è un programma ,
libreria ecc.... che mette a disposione dei comandi per lavorare sui dati,
li organizza e li rende disponibili più o meno efficentemente) ODBC non è un
motore di database ma è se, se mi permettete un altro termine non molto
ortodosso, un "interprete" ossia tramite ODBC tu scegli la fonte dati e lui
fa da interprete tra la fonte (il motore di database) e la tua applicazione.
Se mi sono spiegato decentemente, si può capire che questo crea un passaggio
in più dei dati (a volte necessario, ma cmq un passaggio in più...) per
questo motivo Microsoft un po ambiziosamente, ha dato vita a ADO.
4- ADO, sicuramente all'inizio era pieno di pecche e di bug...ce ne sono
ancora, ma con l'ultima release le cose sembrano migliorate. ADO in pratica
ha un vantaggio su tutti di essere compatibile con qualunque fonti dati (da
mdb, a SQL server , adirittura può recupere dati da un file di testo). Il
suo vantaggio infatti consiste proprio in questo, infatti se voglio fare
un'applicazione file - server userò tutti i comandi di ADO normalmente (sono
un po dissimili da DAO ma con un può di buona volontà.... più che altro è
che vengono aboliti alcuni comanti, propietà che sono state incorporate qua
e là, oppure le opzioni per la connessione sono molto più articolate
rispetto a prima), tornando a prima, il vantaggio consiste nel fatto che se
un giorno voleste passare l'applicazione file - server a client - server
basterà di cambiare la propietà Connection, che se prima era su DAO 3.51 e
JET 4.0 la potrete passare a SQL server , o quanlunque altra fonte, con la
possibilità,anche di collegarsi a provider magari specifici e prodotti da
qualche piccola società.
Spero di essere stato abbastanza chiaro, anche se un po lungo...
By Zolfo


Se guardi su 
www.deja.com
 (e' un archivio/motore di ricerca apposta per i
newsgroups), puoi leggere i vecchi messaggi di questo newsgroup, dove
troverai molte discussioni e informazioni su ADO.
Inoltre pochi giorni fa ho postato un piccolo elenco di sigle con relativa
spiegazione, anche di ADO.
Riassumendo: DAO e ADO sono entrambi librerie di oggetti OLE dedicate
all'accesso ai dati (in pratica semplificano l'uso dei motopri di database:
JET o altri).
DAO e' strettamente legato al JET, che e' il motore di Access.
ADO e' piu' generico e si basa su "OLE-DB providers" che sono una sorta di
drivers specifici per le varie sorgenti dati (lo stesso concetto dei drivers
ODBC).
Nelle intenzioni di Microsoft ADO dovrebbe sostituire RDO (tipo DAO ma per
database remoti), DAO e ODBC...
Se hai VB6 hai anche ADO e la relativa documentazione.
Se hai una versione precedente di VB, puoi scaricare ADO gratuitamente dal
sito Microsoft.
--
Roal Zanazzi
z...@iol.it

Ti chiedo una cosa.
Io utilizzo ADO con un DB Access.
Come devo fare per accedere direttamente al DB tramite OLEDB?
Io fino ad ora ho utilizzato un DSN tramite ODBC per semplicità d'uso, ma
ora
vorrei staccarmi da ODBC.
Grazie.

 wrote in message
7sdv1e$sr$1...@nslave1.tin.it...

dunque dichiara questo in un modulo
Global Cnn As New ADODB.Connection
Global MyRecordset As New ADODB.Recordset
'NomeDb è il nome con percorso del tuo db
Function ApriConnessione(NomeDb As String) As ADODB.Connection
On Error GoTo Errore
Cnn.Provider = "Microsoft.Jet.OLEDB.4.0"   'specificando un altro provider
'con lo stesso codice puoi collegarti per esempio a SQLServer
Cnn.Open NomeDb, admin, ""
Exit Function
Errore:
Msgbox("Impossibile aprire una connessione"
End Function
'questo invece è un piccolo esempio per aprire un record intero
Function ApriRecordsetIntero(NomeRecord As String, CnnAperta As Connection,
Cursore As Variant, Record As ADODB.Recordset)
On Error GoTo Errore
Record.CursorLocation = Cursore
Record.CursorType = adOpenStatic
Record.LockType = adLockOptimistic
Record.Open "Select * from " & NomeRecord & "", CnnAperta
Exit Function
Errore:
Msgbox ("Impossibile aprire record")
End Function
By Zolfo

>'NomeDb è il nome con percorso del tuo db
Si ma cosa succede se il percorso ce l'ho in formato UNC ?
Grazie in anticipo
Vince
vi...@soluzioni-energia.it