Newsgroup: it.comp.appl.access
Titolo: Priorità di accesso dati

Ho già chiesto una cosa simile ma non riesco a trovare la soluzione.
Provo a spiegarmi meglio.
Ho un database strutturato nella seguente maniera:
db_base.mdb (contiene la base dati per tutti gli utenti)
db_utente1.mdb (contiene il collegamento alle tabelle "comuni" di
db_base.mdb, le maschere e i report per l'elaborazione)
db_utente2.mdb (come sopra)
db_utente... .mdb (come sopra)
La tabella DATI contiene una numerazione univoca dei biglietti emessi
determinata da un indice con doppio campo:
NUM_BIGLIETTO (identifica il numero progressivo dei tagliandi)
TIPO_BIGLIETTO (titpologia biglietto).
Per capirci:
1° record
NUM_BIGLIETTO = 1
TIPO_BIGLIETTO = 1
2° record
NUM_BIGLIETTO = 2
TIPO_BIGLIETTO = 1
3° record
NUM_BIGLIETTO = 1
TIPO_BIGLIETTO = 2
e così via.
Quando vado a fare il salvataggio per ogni TIPO_BIGLIETTO cerco il max di
NUM_BIGLIETTO e:
NUM_BIGLIETTO  = NUM_BIGLIETTO + 1
TIPO_BIGLIETTO = TIPO_BIGLIETTO.
Fin qui tutto ok.
Se ho un accesso simultaneo da due PC diversi:
quello che arriva prima salva tutto;
4° record
NUM_BIGLIETTO = 2
TIPO_BIGLIETTO = 2
il secondo mi dice "impossibile salvare il record - chiave duplicata" come
se inserissi;
5° record
NUM_BIGLIETTO = 2
TIPO_BIGLIETTO = 2
anziché
5° record
NUM_BIGLIETTO = 3
TIPO_BIGLIETTO = 2
Ho provato nella seguente maniera:
1) nella routine di salvataggio creo un record in una tabella SALVATAGGIO
munita di contatore;
2) in base al contatore verifico quale PC deve essere il primo a salvare;
3) salvo il tutto dal PC che ha la priorità (come descritto prima nella
tabella DATI) e, dopo aver completato il salvataggio, cancello il record
nella tabella SALVATAGGIO;
4) se nella tabella SALVATAGGIO  ci sono ancora record ritorno al punto 2)
altrimenti esco dalla procedura.
Però questo non funziona ugualmente (probabilmente quando nel PC1 cancello
il record della tabella SALVATAGGIO (punto 3) e dal PC2 (dopo aver
verificato il punto 2) passo al punto 3 la lettura del dell'indice nella
tabella DATI non è ancora aggiornato .).
Sono disperato, riuscite ad aiutarmi?

 Sono disperato, riuscite ad aiutarmi?
Ciao Roberto.
Ci Provo.
2 Possibilità:
Premesso che dmax in presenza di molti record ti costa in termini di
velocità e quindi in tempo di risposta, potresti intercettare l'errore 
(mi semra codice 3022) e rieseguire l'istruzione dmax.
In alternativa creati una tabella "Contatori" (Tipo / Numero Biglietto).
Il primo utente la blocca, legge il numero da assegnare, usa il numero,
lo incrementa di 1, salva e rilascia la tabella.
Il secondo utente aspetta fino a che la tabella "Contatori" si sblocca.
Ciao
MArco 
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

Marco Antonioli ha scritto:

Intanto grazie per la risposta.
In pratica già intercetto l'errore nel senso che "blocco" l'accesso
con la routine che ho fatto.
Non riesco però a lavorare a livello utente.
Ho trovato qualcosa ma in inglese e non riesco a tradurlo bene da
comprendere i particolari.
Sai consigliarmi ulteriormente?

Intanto grazie per la risposta.
Giࠩntercetto l'errore 3022.
Per򠮯n riesco a bloccare la tabella a livello utente.
Ho letto qualcosa ma in inglese: non riesco a tradurla bene.
Riesci a darmi qualche delucidazione in pi񿢾
<input type=hidden name=lang value=

 Sai consigliarmi ulteriormente?
Sono stato via, scusami.
Se hai ancora bisogno replica a questo post.


si sono ancora in alto mare.
riesci ad aiutarmi

 riesci ad aiutarmi
Provo.
Siamo alla prima soluzione.
Ti sei calcolato max di numero biglietto e provi a scrivere.
Se un altro utente ha già utilizzato la stessa chiave ottieni 3022.
Allora ricalcoli max e provi a riscrivere fino a che ci riesci.
Hai provato ?
Che succede ?


