Newsgroup: it.comp.appl.access
Titolo: Evento indesiderato in ADP A2000 su MSDE2000

Ciao a tutti,
non riesco proprio a capire perche' succeda questo.
in pratica ho una maschera con interruttori e tutto funziona, se non che' se
sfrutto la proprieta' me.bookmark per individuare un record e poi cerco di
modificare l'interruttore si verifica l'evento afterupdate.
da precisare che in questo evento ho messo una msgbox di conferma con i
pulsanti Si', No e Annulla.
se premo annulla si verifica una seconda volta l'evento e ricompare la
richiesta di conferma
se premo nuoamente annulla tutto torna normale e posso completare tutte le
operazioni.
se per sbaglio in uno dei due casi premo si' o no access da un errore e si
chiude.
se prima di modificare l'interruttore modifico ad es un controllo e mando il
record in fase di modifica non si presenta nessun problema.
la cosa non dipende da un interruttore in particolare, ma da un qualsiaasi
interruttore
NB ovviamente gli interruttori sono legati a campi bit della tabella
sottostante.
Ho installato fino alla sp3 senza successo, non so piu' cosa modificare.
accetto qualsiasi suggerimento
Sib

"Sib" <si...@SPAMiol.it> ha scritto nel messaggio
cut
per chi vuole riprodurre l'errore la cosa e' semplicissima:
create un adp e collegatelo a un db msde (o createne uno di prova)
create una maschera da una tabella che contenga campi bit
(l'autocomposizione va bene)
se usate l'autocomposizione evdrete che i campi bit vengono tradotti come
caselle di controllo
provate a inserire e modificare record a partire dalla casella di controllo,
tutto andra' bene.
con l'autocomposizione create una combo di ricerca
salvate la maschera (perche' ora vi faccio andare in crash access)
trovate un record col nuovo controllo di ricerca che avete creato
senza fare altre operazioni fate click sulla casella di controllo e...
...buon divertimento!!
Sib

"Sib" <

Ho provato senza incontrare problemi con la seguente configuraz. (il formato
del file è sempre il 2000)
Access 2000 SP-1
Access XP SP-2
Sql Server Dev Edition 7.0
Maschera con cambi "Bit" (check box associate), cerco un record, quindi
modifico il campo Bit su quel record o su altri record.
Non va in crash.
Sarà solo con Sql Server 2000?
Saluti.

 ha scritto nel messaggio

molto interessante.
ho verificato su diversi pc e su diversi database, sempre con file adp di
A2000 aperto con AXP cone MSDE 2000, va sempre in errore.
hai usato l'autocomposizione per la casella di ricerca (quella che usa la
proprieta' bookmark)?
hai premuto subito la casella di controllo dopo la ricerca? non e' che hai
iniziato a modificare prima altri controlli?
Sib

"Sib" <si...@SPAMiol.it> ha scritto nel messaggio
news:zMefb.160439$hE5.5...@news1.tin.it...

Ciao Sib
In passato ho avuto un problema analogo che si presentava eseguendo lo
spostamento tra i record tramite l'oggetto recordset del Form, infatti se
dalla finestra di debug esegui il comando Forms!TuoFrm.Recordset.movefirst e
fai click sul CheckBox otterrai lo stesso errore. Nel mio caso ho risolto
(in un primo momento) utilizzando il metodo docmd.RunCommand
acCmdRecordsGoToLast, poi ho deciso di abbandonare queste  tecniche di
Access che sono valide per piccoli MDB ma che ( a mio parere ) non hanno
senso in un sistema Client/server o con tabelle di grosse dimensioni.
(Le reti geografiche sono il futuro e sqlserver è lo strumento adatto)
Comunque come suggerimento potresti utilizzare il metodo FindRecord
dell'oggetto DoCmd.
Es..
-------------------------------------------
Private Sub CasellaCombinata_AfterUpdate()
    Me.CTR.Setfocus
    DoCmd.FindRecord Str(Nz(Me![CasellaCombinata], 0)), , False, , False
End Sub
------------------------------------------
( CTR ha come origine controllo il campo da ricercare)
A quanto pare non si può toccare il Recordset del Form.
Ciao Giorgio.

 Access che sono valide per piccoli MDB ma che ( a mio parere )
Beh, Giorgio: senza dubbio a tuo parere.
A parere di altri la soluzione più razionale per gestire la concorrenza su
reti geografiche (senza esser costretti a creare interfacce simili ai
software di 25 anni fa) è ricorrere a servizi Terminal, Cytrix e affini.


 iniziato a modificare prima altri controlli?
Effettivamente ho fatto tutto come da tuo post precedente.
Vuoi darmi altre indicazioni?
Mi piacerebbe capire bene come si verifichi l'errore che descrivi.
Saluti.

 Beh, Giorgio: senza dubbio a tuo parere.
Certamente, non volevo dare consigli ma solo una testimonianza :)))
Ciao Giorgio

 ha scritto nel messaggio
