Newsgroup: it.comp.lang.visual-basic
Titolo: Leggere un database in rete

Caro NG
ho un programma perfettamente funzionante, il quale fa uso di un databae in
format jet (mdb), utilizzato da molte persone e in molti pienamente
soddisfatti del funzionamento. A questo punto vi chiederete perche di questa
mia.
Ovviamente, come in tutte le cose c'èe sempre quello che rompe le uova nel
paniere ed un giorno mi è stato proposto di mettere i computer in rete. Ahi
Ahi. e qui sono iniziate le note dolenti.
Premetto che non capisco assolutamente nulla di come poter mettere in rete
un database, ho iniziato a leggere qualche cosa su ADO RDO ODBC SQL SERVER e
mi sono venuti i mal di testa.
vEDIAMO DI SPIEGARE UN PO IL MIO PROBLEMA.
Innanzitutto i computer che saranno messi in rete non saranno mai gli
stessi, ovvero il server potra essere oggi il mio computer, domani il
computer di qualche altro e cosi dicasi per i client.
Oggi utilizzo questa connessione per aprire il database sul computer:
Stringa = "Provider=Microsoft.Jet.OLEDB.3.51;Persist Security " _
    & "Info=False;Data Source=" & App.Path & "\Database\" & Nominativo _
    & ".mdb"
come fare per indirizzare l'apertura ad un server??? e se il server cambia
nome cosa succede????
E questi sono tutti i tuoi problemi, vi chiederete???? NOOOO
Al resto vedremo in seguito, quando sarà riuscito a capire come attivare una
connessione ad un database remoto
e verrano fuori a dir poco un'altro milione di problemi.
Grazie a tutti
Enzo

beh, la questione non è tanto complicata, se non per il fatto che non hai un
server database.....
cioè, in realtà ce l'hai, però tutti i giorni cambia, se ho capito bene!!!
in pratica, cmq, devi cambiare la stringa di inizializzazione che hai messo
per aprire il database.....
il file MDB non devi cercarlo nella directory dove hai l'eseguibile, ma in
una posizione condivisa da tutti in rete......usando ad esempio un disco
connesso in rete F:
io di solito metto un file CFG nella dir dell'app, con dentro il
percorso......
good coding!!!
--
Damiani Liborio Igor
idam...@hotmail.com
 - 
igor.d...@light.it
http://www.igordamiani.it
ICQ : 11847262

 wrote:
Ciao, credo che il tuo problemino sia più facile di quanto credi,
hai due possibilità
la prima è quella di fare uno share di una cartella con lo stesso nome
su tutti i pc 
all'inizo dell'applicazione fai un'enum dei pc in rete con le api
necessarie e ti connetti allo share desiderato con un path UNC
\\nome_computer\CartellaCondivisa
oppure setti su ogni pc un origine dati DSN (Pannello
Controllo-->Origini Dati ODBC-->DSN sistema-->ADD-->E scegli ACCESS
come fonte e selezioni il percorso del db
da questo momento per accedere al db potrai usare il nomemacchina ed
il nome del DSN appena settato modificando solo la stringa di
conessione .
ti consiglio di trovare su MSDN:
1) Fonti DATI ODBC 
2) System  DNS
3) Connection String
ciao 
Lorenzo


Assolutamente sconsigliato la connessione da pannello di controllo.
Altrimenti ogni volta tocca riconfigurare tutto.
Saggio invece un file .ini dove metti le informazioni che ti occorrono
per la connessione (path unc da raggiungere, nome del file mdb,
userid e password).
Okkio ovviamente alle prestazioni. Gią di suo access č lento, se poi
lo metti in rete e in connessioni simultanee per operazioni di lettura
e scrittura potresti rischiare il tracollo.
--
Saluti
Andrea MORO
***************************************
Per rispondere togliere ET dal messaggio prima
della chiocciola.

