Newsgroup: it.comp.lang.delphi
Titolo: Access Vs Interbase

Ho realizzato un applicativo da utilizzare in rete locate usando BD
interbase, ma, il Boss vuole archivi in access (deve aprirli con un suo
programma, e ,quindi , ho convertito il tutto e pare funzionare bene.
Cosa ne pensate di access in rete locale?
Lo chiedo perchč , quasi quasi, visto che va egregiamente, potri evitarmi
tutti i casini di Interbase ed usare , piů spesso, access.
Qualcuno sa dirmi quali possono essere i problemi con access?
(E' , sempre meglio di Paradox, e questo si vede immediatamente!!!!)
--
Ciao, Ivan
----------------------------

tutti i casini di Interbase ed usare , piů spesso, access.
Concorrency con Access: materia scottante su ICLD!
Cerca su google groups i post di Fabrizio Mancini a riguardo, oppure i miei
sulla concorrenza.
Ti dico innanzitutto che trattandosi di database file server, access da'
diversi problemi di lentezza in multiutenza.
Inoltre il problema dell'accesso concorrenziale puo' essere gestito solo con
il lock pessimistico. Cerca sempre nel ng che ho scritto qualcosa in merito
all'uso di TBetterAdoDataset + access2000.
Inoltre, ricordati che Access fino al 97 lockava a livello di pagina, mentre
solo dal 2000 e' in grado di fare il row locking.
Se hai bisogno ancora chiedi pure. Fondamentalmente il giochetto sta nell'
impostare ltPessimistick al tipo di lock del dataset che utilizzi, sia esso
adodataset, adotable, tbetteradodataset, ecc.
In questo modo otterrai l'impossibilita' di editare un record gia' in edit da
un'altra postazione (anhce se con un piccolo ritardo) se usi access2000, per
le versioni precedenti otterrai il lock a livello di pagina, quindi di piu'
record vicini a quello editato.
Ciao!
-- 
Morde. 
(
mo...@despammed.com
)
M-List di icld: 
http://it.groups.yahoo.com/group/icld/

 tutti i casini di Interbase ed usare , piů spesso, access.
I casini di Interbase ( o meglio Firebird )  ?????? Quali ?
Direi i casini di access in rete (imho)
1) č "pesante" come traffico sulla rete
2) casino a livello di locking
3) spesso si incasina (errori su query ,  chiavi duplicate non esistenti)
senza motivo.
4) crescita "mostruosa" delle dimensioni
Naturalmente i punti 3 e 4 li risolvi con una compattazione periodica. E
naturalmente dipende da quanti client lo utilizzano.
Anche Firebird ha bisogno di un periodico backup/restore , naturalmente ....
ma non ho mai avuto problemi (una volta in caso di black out)
Se vuoi puoi accedere a firebird/interbase via odbc anche con access.
Giulio

senza motivo.
Mi permetto di dissentire su questo specifico punto: io non ho mai avuto
problemi di questo tipo (uso access2000), per quanto riguarda le chiavi
duplicate. 
Invece riguardo le query errate, dipende da come e' strutturata la query e con
cosa l'hai costruita: a volte il generatore stesso di Access non riconosce una
query (molto complessa, con subquery) prodotta da lui medesimo. Ma sono casi
limite. Cmq a me non e' mai capitato che si incasinasse, sara' perche' lo
compatto stesso, boh.
Quanto agli altri punti, sono d'accordo con te.


 compatto stesso, boh.
Access 97 .... :-(    (lo so , lo so ma è una serie di applicazioni
complessissime tutte in acces 97 fatte da un altro e a me la rogna di
mantenerle , con 15 client in rete mista novell/windows ).
Ciao da Giulio