Newsgroup: it.comp.appl.access
Titolo: Strana "fissazione" della maschera con la proprietà bookmark

Come si può immaginare (almeno per chi mi conosce) faccio largo uso del mio 
controllo di ricerca (vedi sitocomune).
Su ADO in un db Access/SQL Server si adatta con poche modifiche.
Tutto funziona in modo regolare finchè, per qualche motivo che mi sfugge, la 
maschera si "fissa" con un record.
Mi spiego, in base al codice (che riporto in calce) alla pressione del tasto 
enter nel controllo di ricerca viene cercata l'occorrenza successiva del 
testo digitato in un determinato campo.
Finchè la maschera è "fresca di apertura" tutto gira bene, se non chè, 
improvvisamente, non appena assegno il bookmark della maschera al recordset 
di ricerca la maschera cambia il record corrente con un altro record che 
resta sempre lo stesso finchè non chiudo e riapro la maschera.
In pratica quando succede questo la ricerca inizia SEMPRE da quel record 
invece che dal record corrente.
Vediamo se posso rendere più chiara la cosa:
questo è un insieme di debug print che eseguo durante il codice:
---108---
Prima:         41            1             108
Dopo:          41            41            108
Intermedio:    41            299           108
Finale:        105           299           9090
Il primo numero è l'IDCliente del record corrente, la struttura dei numeri 
che seguono è composta da bookmark della mascera, bookmark del recordset, 
IDCliente.
Prima è la situazione iniziale
Dopo è la situazione dopo l'assegnazione rs.bookmark=me.bookmark
Intermedio è la situazione dopo la ricerca in rs (infatti rs.bookmark cambia 
mentre me.bookmark no, è giusto)
Finale è la situazione dopo l'assegnazione me.bookmark=rs.bookmark (i valori 
sono diversi ma è corretto così, si osservi che IDCliente finalmente è 
cambiato e corrisponde al record che si stava cercando.
Quando il codice non funziona si ottiene questo output:
---108---
Prima:         41            1             105773
Dopo:          73            300           105773
Intermedio:    73            41            105773
Finale:        41            41            108
Si osservi che la ricerca inizia sempre dal cliente con IDCliente=108, ma 
già un attimo prima dell'assegnazione rs.bookmark=me.bookmark la maschera 
sta cambiano il record corrente infatti l'IDCliente stampato alla voce Prima 
è diverso da quello iniziale, alla voce Dopo si osserv a che anche 
Me.bookmark è cambiato come anche rs.bookmark è diverso da prima, la ricerca 
in sostanza inizia da un record diverso dal 41, infatti alla fine il record 
trovato è proprio il 108 (quello da cui si era partiti)
Il codice segue:
Private Sub Ricerca_KeyPress(KeyAscii As Integer)
On Error GoTo Riprova
Dim str As String, rs As ADODB.Recordset
    If KeyAscii = 13 Then
        Set rs = Me.RecordsetClone
        If Nz(Me!Ricerca.Text, "") <> "" Then
            With rs
                Debug.Print "---" & Me.IDCliente & "---"
                Debug.Print "Prima:", Asc(Me.Bookmark), .Bookmark, 
Me.IDCliente
                .Bookmark = Me.Bookmark 'Predispone il recordset sul record 
corrente della maschera
                Debug.Print "Dopo:", Asc(Me.Bookmark), .Bookmark, 
Me.IDCliente
                .MoveNext 'Si sposta avanti di un posto per cercare tra i 
record successivi a quello corrente
                .Find Me.RicercaIn & " like '" & ChiaveRicerca & 
Apici(Me!Ricerca.Text) & "%'"
                If .EOF Then 'Se non trova il record
                    PlaySound SuonoPredefinito, 1 
'"c:\windows\media\chord.wav", 1
                    .MoveFirst 'Ricomincia la ricerca dal primo record
                    .Find Me.RicercaIn & " like '" & ChiaveRicerca & 
Apici(Me!Ricerca.Text) & "*'"
                End If
                Debug.Print "Intermedio:", Asc(Me.Bookmark), .Bookmark, 
Me.IDCliente
                If Not .EOF Then 'Se il record è stato trovato predispone la 
maschera sul record trovato
                    Me.Bookmark = .Bookmark
                End If
                Debug.Print "Finale:", Asc(Me.Bookmark), .Bookmark, 
Me.IDCliente
            End With
            Set rs = Nothing
        End If
        Me!Ricerca.SetFocus
        Me!Ricerca.SelStart = 255
        KeyAscii = 0
    End If
Esci:
    Exit Sub
Riprova:
    If Err.Number = -
2147217881
 Then Resume Esci
    If MsgBox(Err.Number & " - " & Err.Description & vbCrLf & "Riprovare?", 
vbExclamation + vbYesNo, "Errore di ricerca") = vbYes Then
        Resume
    Else
        Resume Esci
    End If