Il problema è proprio li: non riesco a gestire l'errore 3022 perchè
non riesco ad intercettarlo (anche facendo il debug passo per passo).
Quando mi arriva la msgbox con l'errore non mi salva il record
(ovviamente) appunto per l'errore 3022 ...
Ho creato un procedura per impedire la duplicazione (e a livello logico
dovrebbe essere giusta) che però non funziona.
Probabilmente c'è un errore ma non riesco a capire dove.
Domani (adesso non l'ho sotto mano) la posto: puoi darci un'occhiata?

Ecco il codice:
Private Sub SALVATUTTO()
On Error GoTo Err_SALVATUTTO
    ERRORESALVATAGGIO = 0
    CONTA_POSTEGGI = 0
    VERIFICA = 0
'*****************************************************************************
' SEGNA IL CODICE DELL'UTENTE PER LA PRIORITA' NELLA NUMERAZIONE DEI
PARCHEGGI
'*****************************************************************************
RIPROVA:
    Dim RS As DAO.Recordset
    Set RS = CurrentDb().OpenRecordset("SALVATAGGIO", dbOpenDynaset)
        RS.AddNew
            RS("TESTO") = "SI"
            RS("IDPC") = ID_PC
            RS("IDPC1") = ID_PC1
        RS.Update
    Set RS = Nothing
'*******************************************************
' VERIFICA LA PRIORITA' PER LA NUMERAZIONE DEI PARCHEGGI
'*******************************************************
RIPROVA1:
    QRY = "SELECT SALVATAGGIO.* FROM SALVATAGGIO ORDER BY
SALVATAGGIO.ID_SALVATAGGIO"
    Set RS = CurrentDb().OpenRecordset(QRY, dbOpenDynaset)
    If RS.RecordCount > 0 And ID_PC / 1 = RS("IDPC") / 1 And ID_PC1 / 1
= RS("IDPC1") Then
        VERIFICA = RS("ID_SALVATAGGIO")
    End If
    Set RS = Nothing
    If VERIFICA = 0 Then GoTo RIPROVA1
'*************
' SALVA I DATI
'*************
    stDocName = "QRY_CITYPARK_AGGIORNA"
    DoCmd.OpenQuery stDocName, acNormal, acEdit
'*********************************************************
' RIPRISTINA LA PRIORITA' PER LA NUMERAZIONE DEI PARCHEGGI
'*********************************************************
RIPROVA2:
    QRY = "SELECT SALVATAGGIO.* FROM SALVATAGGIO WHERE
SALVATAGGIO.ID_SALVATAGGIO=" & VERIFICA
    Set RS = CurrentDb().OpenRecordset(QRY, dbOpenDynaset)
    If RS.RecordCount > 0 Then RS.Delete
    Set RS = Nothing
Exit_SALVATUTTO:
    Exit Sub
Err_SALVATUTTO:
    If ERRORESALVATAGGIO = 1 And Err.Number = 3022 Then
        ID_PC = Now() * Rnd * Rnd: ID_PC1 = Rnd: STATO = 1
        Resume RIPROVA
    End If
    MsgBox Err.Description & " -- " & Err.Number
    Resume RIPROVA2
 
End Sub

 End Sub
Mi sembra che ERRORESALVATAGGIO non assuma mai valore<>0 perciò passa
sempre da Msgbox.
A parte questo nn mi aspettavo un codice così.
Parlavi di dmax ..... 
Pensavo così :
Private sub SALVATUTTO()
 On Error goto Orrori_ST
 apertura RS
 RS.AddNew
 campo1=TipoBiglietto
RIPROVA: 
 campo2=dmax.......
 RS.Update
 Exit sub
Orror_ST:
 if Err = 3022 Then Resume RIPROVA
 msgbox err.description ...
End sub
Forse per aggiornare il recordset devi chiuderlo e riaprirlo in caso di
errore 3022.
Ho semplificato troppo ?


Hai ragione.
Visto così ERRORESALVATAGGIO non diventa mai diverso da 0 (ma in
realtà ho eliminato una parte di codice superfluo è ho lasciato ciò
erroneamente).
dmax viene calcolato dalla query esecutiva "QRY_CITYPARK_AGGIORNA" ...
ma "QRY_CITYPARK_AGGIORNA" viene eseguita una valta passato lo step
"RIPROVA1: " quindi la duplicazione non ci dovrebbe essere ...
Sempre più disperato ...

 wrote in message
news:1122392195.8...@o13g2000cwo.googlegroups.com

Mi risulta difficile capire senza avere visione globale della cosa.
La gestione delle priorità faceva parte dell'idea originale e l'hai
aggiunta per "disperazione" ?
Hai provato a fare come nell'esempio che ti ho proposto?
Pensavo anche che dopo aver calcolato il numero da assegnare (io farei 
N=Dmax("[NomeCampo]" , "NomeTabella" ,  "Condizioni") in caso do errore
3022 potrebbe bastare fare N=N+1 e riprovare a scrivere finchè va bene.
Prova e fammi sapere


Gestione priorità: hai visto giusto, disperazione.
Dai e dai credo di aver capito.
L'errore 3022 non me lo gestisce se utilizzo una query esecutiva già
preordinata.
Adesso provo a fare a mano (con vb) quello che facevo prima con gli
oggetti di access (in pratica quello che mi dici tu) e poi ti faccio
sapere (le prove in rete le faccio lunedì).
Ciao e grazie per la collaborazione

 wrote in message
news:1122463064.8...@o13g2000cwo.googlegroups.com

Buona fortuna


Ho anticipato le prove ed è tutto ok.
La cosa ridicola è che facendo la stessa cosa utilizzando due strade
diverse si ottengono due risultati diversi (nella procedura originale
non ci sono errori concettuali ne di programmazione) e perdi 10 giorni
per trovare una soluzione che non c'è.
In pratica se l'errore 3022 è creato da una query preregistrata nel db
non riesci a gestirlo.
Ciao e ancora grazie