Newsgroup: it.comp.appl.access
Titolo: Cosa sono i semafori?

Ciao a tutti,
proprio oggi mi sono scontrato (e fortunatamente ho risolto) dei
problemi che avevo su una form con campi non associati.
Il mio capo mi ha detto che avrei potuto risolvere il problema usando
i "semafori" poi facendo un giro su google groups leggo in un post in
cui si parla di semafori anche di "mutex".
Sapreste dirmi cosa sono i semafori e le mutex?
Ciao,
Lorenzo

 i "semafori" poi facendo un giro su google groups leggo in un post in
aaahhh... vecchie reminiscenze universitarie...
I semafori (e si parla anche di "monitor") sono più o meno degli algoritmi
logici, realizzabili poi in vari metodi pratici, che permettono di gestire
l'uso delle risorse condivise quando ci possono essere dei problemi di
concorrenza.
Non capisco in che modo c'entrino però nel discorso dei campi non
associati...
Antonio
P.S.
Sniff...
che nostalgia...

 ha scritto nel messaggio
news:jBiV9.8735$YG2.2...@twister1.libero.it...

Di solito si usano in sistemi multi processore e servono per gestire il
flusso logico del programma lungo vari thread
es. l'algoritmo che ti fa sedere sulla sedia del barbiere viene bloccato dal
semaforo finchè l'algoritmo che fa alzare il cliente precedente dalla sedia
non è finito.
Capito? Non so che centri con i campi no associati comunque
AEOM

 associati...
Il problema era quello che poi ho letto essere un classico dello
sviluppo in Access sull'Access Developer Handbook scrivere su una
tabella con controlli associati e confermare le modifiche solo
premendo per es. il tasto "Salva"... lo stesso Acc Dev Handbook
suggerisce di usare i controlli non associati allo scopo.
Io ho risolto nel modo, credo, classico cioè con i controlli non
associati e un'infinità di codice per la validazione degli input
(quando sarebbe bastato il tipo di dato del campo nel caso del
controllo associato che in caso di input assurdi avrebbe restituito
l'errore "E' stato immesso un valore non valido per il campo")... il
mio capo (evidentemente siete due vecchietti ;-) mi ha parlato di
semafori a proposito del fatto di poter salvare il record solo a
conferma avvenuta che i dati fossero corretti.
Ciao e grazie,
Lorenzo
P.S Urge comprarmi un bel libro sugli algoritmi!!! ;-)

 P.S Urge comprarmi un bel libro sugli algoritmi!!! ;-)
Mi sa che ti serve un bel libro su access invece ;-)
Sib

 gestore potente come access a disposizione?
Forse perchè il capo non conosce altro!
Ciaooo

 gestore potente come access a disposizione?
In effetti programmava in COBOL prima di passare ad Access ;-)
Mi sa che lo licenzio il capo!! ;-) Tu però come fai a risolvere
questo tipo di problemi?
Ciao,
Lorenzo

 questo tipo di problemi?
Dipende.
Se usi A2000 puoi veramente utilizzare un adp che, come tu stesso riporti,
possiede queste caratteristiche.
personalmente non ho mai trovato problemi a usare maschere normali ed
eventualmente cancellare i dati inseriti.
Fermo restando che finche' non salvi il record corrente puoi annullare tutto
premendo esc.
Ciao
Sib

 premendo esc.
Tecnicamente come fai? Usi un bookmark per marcare il record inserito ed
eventualmente lo cancelli?
Il problema si pone anche nel caso di una maschera di modifica dei dati
inseriti ma in quel caso risulta tutto moooltooo più semplice utilizzando un
tip che ho trovato sul mitico 
www.mvps.org/access
 ... in sostanza si tratta
di usare le proprietà controllo.value e controllo.text agganciate all'evento
Change (Modifica) del controllo, infatti i valori mostrati dalle due
proprietà si aggiornano in momenti diversi .text mostra l'uncommitted value
(prima dell'inserimento) e .value mostra il committed value (quello che già
risiede nel record).
Private Sub NumFatt_Change()
lbValPrecedente = Me.NumFatt.Value
    If IsNumeric(Me.NumFatt.Text) Then
    '
    Else
        MsgBox ("Inserire un valore numerico")
        Me.NumFatt.Value = lbValPrecedente
        Exit Sub
    End If