End Sub
Grazie a chi sia arrivato a leggere fin qui.
Davide (Sib)
-- 
www.gestionedati,com

Ciao Davide.
Il Post è un pò complesso anche da capire, almeno per me, e la cosa
migliore
sarebbe stata simularlo realmente con un Demo, ma non essendo
Access...!
Non mi è chiaro se stai usando un ADP oppure un MDB+ADO(ma immagino
sia
il 1° caso).
Se fosse il 2° caso, hai provato invece di usare ADO ad usare DAO...?
Solo per discriminare se può derivare da un baco nella gestione dei
Dataset
di differente estrazione, cosa non nuova...!
Se è il 1° non dico nulla in quanto non sono esperto di ADP.
@Alex

 ha scritto nel messaggio
Il Post è un pò complesso anche da capire, almeno per me, e la cosa
migliore
sarebbe stata simularlo realmente con un Demo, ma non essendo
Access...!
---
hai ragione, comunque in breve durante il malfunzionamento invece di 
spostarsi dal record corrente al record successivo, fa prima un salto a un 
record arbitrario (sempre lo stesso finchè non si chiude e si riapre la 
maschera) e poi si sposta sul record successivo e questo salto anomalo 
avviene esattamente un istante prima dell'assegnazione 
rs.bookmark=me.bookmark (come si evince dall'output Prima:)
---
Non mi è chiaro se stai usando un ADP oppure un MDB+ADO(ma immagino
sia
il 1° caso).
cut
---
Primo caso, come dicevo uso SQL Server.
---
Se è il 1° non dico nulla in quanto non sono esperto di ADP.
---
MALE!
Dimmi qualcosa lo stesso altrimenti chiamo uno psicoanalista.
Ciao
Davide
-- 
www.gestionedati,com 

MALE!
Dimmi qualcosa lo stesso altrimenti chiamo uno psicoanalista.
;-)
Hai provato a passare il parametro di direzione della
ricerca(adSearchForward), giusto per evitare
anomali malintesi con ADO, anche se come dici vai solo avanti e
dovrebbe essere di Default.
Altra prova è di sostituire
Set rs = Me.RecordsetClone
con
Set rs = Me.Recordset
Per ora non ho altre risorse, ma ho il nome di un buon
Psicanalista...!!
;-)
@Alex

 Set rs = Me.Recordset
in questo caso non dovrebbe neanche avere bisogno del bookmark
--
ac

Si non nella prima fase, ma solo nel riaggiornamento della
Form...!
Speriamo.
@Alex

 ha scritto nel messaggio
MALE!
Dimmi qualcosa lo stesso altrimenti chiamo uno psicoanalista.
;-)
Hai provato a passare il parametro di direzione della
ricerca(adSearchForward), giusto per evitare
anomali malintesi con ADO, anche se come dici vai solo avanti e
dovrebbe essere di Default.
-No, non ho provato ma ti farò sapere
Altra prova è di sostituire
Set rs = Me.RecordsetClone
con
Set rs = Me.Recordset
-Guarda che qui forse hai avuto un'illuminazione, come dice anche Alessandro 
C. (mi pare il caso qui di specificare) in questo modo la maschera si sposta 
da se senza l'uso di bookmark. L'avevo usato tempo fa ma chissà perchè avevo 
ripreso a usare il ...clone.
-Provo e ti faccio sapere.
Per ora non ho altre risorse, ma ho il nome di un buon
Psicanalista...!!
;-)
-Anche tu ne conosci uno?!
-Tieni da parte il nome che potrebbe anche servirmi.
@Alex
Ciao
Davide
-- 
www.gestionedati,com 

;-)
-Anche tu ne conosci uno?!
Si certo è un caro amico....!
E trovargli clienti è un piacere.
(Dicono tutti che è l'amico ad avere bisogno......)
-Tieni da parte il nome che potrebbe anche servirmi.
Certamente.
@Alex

 -Provo e ti faccio sapere.
CUT
Questo sembra aver funzionato in quanto l'assegnazione del recordset diretto
consente praticamente di manipolare direttamente l'effettivo recordset della
maschera.
Questo è un grande vantaggio poichè anche semplicemente dando un rs.movenext
il record corrente della maschera si sposta, ma è anche uno svantaggio
infatti, siccome l'istruzione find inizia la ricerca dal record corrente,
per trovare il successivo devo dare proprio un rs.movenext il quale produce
la visualizzazione del record successivo prima di saltare al record trovato.
Funzionalmente non è un problema, ma esteticamente non è il massimo e,
soprattutto, provoca l'evento su corrente che viene eseguito inutilmente una
volta in più.
Boh, per ora così, poi vediamo se riesco a capire perchè col recordsetclone
dà quel problema.
Ciao
Davide
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/