Newsgroup: it.comp.lang.visual-basic
Titolo: utilizzo di files mdb

Abbiamo realizzato un programma gestionale che si basa su un archivio fatto
di file ACCESS.
La differenza rispetto ai classici database ACCESS è che l'archivio non è
costituito da un solo file .mdb che contiene molte tabelle, ma da tanti
files che contengono poche tabelle. (Es. magazzino.mdb, clienti.mdb,
fornitori.mdb, daticontabili.mdb, ecc.).
il problema è questo: qualcuno sa se questa frammentazione di .mdb può
causare danneggiamenti di dati specie se l'utilizzo di questa struttura di
dati viene usata in multiutenza. A noi è successo spesso di ritrovarci con
messaggi del tipo "database non riconosciuto",  "impossibile aprire
database", ecc.
Grazie a chi potrà darmi utili consigli in merito.
Walter

 dati viene usata in multiutenza. A noi è successo spesso di ritrovarci con
Ma... l'integrità referenziale? O (possibile?) avete evitato relazioni
fra file diversi?
Flavio Ronco
-- 
f.ronco@*NonMiServeNiente*
flashnet.it
http://www.metabrains.com
  [Under Construction]
-------------------------------------------------------------
"Che pubblico in gamba! Se ci dite dove lavorate,
domani mattina se abbiamo tempo vi veniamo a vedere"
[Paolo Rossi]

 fra file diversi?
flavio, non svenirmi p.f. :
dai tempi giovanili di dbase/clipper, l'integrita' referenziale preferisco
gestirmela io. risultato: ho conosciuto decine di persone cui si
corrompevano se andava bene gli indici, se male le tabelle... io ho un db
con una decina di tabelle, gestito da inesperti, che va avanti dal 91 senza
perdere un colpo...
in tre anni di access non ho mai stabilito una connessione fra tabelle se
non via codice. preferisco prevedere e gestirmi gli errori se sono stati
fatti dei casini.
e' una rotta mica piccola, ma almeno sai che se cambia il db (cosa non
infrequente con access) il tuo codice te lo puoi continuare a gestire tu...
sai, conoscendo gli informatici, li temo almeno come i greci che portano
doni :)
IO AMO LE NUDE TABELLE !!
l'ho detto ! dopo 15 anni di silenzio, ci voleva.
tornando al punto, anch'io sono stato attirato dalla soluzione dei molti mdb
con poche tabelle. prob molti di quelli che arrivano da dbase e vedono che
access considera "database" una directory -- dopo l'iniziale incredulita' --
e ragionandoci un po' -- si adeguano ma mantengono l'ideuzza di fondo. per
un vero dbf'ista database e' la tabella. l'insieme di tabelle e' un'altra
cosa, indefinita :):)
non l'ho fatto soprattutto perche' in vb4/32 avevo letto per dbengine e
famiglia qc tipo: max 10 sessioni. il che -- se era / e' vero -- ti spinge a
mettere piu' tabelle che puoi dentro un solo mdb...
in questo momento ne ho aperti un paio. non so se il limite vale -- se vale
ancora -- in assoluto, solo per 9x, nt o altro.
se qualcuno ha altre info, benvenuto.
tia, pal

 fatti dei casini.
Presto, i sali! :-)
MMMh... se scrivi tutto il front-end in VB o altro linguaggio ci credo.
Ma secondo me, se ti chiudi in Access e (soprattutto) se l'utente
pretende di usare il database senza sicurezza a livello utente, credo
che la via migliore sia sempre impostare l'IR da Access. Lo dico
pensando a cosa succede se qualcuno, di fronte a un errore di Access
Basic, pigia "Debug" e pasticcia nel codice. Purtroppo l'impossibilità
di compilare il codice (l'MDE è troppo limitativo) rende poco sicuro,
nel complesso, qualsiasi mdb gestito da un front-end Access. E se si
aggiunge sicurezza si scade inesorabilmente in flessibilità.
Da VB le cose sono diverse, e la necessità di programmare praticamente
tutto via codice rende anche conveniente gestirsi il meccanismo di IR.
In pratica: se c'è qualcosa che viene eseguito senza scrivere codice
visibile ben venga: un rischio in meno fra i tanti. Se poi ho tutto il
tempo e il budget per costruire del codice solido come una roccia il
discorso cambia.
Boh, è più di un anno che non frequento l'ambiente, può darsi che
vaneggi. Il fatto è che mi dovrò riprendere in fretta...
ciao


 che la via migliore sia sempre impostare l'IR da Access.
svenimento II in arrivo...
non ho _mai_ imparato a usare bene dbase, e _non_ so usare bene access. in
tutti e due uso il browse. in access provo qualche qry, ma rigorosamente in
sql. l'interfaccia grafica non mi piaceva quando mi hanno fatto vedere
fourth dimension nel 90-91, e continua a non piacermi ora.
i dbms li uso per creare e modif velocemente la struttura del db
poi come usavo clipper uso vb.
ne' peraltro amavo i prg dbase o amo i prg access. anzi, mi innervosiscono
molto. un sacco di smacchinamento per poi doversi comprare il runtime e
avere un prg inchiodato sempre.
fra access e vb il salto di velocita' non e' spettacolare (anzi, qno dice
piu' veloce access), ma fra dbase e clipper era una vera pacchia :)
in clipper creare una tabella era abbastanza immediato, 10 righe o giu' di
li', in vb piu' rognoso, ma se dovessi fare qualcosa di serio lo userei lo
stesso.
meno dbms ho fra i piedi, meglio sto. per il resto concordo su tutto.
ciao, a.

 meno dbms ho fra i piedi, meglio sto. per il resto concordo su tutto.
Temo che dovremo aggiornarci anche noi. ADO č destinato a soppiantare gli
standard precedenti, e lě le seek non si possono piů fare. Presto mi aspetto
di vedere tra il motore database e i file tanti di quei layer da  non sapere
piů neppure se stai lavorando su un database Oracle o su un documento
Word...
Ciao
*Roby*