End Sub
Ciao,
Lorenzo
--------------------------------
Inviato via 
http://usenet.libero.it


sul sito comune (
www.sitocomune.com
) c'e' un esempio che ritengo
"elegante" 
che usa un workspace a livello di form per fare quello che, mi sembra ,
richiedi e
lo fa con form di tipo associato. Gli esimi autori di ADH qualche volta,
come dice
sib, usano una geometria "non" euclidea
mi sa che il capo licenzia te se non gli risolvi il problema ;<)
--
a.cara 
Togli qualcosa dall'email

 l'errore "E' stato immesso un valore non valido per il campo")... il
Personalmente spesso trovo più semplice molte volte la maschera non
associata con controllo "off line" dei valori inseriti che gestire con
annullamenti successivi ad errori del sistema l'input errato.
Non è poi così peregrina l'idea, IMHO
Antonio

 gestore potente come access a disposizione?
permettimi di dissentire:
a parte l'uso delle maschere non associate che trovo spesso molto utile e
più semplice, anche se con un po' più di codice sotto, il concetto di
semaforo è molto importante nell'informatica, e non lo ritengo una tecnica
da cobol...
ma era questo che intendevi?!?
Antonio

 inseriti ma in quel caso risulta tutto moooltooo più semplice utilizzando
un
cut
scusa ma sto perdendo di vista il tuo problema.
qual'e' il problema? perche' mi pare che ti poni quesiti su problemi che non
ci sono.
Forse dovresti dare un'occhiata agli eventi:
BeforeUpdate
AfterUpdate
BeforeInsert
AfterInsert
della maschera.
Sib

 ma era questo che intendevi?!?
No, non intendevo dire che il semaforo fosse una tecnica da cobol, dicevo
che le maschere non collegate, salvo quando non strettamente necessario sono
tecniche da cobol.
Ad ogni modo io trovo molto comodo che a preoccuparsi del semaforo sia
access.
personalmente non ho mai incontrato problemi a gestire qualsiasi tipo di
inserimento tramite maschere collegate. trovo molto piu' semplice cancellare
eventualmente i record inseriti per sbaglio piuttosto che gestirli come
effettivamente temporanei per poi caricarli in tabella da vb. anche perche'
non penso che la gente si metta a inserire record a caso per annullarli
cosi' per gioco, quindi il caso da ritenere meno frequente e' l'annullamento
di un inserimento e non il suo effettivo inserimento.
Ovviamente parliamo di database Access (5-10 utenti in lan 100Mb)
Sib

 ha scritto nel messaggio
news:gsjV9.8905$ZE.2...@twister2.libero.it...

Dopo aver ascoltato ne dico una anch'io.
Io spesso uso una Form non associata, con una QRY Update o Insert eseguo
modifiche o AddNew.
Semplice e scontato, mica ho scoperto l'acqua calda.
Qual'è il problema, controllare i dati...., benissimo, quando esegui la QRY
Action
basta non usare il metodo RunSQL, ma EXECUTE sull'oggetto CurrentDB o quello
che è il DB.
Con questo stupidissimo modo si possono usare le tranzazioni........!!!!!
Le transazioni......, già se c'è un errore per il quale non può salvare o
eseguire la
QRY esegui il RollBack........!!!
Vantaggio nessun controllo da fare, se i dati non corrispondono non salva.
Beh, adesso che l'ho detta, mi sono sfogato.......!
@Alex.

 AfterInsert
Ciao Sib,
il problema è che nel momento in cui trappo uno qualsiasi degli eventi
che mi suggerisci in una maschera con controlli associati il record
sotto l'ho già sporcato e non voglio pensare ai casini per
ripristinare il valore che c'era sotto nel caso in cui l'utente si
accorga al momento di aver sbagliato a digitare qualcosa.
Ciao e grazie cmq della risposta! ;-)
Lorenzo

 Vantaggio nessun controllo da fare, se i dati non corrispondono non
salva.
Bell'idea Alex... essendo un novizio di Access (sono un baby di 1 anno
;-) che impara le cose man mano che gli servono (essendo Access
infinito) non avevo ancora pensato alle transazioni per risolvere il
problema e non sapevo che già con una transazione si potesse far fare
il controllo ad Access... davvero molto bello! :-))
Ciao,
Lorenzo

 ha scritto nel messaggio