news:blm571$4ht$1...@lacerta.tiscalinet.it...

Dimenticavo..
(senza esser costretti a creare interfacce simili aisoftware di 25 anni fa)
Le tecniche e le comodità di di Access sono riproducibili con stored
procedure scritte il linquaggio TSql su SqlServer, ovviamente bisogna
cambiare tutta la logica.
Ciao.

 cambiare tutta la logica.
Il discorso si complica...
E' vero che usando il TSQL puoi delegare molto al Server e restituire poco
(ma dipende dalle richieste dell'utente) al Client.
Tuttavia tante classiche comode _e assai gradite_ features che offre Access,
sono intrinsecamente pesanti e fondamentalmente incompatibili con qualunque
applicazione che lavori in remoto su linee ordinarie.
Parliamo di Combo a espansione, strutture Master/Detail, SubForms etc.
A questo punto, a meno che non si lavori per le assicurazione Generali o la
Fiat, tanto vale sfruttare i servizi Terminal senza rinunciare alle comodità
di cui sopra.
Sono opinioni per carità, però noto che molti noti produttori di gestionali,
imbrattano brochures e siti di tirate su "applicazioni web", "web services",
operatività Client-Server attraverso linee ADSL, etc.  ... però poi all'atto
pratico preferiscono sfruttare servizi Terminal.
E la cosa non mi stupisce considerando che la maggior parte dei software che
girano s'interfacciano ai Server di database con pure connessioni ODBC.
Saluti: Simone

 ha scritto nel messaggio

si verifica esattamente come descrivo.
se si usa la proprieta' bookmark per ritrovare un record, allora non si puo'
iniziare a modificare i dati della maschera a partire da un controllo
collegato a un campo bit.
si deve iniziare da un controllo legato, ad es, a un campo testo, allora
tutto va bene.
come ho detto in post precedenti, ho verificato che prima di andare in
errore si verifica l'evento before update, il quale se intercettato e
annullato evita che l'applicazione vada in errore.
Tra l'altro l'evento si verifica 2 volte e entrambe le volte l'evento va
annullato.
Sib

 annullato.
Ho riprovato per filo e per segno _con la configurazione solita_ su una Form
con parecchie migliaia di records: nessun crash.
Tuttavia ho dovuto modificare il testo _pessimo_ dell'autocomposizione:
Dim rs As Object
 Set rs = Me.Recordset.Clone
 rs.Find "[ContMovim] = " & Str(Nz(Me![CasellaCombinata28], 0))
 If Not rs.EOF Then Me.Bookmark = rs.Bookmark
Con tale codice si verifica una strana cosa: dopo aver effettuato la
ricerca, il primo click sulla check box va a vuoto!
Sostituendo con un più consono:
With  Me.RecordsetClone
       .Find "[ContMovim] = " & Str(Nz(Me![CasellaCombinata28], 0))
       If Not .EOF Then Me.Bookmark = .Bookmark
End With
... nessun problema.
Saluti: Simone

 ricerca, il primo click sulla check box va a vuoto!
cut
stai usando sql/msde 2000?
comunque il fatto che vada a vuoto il primo click secondo me e' legato al
problema.
nel frattempo (CASO STRAORDINARIO) per la disperazione ho dato l'ok
all'invio delle informazioni sull'errore, staremo a vedere se mi arrivera'
una soluzione per il problema o i carabinieri per qualche programma piratato
;-)
Sib

 ;-)
Abbi fede!
Ciao: Simone

 tutto ok.
Simone, la tua soluzione mi ha dato la giusta via per superare questo bug.
io avevo usato nel mio codice questa istruzione:
With Me.recordset.clone
e dava quel problema, invece usando:
With Me.recordsetclone
tutto fila liscio.
resto comunque molto perplesso per l'inconveniente.
Ciao e grazie
Sib

 Ciao e grazie
Mi fa piacere per la raggiunta soluzione :-)
Dal canto mio sono sorpreso più che altro della rozzezza
dell'autocomposizione
realizzata da M$:
Dim Rs as object   ----  *warning*:  scelta di un tipo di dati poco
specifico
set Rs=me.Recordset.Clone  -----  Che ci fa il puntino? Mai visto prima!
*warning* -----  La variabile recordset non viene "uccisa" alla fine della
routine.
In altre parole: tutto in antitesi con quanto consigliato su Help,
manualistica, KB.
Ma secondo te ci sono o ci fanno?
Saluti.

 Ma secondo te ci sono o ci fanno?
Secondo me "ci sono".
Ciao
Sib