Newsgroup: it.comp.appl.access
Titolo: Front end utilizzato da più utenti

Ho creato un DB utilizzato con struttura front-end/back-end... e infatti 
così è utilizzabile da più utenti contemporaneamente. Il DB è un 
database per il protocollo corrispondenza, e grazie ai preziosissimi 
consigli dei frequentatori di questo NG ho creato in ogni tipologia di 
protocollo un campo che genera, come valore predefinito, il famoso 
"numero precedente + 1". Se si connette uno solo, tutto benissimo. Se si 
connettono più di uno, però, assegna gli stessi numeri! Cosa ho 
sbagliato? Nel front-end sono presenti solo le maschere, le tabelle sono 
solo collegamenti ad altre tabelle che risiedono nel front-end.. non è 
così che si dovrebbe fare?
Fabrizio

 Fabrizio
Penso che non si possa evitare. 
Fino a quando non salvi il record da qualunque postazione avrai come
valore predefinito lo stesso protocollo.
Pertanto all'inserimento, il nuovo record deve essere subito salvato.
Oppure devi utilizzare tecniche diverse, leggere da una tabella che
mantenga l'ultimo numero di protocollo, da aggiornarsi all'inserimento di
un nuovo record.
Oppure bloccare i record.
--
rgrds
SC
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 SC
Grazie comunque per la tua risposta..
E Bloccare i record cosa potrebbe provocare?
Fabrizio

 Fabrizio
Cerca nell'Help "Proprietà RecordLocks".
Altro trovi pure su:
http://www.accessgroup.it/Bld_HTML/Home.htm
Cap6°:Usare Oggetti Recordset


 ha scritto nel messaggio
news:do5vvm$c6c$1...@news.newsland.it...

Scusa sv, ma non è più corretto distrubuire piu' FE che puntano allo stesso
BE?
Questa dovrebbe essere la regola...
Ciao e auguri di Buon Natale.

 Ciao e auguri di Buon Natale.
Altrettanto a te e famiglia.


 ha scritto nel messaggio 
news:43a67a99$0$327$5fc...@news.tiscali.it...

ciao,
una soluzione (che io ho adottato) potrebbe essere quella di assegnare il 
numero appena prima di salvare il  record (a meno chè non sia necessario che 
l'operatore debba conoscere immediatamente il numero assegnato).
Così facendo riduci al minimo la possibilità che vengano attribuiti numeri 
uguali a record diversi.
Ciao,
Mat. 

 Mat.
Sto riflettendo a lungo sulla creazione di un ID progressivo, in una tabella 
condivisa da più utenti e mi parso di arrivare ad una conclusione che, è 
difficile quale sia la strada giusta:
Come dice Mat è OK, però se vado al salvataggio del record e lo stesso 
record era già stato inserito, che faccio? Annullo? quindi si avrà un buco 
nella progressione dei numeri!
Ciao
Napoleone 

 Fabrizio
Salva il record appena entri (attribuendo cosě l'ID immediatamente), e poi 
continui l'inserimento dei dati con un azione di "update" invece che di 
"insert". ;-)
-- 
Ciao
Pablitomf (Maurizio Facciuti)
-----------------------------------------------------------------
Access 97 -  2000
ASP
-----------------------------------------------------------------
http://www.accessgroup.it/
http://www.sitocomune.com/
Quotare :
http://wiki.news.nic.it/QuotarBene
http://www.krisopea.it/mvp/Quoting.htm
-----------------------------------------------------------------
Il mio motto :
""Non mi fido molto delle statistiche, perchč un uomo con la testa nel forno
acceso e i piedi nel congelatore statisticamente ha una temperatura media." 

 Pablitomf (Maurizio Facciuti)
Ciao Maurizio,
Perfetto quanto dici per quanto riguarda la generazione dell'ID, però alla 
fine quando vado a salvare il record, supponiamo l'anagrafica di un cliente, 
e lo stesso cliente è già presente in archivio, debbo necessariamente 
annullare l'inserimento, per cui intanto la progressione è stata portata 
avanti da altri utenti ed io non posso fare altro che (annullando 
l'inserimento del nuovo record) creare un buco nella progressione della 
numerazione.
Napoleone 

 ha scritto nel messaggio 
news:i_Opf.9831$eD5.1...@twister2.libero.it...

cosa intendi con "lo stesso record era già stato inserito"?
La questione dei buchi nella numerazione è comunque da considerare se c'è 
l'eventualità che un record (comunque sia stato numerato) venga eliminato.
Dipende se è strettamente necessario che non vi siano discontinuità nella 
numerazione oppure se è trascurabile.
Personalmente per reperire i numeri da assegnare utilizzo una funzione che, 
quando necessario, controlla anche se ci sono buchi e avverte l'operatore o 
chiede se riutilizzare il numero "perso".
Ciao,
Mat. 


ciao Napoleone, hai ragione, stesso discorso se cancelli il record.
Ti conviene crearti un contatore temporaneo e poi salvare con il definitivo
solo dopo la conferma
-- 
_ _
Ciao
MAssimiliano Amendola            
www.accessgroup.it
Cisa - Conferenza Italiana per Sviluppatori Access
Info:  
www.donkarl.com/it

 Mat.
Questa è veramente una bella cosa, ce ne puoi mettere a conoscenza?
Ciao
Napoleone 


C'è la routine sul SC


 MAssimiliano Amendola
Ciao Mio carissimo,
come sarebbe?
Napoleone 

 C'è la routine sul SC
ottimo, vedi sul sc.
Mat.



Ciao,
Allora tu hai un campo che ti serve da contatore.
Se definitivo tu hai questa imput N05-0001, per esempio: quindi N05 ti dice
che è definitivo
Bene usa un diverso contatore temporaneo formato solo con T e il dmax dei
temporanei.
a quel punto quando confermerai l'inserimento lui attribuisce il valore
definitivo secondo l'ordine del contatore temporaneo.
Ora ovviamente se c'è un buco nel temporaneo a te non interessa
-- 
_ _
Ciao


 Napoleone