Newsgroup: it.comp.appl.access
Titolo: problemi con progetto

Ciao a tutti, ho il seguente problema: ho sempre lavorato con A97 (BE+FE) e
ho deciso di convertire i miei lavori in A2002 (XP) in modalità progetto con
SQL SERVER per renderli più performanti. Una volta terminato il lavoro, le
tabelle (su SQL) le vedo come se fossero locali e non collegate (e fin qui
mi sta bene); il problema è che sono abituato a lavorare con tbl temporanee
sul FE per caricare, ad esempio, i dati del corpo di un ordine prima della
conferma definitiva che aggiorna il db. sSolo che se creo una nuova tabella,
questo me la crea sul SQL e non in locale alla sessione! Come posso fare per
ritornare ad una situazione simile a quella precedente (FE con tbl in locale
e SQL SERVER sul server)? Qualcuno utilizza il mio metodo (tbl locali) per
memorizzare i dati prima dell'aggiornamento o, in alternativa, quale altro
metodo usate?
Grazie a chi mi risponderà!!!
Ciao
Marco

 ha scritto nel messaggio

Personalmente sono contrario all'uso di tabelle temporanee, soprattutto per
quel che riguarda la conferma dati, tanto se poi i dati non vanno bene si
possono cancellare.
Comunque puoi creare delle tabelle permanenti da usare solo per i dati
temporanei, delle tabelle di transito insomma.
Sib

 temporanei, delle tabelle di transito insomma.
Questo č vero se sono in monoutenza ma in multiutenza gestire chi ha
inserito cosa diventa piů complicato (soprattutto perchč la tbl tmp la uso
solo per la parte molti di una relazione, quindi di fatto senza chiave
esterna). L'uso delle tbl temporanee sul FE diverse dal DB "ufficiale" sul
BE agevola molto il lavoro di inserimento e minimizza i locking (che si
riducono solo al momento dell'esecuzione del codice di accodamento).
Altrimenti, un metodo efficiente per gestire inserimenti 1-m quale puň
essere? Strutture in memoria? E come faccio a mostrare a chi sta inserendo
cosa ha inserito fino a quel momento?
Ciao
Marco

 cosa ha inserito fino a quel momento?
Boh, qui non ti seguo...
Ciao: warp

 riducono solo al momento dell'esecuzione del codice di accodamento).
Se conosci ADO, in Access XP puoi creare un recordset locale salvandolo come
file su disco e poi  usarlo per aggiornare una tabella remota.
Il comando e' qualcosa del tipo
rst.save "Nome", adPersistXML
Ma sono certo di stare facendo qualche errore di sintassi.
Sib

 Ma sono certo di stare facendo qualche errore di sintassi.
ti ringrazio, proverň questa soluzione anche se cosě di pelle non mi
entusiasma. Ti chiedo una cosa: quando scrivi una applicazione da usare in
multiutenza, come gestisci gli inserimenti (o le modifiche) in una relazione
1-m? Voglio dire, se io entro in modifica direttamente sulle tabelle
(diciamo attraverso una maschera con sottomaschera) e mentre lavoro vado a
prendere il caffč, in bagno ecc. blocco il lavoro di chiunque altro su quel
record (o sulla pagina). Lo stesso vale, anche se in misura minore, per
quanto riguarda l'inserimento, senza contare tutta una serie di controlli
piů sofisticati che posso fare su caselle "unbound" rispetto a quelli che
posso fare se inserisco direttamente in tbl. Mi piacerebbe capire come
gestite la multiutenza senza tbl tmp senza contemporaneamente  bloccare il
lavoro di tutti gli utenti -1.
Ciao
Marco

 lavoro di tutti gli utenti -1.
In questo hai perfettamente ragione.
Questo problema, tuttavia, puo' essere superato solo sfruttando pesantemente
la programmazione (DAO o ADO che sia, ma soprattutto ADO) in quanto, dato
che lavori direttamente sulla base dati, in qualche modo Access li deve pur
gestire sti dati.
Teniamo presente comunque che questo non e' tanto un problema di Access
quanto della gestione dei database in generale.
Solo con maschere slegate che compiono l'aggiornamento in batch puoi
migliorare la cosa, ma ti faccio notare che comunque non puoi superare il
problema in se. anche se gestisci la cosa cosi' come l'ho descritta, nel
momento in cui un utente va a salvare va a sovrascrivere le eventuali
modifiche di un utente che abbia salvato poco prima. In tal caso c'e' da
chiedersi se non sia il caso di mantenere bloccato il record fino alla fine
delle modifiche addestrando gli utenti a non lasciare in pausa un record
andandosi a prendere un caffe'. Ovviamente a meno che gli utenti non siano
decine e decine.
Sib