Newsgroup: it.comp.lang.visual-basic
Titolo: Database Access su CD

Ciao a tutti!
Sto scrivendo una applicazione VB che accede ad un database access 2000 via
ado e dao.
Se tengo il file MDB del database su disco fisso non ho nessun problema,
mentre non riesco ad usarlo se sposto il database su cd-rom.
Questo problema è dovuto al fatto che quando si usa un db access (anche solo
aprendolo con Access) viene creato un file temporaneo con estensione .ldb
(nomedatabase.ldb), che viene cancellato una volta chiuso il database.
Quindi mentre su disco fisso la creazione/eliminazione del file ldb non da
problemi, si hanno problemi volendo mettere il db su cd (il cd essendo
read-only non permette la creazione di questo file .ldb).
Come faccio ad utilizzare il database access da cd allora, senza spostarlo
su disco fisso?
Vorrei avere una unica applicazione che legge basi di dati diverse
semplicemente cambiando il cd nel lettore.
Forse c'è qualche parametro da passare via codice? se si riuscite a darmi
per favore la linea di codice?
Grazie mille anticipatamente per tutto il supporto!
A presto.
Luca

semplicemente cambiando il cd nel lettore.
E perche' non cambiando la stringa di connessione ?
ciao, hal

 venga creato il file .LDB.
Vuol dire allora che il file LDB viene creato per la gestione delle
transazioni in un ambiente dove piu' persone concorrono all'utilizzo della
stessa base di dati?
Come si fa ad aprire il db in modalità esclusiva?
Immagino via codice ci sia un paramtero da passare.....
Mi sai dire qcosa di +?
Grazie mille per il suggerimento!
Luca

Specifica se in DAO o ADO
Ciao,
Timothy
--
Timothy Redaelli
timothy....@email.it

 ha scritto

aprendo l'ldb con blocco note, fra le varie schifezze si vedono i nomi delle
macchine connesse. ne avevo dedotto stesse per login data base. qualcuno,
_forse_ zeross o hpl, parlava piu' diffusamente dell'ldb nei giorni scorsi
sul ng.


E' un post di Alfonso Moscato della settimana scorsa.
Ricopio qui un estratto del suo messaggio, poiche' il resto riguarda altri argomenti.
ciao, hal
-------- da Alfonso Moscato:
Access non è client
server, il motore di database gira localmente. La condivisione sfrutta il
sistema operativo. I lock vengono gestiti attraverso il file ldb. I limiti
del file ldb impongono il limite di 255 utenti (sebbene nella pratica sia
ampiamente irraggiungibile; così Roal non ride). Quello che segue è un
estratto della White paper di Microsoft, scritta da  Kevin Collins, del
Microsoft Jet Program Management, dal titolo "Understanding Microsoft Jet
Locking". Tale white paper fa parte delle Jetutils, scaricabili dal sito
Microsoft. Non l'ho allegata perchè è più di 1 mega, ma posso fornirla a
chiunque la voglia.
"One .ldb file is always created for every Microsoft Jet database file that
is connected in a shared mode. The .ldb file always retains the same name as
the database that was opened (for example, Nwind.mdb always has a Nwind.ldb
file), and the .ldb file will always be in the same directory as the
database. If an .ldb file does not exist and the database is connected in a
shared mode, an .ldb file is created. The physical structure of the .ldb
file is best thought of as a one-dimensional array. Each element in the
array, up to 255, consists of 64 bytes. The first 32 bytes contain the
computer name (such as Machine1), and the second 32 bytes contain the
security name (such as Admin). This data is then used to provide information
regarding which other users are holding locks. You can view this information
by simply looking at the contents of the .ldb file.
 The physical size of the .ldb file never exceeds 16,320 bytes, because the
maximum number of concurrent users in a Microsoft Jet database is 255 (255 *
64 = 16320)."
L'ultima frase dimostra che il numero massimo di utenti di Access è 255.
Peraltro è sufficiente andare sull'help, "Impostazione e personalizzazione
di Microsoft Access->Specifiche di Microsoft Access" per leggere la stessa
cosa.

Parte in ado e parte in dao,
per via della necessitą di riutilizzo di vecchio codice, che verrą migrato
ad ado solo in un secondo tempo.
Ciao
Luca

 ha scritto
luca f.

il punto e': il db deve essere anche modificato o solo letto ?
nel primo caso, _deve_ essere copiato su disco fisso.
nel secondo, sono piu' che sicuro di avere gia' trovato alcuni mdb su cd, e
i programmi andavano. direi -- dico direi -- che si debba masterizzare anche
un ldb sul cd. quindi: aprire il db su hd, copiare _quando e' aperto_ mdb e
ldb su cd. aggiungere ghiaccio e pregare q.b. -- al massimo si butta via un
cdr :))
in bocca a nero,
a.

 un ldb sul cd.
Se anche metti l'ldb su CD non ci puoi scrivere quindi č inutile. Se trovi
dei CD che contengono degli ldb, č molto probabile che ci siano finiti sopra
per errore (ehm...)
Personalmente uso la seguente funzione per aprire gli MDB, che funziona
indifferentemente su CD o su HD. In questo modo non mi preoccupo di lavorare
diversamente quando non ho ancora generato il CD, e posso utilizzare il
database in modo condiviso mentre sviluppo con i DB ancora su HD.
Public Function RitornaDatabaseDaFile(ByVal sPathFileCompleto As String,
Optional bReadOnly As Boolean = True) As Database
   Dim sPathFileCompleto As String
   If IsFile(sPathFileCompleto) Then
      On Error Resume Next
      ' Prima prova ad aprirlo in modo condiviso
      Set RitornaDatabaseDaFile = OpenDatabase(sPathFileCompleto, False,
bReadOnly)
      If Err > 0 Then
         On Error GoTo 0
         ' se non č riuscito ad aprirlo in modo condiviso, lo apre in modo
esclusivo
         On Error Resume Next
         Set RitornaDatabaseDaFile = OpenDatabase(sPathFileCompleto, True,
bReadOnly)
         If Err > 0 Then
            On Error GoTo 0
            ' se non č riuscito ad aprirlo in lettura/scrittura, lo apre in
sola lettura
            Set RitornaDatabaseDaFile = OpenDatabase(sPathFileCompleto,
True, True)
         End If
      End If
      On Error GoTo 0
   Else
      MsgBox "Non trovato file <" & sPathFileCompleto & ">"
      Set RitornaDatabaseDaFile = Nothing
   End If
End Function
Ciao
*Roby*