news:tbGV9.13089$ZE.3...@twister2.libero.it...

He... sembra facile.....!!!
Tienimi informato credo che con una 10na di righe di codice
si faccia tutto....!
Se non vuoi usare le tranzazioni il Metodo Execute ha un parametro
che si imposta=DbFailOnError, che fa +/- la stessa cosa, leggermente
meno gestibile.....!
Prova a dare un'occhiata Help(Execute).
@Alex.

 accorga al momento di aver sbagliato a digitare qualcosa.
ma di cosa stai parlando?
guarda che l'evento before update si verifica PRIMA che il record venga
salvato quindi non hai ancora sporcato un bel niente.
non parliamo poi dell'evento beforeinsert che si verifica addirittura prima
che access inizi a creare la struttura temporanea che conterra' il record da
salvare.
Sib

 Beh, adesso che l'ho detta, mi sono sfogato.......!
Ciao alex,
fermo restando che ognuno adotta la tecnica che ritiene piu' adatta, ritengo
che le l'uso delle query di comando, per forza di cose generate
dinamicamente da codice, pongano seri problemi di gestione da parte di chi
non abbia sufficiente esperienza, mi riferisco ai campi data, valuta e
numerici che richiedono particolari manipolazioni.
Per non parlare del fatto che questo metodo non si puo' usare in maschere
continue (unico caso in cui personalmente giustifico in parte il
preoccuparsi di annullare gli inserimenti) dove il metodo delle query di
comando ha senso solo usando tabelle temporanee di appoggio.
cosa ti fa preferire le query all'evento before update?
Sib

 cosa ti fa preferire le query all'evento before update?
In parte ho già risposto, ma in più aggiungo che con BeforeUpdate
devi effettuare una verifica per ogni Controllo....!
Molte volte è necessaria, ma non sempre, in quei casi non
particolarmente
critici mi è parsa una buona soluzione veloce e affidabile.
Ciao.
@Alex.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 critici mi è parsa una buona soluzione veloce e affidabile.
come dicevo, ognuno valuta cio' che ritiene piu' opportuno, quindi la mia
non e' assolutamente una critica alla tua tecnica.
Solo che non vedo la differenza tra l'evento before update e l'uso di una
procedura per eseguire l'accodamento da codice.
Sib


Risparmio x righe di codice.....!
Supponi di avere 30 Campi in Tabella--->30Controlli associati--->30
Controlli Inserimenti...!
Alcune volte usando le Qry della Tecnica citata con 10 righe in tutto si fà,
solo se conviene....!
Dai Sib sto tirandola lunga per nulla...., concordo pienamente con le tue
osservazioni.............!
@Alex.

 Controlli Inserimenti...!
cut
ma io intendevo l'evento before update della maschera, non dei singoli
controlli.
Ciao
Sib

"Sib" <si...@SPAMiol.it> ha scritto nel messaggio
news:QuyW9.21823$YG2.6...@twister1.libero.it...

Si, ma anche considerando quello devi ugualmente controllare o no...?
Se non controlli anche su BeforeUpdate di Form devi intervcettare
l'errore, che in ogni caso si verifica su AfterUpdate....!
Altrimenti l'Evento di riferimento diventa OnError...di Maschera...!!
Magari sto fraintendendoti.....??(che parolona....)
@Alex.

 Magari sto fraintendendoti.....??(che parolona....)
:-)
sib

"Sib" <si...@SPAMiol.it> ha scritto nel messaggio
news:2yVW9.76773$AA2.3...@news2.tin.it...

Non sò come spiegarti meglio....!!
In pratica ora se utilizzi l'evento BeforeUpdate, come controlli
che all'immissione dei dati il contenuto dei CONTROLLI concordi
con il Type del Fields in cui salvi....?????
Il problema al quale mi riferivo è questo....!!!
Non mi dire che basta imporre il tipo di dati sulla TxtBox......risolve solo
1/3 dei
problemi......!
Spero di essere stato + chiaro....!
Purtroppo spiegarmi non è il mio forte, molte volte addirittura non mi
capisco....!
@Alex.

 capisco....!
Esagerato!
Sib