Non sono granchè daccordo nel fatto di non utilizzare Le Fonti ODBC da
pannello di controllo, sono un po più lente ma ci sono sicuramente
meno problemi in termini di codice ed anche meno problemi di accesso
nel caso specifico
E poi perchè dovrebbe riconfigurare tutto? 
mica vero!
le connessioni si settano all'inizio (VIA CODICE ALLO STARTUP DEL
PROGRAMMA) su tutti i pc e si risolve un grande sbattimento e per di
più con lo stesso nome e quindi sa che ogni pc in rete ha un DSN con
quel nome deve fare solo l'enum dei pc presenti in rete in quel
momento
Altrimenti se usa un file ini dovrebbe sempre conoscere il path del DB
ed aggironarlo nel file.
Ad ogni modo per il discorso prestazioni anche io penso che 
devi stare attento..
o meglio il prog funzionerà bene...ma devi sempre considerare che il
codice per un'applicazione che gira in rete deve essere scritto
facendo molta attenzione, Specialmente se il db è Access :))
Ti consiglio di rivedere (giusto un po) le varie query SQL ...evita di
trasferire troppi dati se non sono necessari :
se il db è in rete e tu vuoi il nome dei tuoi fornitori per esempio 
se fai una query del tipo:
SELECT * FROM Fornitori 
ti vengono passati tutti i campi e tutti i record ma a te serviva solo
il nome e quindi potresti riscriverla come
SELECT DISTINCT NomeFornitore FROM Fonitori
Cerca inoltre di trasferire tutte le query che puoi nel DB e lasciare
via codice solo quelle necessarie.
Almeno questo è quello che credo si possa fare..
ho riletto il tuo post
e mi è venuto un dubbio
Potresti essere più chiaro quando dici che non ci sarà un server ?
Di che ti po di applicazione parliamo?
Solo per curiosità
Loenzo

 ha scritto nel messaggio
news:SVf28.16769$tl3.4...@twister2.libero.it...

ciao.
prima di tutto fammi capire una cosa: il committente è un cliente o è la tua
stessa azienda?
considerando che sia il primo caso (fosse il secondo... mah...non ho
parole.. ) ti consiglio di consigliare al cliente un'altra soluzione... se
ogni giorno il "server" (chiamo così il computer  nel quale risiede
fisicamente il file mdb) è diverso... mi spieghi come si fa a mantenere
aggiornati i dati? nel senso: se oggi lavori sul file sul pc1 e domani su
quello sul pc2... quello sul pc2 non conterrà i dati del pc1...
detto questo, considerato che se il cliente ti commissiona una cosa poco
performante o addirittura controproducente è tuo compito, in veste di
persona competente, sconsigliarlo proponendo invece soluzioni più
appropriate, ti suggerisco di rivedere un po' con il cliente la richiesta...
Se il db è stato creato in modo corretto ed il codice idem, potresti pensare
di passare da access a MSDE (praticamente SQL Server) ed avere così un netto
miglioramento per quanto riguarda le prestazioni... nonchè uno strumento
nato primariamente per funzionare in una struttura di rete con accessi
contemporanei..
Pensaci
HTH
--
Stefano Zamboni 
sz...@libero.it
Leggi di Manubay per i programmatori:
1) Se la modifica di un programmatore a un programma esistente funziona,
probabilmente non era quello che voleva il cliente.
2) Il cliente non sa quello che vuole, ma sa quello che non vuole.

