Newsgroup: it.comp.appl.access
Titolo: Gestire correttamente l'upd dati senza creare concorrenze (SQLserver)

Sto spippolando con SQLserver 2000
ho fatto degli upsize e semplici trasferimenti di tabelle da ACC-> sql
MA CHE TRAGEDIA GESTIRE I DATI
prime impressioni che mi sono saltate all'occhio
mdb e tab collegate ACC = che Dio la benedica: puoi scrivere un
porcaio di codice e tutto fila "liscio"
mdb e tab tramite ODBC su SQL = parecchie rogne ma ancora gestibili
(forse?....mmmm)
adp = macchesseimatto?
E vabbè che sono bestia io...... ma quanti problemi... non gliene
piace una santa pupazza !!!
che bisogna fare per aggiornare una tabella ?
chiudere le maschere ?
refresh requery recalc come?
con dao con ado o qualcosaltro ?
Cmq il problema è sempre quello "modifica contemporanea record"
Come si deve strutturare il codice del FE quando si passa ad una base
dati come SQLserver ?
Grazie
Alex

 ha scritto nel messaggio
Sto spippolando con SQLserver 2000
ho fatto degli upsize e semplici trasferimenti di tabelle da ACC-> sql
MA CHE TRAGEDIA GESTIRE I DATI
prime impressioni che mi sono saltate all'occhio
mdb e tab collegate ACC = che Dio la benedica: puoi scrivere un
porcaio di codice e tutto fila "liscio"
mdb e tab tramite ODBC su SQL = parecchie rogne ma ancora gestibili
(forse?....mmmm)
adp = macchesseimatto?
---------------
Direi che non concordo.
gestire dati con i file adp è infinitamente più semplice che con un odbc.
Hai perfino pieno accesso a view e sp senza neanche avere un gestore di 
database diverso.
Il tuo problema risiede negli utenti che vanno nel pallone quando access li 
informa che stanno lavorando su un record già modificato da un altro utente.
Non c'è nulla di strano in questo, ragioniamo:
se due utenti aprono la stessa maschera sullo stesso record e uno dei due 
modifica il record, l'altro utente si ritroverà ad avere non il nuovo record 
appena salvato dal primo utente ma il record precedente alla modifica.
L'aggiornamento del recordset non può essere automatico in quanto questo 
genererebbe un enorme e continuo traffico di rete, il cui abbattimento 
invece è proprio il motivo per cui si usano gli adp/SQL Server.
Se a questo punto il secondo utente decide di modificare lo stesso record al 
momento di salvarlo access si accorge che il record originale era stato 
modificato. A questo punto non può essere il programma a stabilire se il 
record da mantenere sia quello già salvato dal primo utente o quello 
modificato dal secondo, per cui lo chiede all'utente cosa bisogna fare.
Questo non è un "problema" del database, un malfunzionamento o chissà cosa, 
è una situazione perfettamente normale, è l'utente che deve sapere cosa 
fare, non access.
Detto questo, per limitare il problema puoi fare in modo tale che, ad es, 
ogni 5 minuti la maschera ricarichi il recordset, in modo tale da mantenere 
aggiornato il più possibile la maschera. Ovviamente al requery deve seguire 
un'istruzione che riporti la maschera sul record che l'utente stava 
visualizzando prima del ricaricamento del recordset. Inoltre è opportuno che 
il codice verifichi se l'utente sia in fase di modifica del record in modo 
da evitare di ricaricare il recordset, con conseguente salvataggio dei dati 
in fase di inserimento.
Saluti
Davide
-- 
http://www.gestionedati.com
"...perchè non esistono saggi per nascita."
(Ptahhotep, 2640 ac) 

Ciao Davide il problema purtroppo non è una multiutenza, il problema è
che sia sul db che sul FE ci sto lavorando solo io....
Ecco perchè credo che il codice sia da rivedere
se aggiorno un campo e poi passo ad un'altro record mi esce il
messaggio
se tento un recalc mi esce il messaggio
idem per un requery
Alex


Fatico a seguirti.
Comunque ti consiglio questa documentazione, relativamente ad ODBC:
http://www.alessandrobaraldi.it/DettaglioFaq.asp?IdFAQ=281
In rapporto agli .ADP è comprensibile che li trovi complicati: richiedono 
l'utilizzo del solo SQL specifico del server.
Se parti da zero ci vuole parecchio tempo per familiarizzare.
Considera comunque che MS non raccomanda l'utilizzo degli ADP a partire 
dalle ver. 2007 di Access, il che potrebbe significare la velata intenzione 
di non supportarli nelle versioni successive.
(considerazioni emerse anche da  
http://blogs.msdn.com/access/
)
Ciao: Oscar

Molte grazie, il file sul server di Alessandro Baraldi è un'ottimo
lavoro e cmq conferma i difficili approci (spero solo) iniziali
passando a questa base dati.
Ineffetti le restrizioni diventano maggiori e il codice in gran parte
andrà rivisto.
Se avrò problemi specifici chiederò al NG un po di supporto
Grazie ancora
Alex

 ha scritto nel messaggio

-------------------------------
Ma tu esegui query di aggiornamento sui record su cui lavori in maschera?
Se è così devi fare un requery ogni volta che aggiorni i record da codice.
Considera questo:
se apri una maschera tu non hai fatto un accesso alla tabella, hai solo 
caricato il recordset (cioè i dati della tabella) in un contenitore 
temporaneo locale cui la tabella accede.
Se esegui una query di aggiornamento, l'operazione viene eseguita sulla 
tabella SQL e non sul recordset della maschera, quindi modifichi il dato di 
origine ma non il dato della maschera, ecco perchè ricevi il messaggio ed 
ecco perchè devi fare un requery della maschera dopo ogni aggiornamento dei 
dati in tabella.
Ciao


Per adesso ho adottato ODBC e sembra rispondere meglio rispetto adp,
le qry vengono effettuate solo nei casi in cui debba aggiornare più
righe, finchè posso vorrei assolutamente evitare il requery e per
adesso sembra funzionare.
Grazie
Alex