Innanzitutto ringrazio tutti per le esaurienti risposte ottenute, ed è mio
dovere precisare alcuni dubbi giustamente espressi nelle risposte. Del tipo
perchè il Server dovrebbe cambiare continuamente e perche i computer in rete
anche.
Il programma in oggetto è un particolare programma ad uso radiantistico,
ovvero è un porgramma per la gestione dei contest (Gare) in campo
radioamatoriale, fa uso di un databse Jet per memorizzare in una tabella
tutti i collegamenti effettuati durante quel particolare contest.
Il fatto che il server potrebbe cambiare continuamente è dato dal fatto che
oggi possono esserci un gruppo di amici che decidono di partecipare a quella
determinata gara in modalità Multioperatore e per tale motivo hanno la
necessita di andare a configurare i computer in rete, utilizzando un'unica
tabella per memorizzare il traffico che andranno a ricevere durante la gara.
Ecco il motivo per cui non e possibile decidere a priori sia il nome del
Server sia i nomi dei vari Cient connessi al server. Di conseguenza capirete
che il Server non è un computer dedicato ma addirittura bene che vada può al
massimo essere un pentium III a 866 Mhz. (vi prego di non ridere). Ho letto
dalle vostre risposte, che mdb potrebbe addirittura serdersi durante le
richieste di aggiornamento e non soddisfare almeno un minimo di requisiti a
giustificare un tale lavoro. Tenete presente che al massimo in una
configurazione completa (ma qui parliamo di stazioni americane e sappiamo
che quelli quando fanno un qualche cosa la fanno con ........) potremmo
avere circa 24 computer collegati in rete di cui 12 sono quelli che
effettivamente fanno richieste al Server o vanno a memorizzare i loro
collegamenti.
Quindi vi chiedo un suggerimento, do per scontato la risposta di evitare con
tali computer di intraprendere un viaggio simile, ma pensate che oggi il
programma che va per la maggiore (americano) per quanto riguarda la
connessione in rete, funziona sotto Dos ed implementa le connessioni con le
porte seriali fino ad un massimo di 15 pc in rete.
Vi passo qualche dato per capire il funzionamento finale:
la tabella potrà al massimo contenere 4000 record con 11 campi per ogni
record ( e siamo su grossi risultati)
Ogni pc puo avere la facolta di visualizzare sul proprio monitor il
contenuto dell'intera tabella, anche se alla fine riceverà solo i
collegamenti da lui effettuati per banda e modo
Da 2 ad un massimo di 4 collegamenti per ogni postazione al minuto da
passare al server (sono solo 4 i campi dati da passare, gli altri vengono
generati in automatico: Del tipo l'ora viene risolta tramite il clock del
sistema etc)
Dopo essere stato, credo un po piu chiaro, su quello che dovrei ottenere, vi
chiedo.
Conviene implementare il tutto con MDB o utilizzare come qualcuno mi ha
suggerito SQL Server (e qui ci sarà tutto da ridere ma non demordo)???
E possibile durante lo startup del programma di un Client o del Server
assegnare un nome al Client (scelto tra una possibile configurazione o
asseganre al server il nome effettivo SERVER o SRV) questo per avere un
percorso univoco nella stringa di inizializzazione per l'apertura del
database.
Che prestazioni si possono ottenere utlizzando schede con HUB da 10 Mbits.
So di averla fatta lunga, ma credo che era necessario spiegare al meglio le
mie necessita per ottenere delle giuste informazioni. Do per scontato, da
come appasiona l'argomento, di ricevere sicuramente delle ottime risposte in
merito, quindi ringrazio tutti anticipatamente ed attendo fiducioso.
Enzo

Il problema di fondo è sempre quanta roba deve transitare per
la rete. Essendo una rete locale, dedicata esclusivamente a quello,
quindi per interderci mentre lavori non ti fai un download di file
da 1GB, la rete e hub da 10 "possono" anche bastarti.
Ma consideranzo che parliamo sempre di access, i problemi
crescono, non tanto per il numero di operazioni, ma per le performance
che ha lo stesso database e per le sue caratteristiche.
Access infatti non è un rdbms, cioè quindi un database dove tu
gli passi una select che tira fuori 10 campi e te ne transitano 10
sulla rete. E' un semplice DB lato client, quindi quando tu fai
una select di 10 campi su una tabella di 4000 record, per la tua
rete transiteranno 4000 record e poi il tuo programma client te
ne farà vedere solo 10.
Questo dovrebbe sufficientemente scoraggiarti.
Se vogliamo andare un pò più a fondo, ti scoraggio ancora su una cosa
del tipo, per il fatto che access è inoltre un db che non ti garantisce
un'integrità dei dati in termini di concorrenzialità.
Infatti tu puoi tranquillamente avere un record che viene aggiornato
da un tizio e immediatamente dopo un secondo tizio aggiorna lo stesso
record, ma l'istante prima il tizio che aveva aggiornato per primo riesce
a fare la select su quel campo per sapere che dato valore ha.
Avrà ovviamente un dato non congruente, perchè non puoi fare il lock
sulla riga o sulla tabella.
Il discorso è ovviabile con dei giochi a livello di codice e di strutture
della tua base dati, ma vale veramente il gioco perdere performance e
riscrivere mezzo codice SQL per non usare da subito un database
che meglio si adatti alle tue esigenze?
Ciao Andrea