Campi obbligatori e duplicati(no key) nel "beforeupdate"

di il
8 risposte

Campi obbligatori e duplicati(no key) nel "beforeupdate"

Ciao a tutti,
sono nuovo di access ma voglio porre dei punti di attenzione credo interessanti. Sebbene io non nasca come programmatore e forse proprio per questo veniamo a noi.
Ho sudato un pò nel realizzare una semplice applicazione access per la gestione del magazzino.
Molto semplice 2 tabelle, una per catalogo prodotti (con attributi ect) e una per i carichi e scarichi . Ho poi ho aggiunto una voce alla tabella catalogo che aggiorno per ogni carico/scarico.
Poi ho aggiunto del codice per i controlli di congruenza in input (before update, campi obbligatori ee campi duplicati (non vogliomo lo stesso prodotto due volte.....) e logiche di calcolo nel afterupdate. Ho usato tutti i potenti strumenti standard offerti quali maschere prefinite da tabella, pulsanti standard (salva, aggiungi, elimina, etc), campi di origine esterna su maschera (non vogliamo replicare le informazioni ect), contatori , integrita referenziale, controllo da DB.
L'applicazione è completata, gioco fatto.
Non credo la mia applicazione abbia avuto esigenze particolari di sviluppo: insomma
- 2 tabelle
- controlli before update
- logiche di calcolo afterupdate


Per fare ciò ho sudato troppo!!! Mi spiego meglio. Per usare gli strumenti standard molto potenti
ho dovuto seguire delle logiche contorte che vanno contro l'intuitività di uno strumento user-frendly come access. Vediamo:

Nei controlli beforeupdate:

- per i campi vuoti ho usato il beforeupdate della form
- per i duplicati (non chiave)ho dovuto ricorrere ai controlli da DB intercettare poi l'errore nell' Error_form per mettere un testo decente.
- ho dovuto modificare le macro dei pulsanti SALVA e AGGIUNGI intercettando l'errore nell' Error_form per mettere un testo decente. (attenzione a mettere sulla stessa maschera AGGIUNGI e SALVA perchè i controlli del beforeudate funzionano una volta si una no)
- nell'utilizzare i campi esterni su maschera comandati da chiave esterna ho dovuto usare i controlli da DB e intercattarli su Error_form ... altrimenti la query definita sul campo nella maschera va in errore se metti una la stringa vuoto perchè prende un intero giustamente.

Insomma due tabelle in chiave (prodotto e carichi), un beforeupdate di validazione su campi vuoti
e duplicati, campi esterni su maschera, un update di calcolo = un bagno di sangue!!!!
Ma è possibile o mi sfugge qualcosa?? Possibile non ci sia un modo piu veloce usando gli strumenti standard offerti???

Grazie

8 Risposte

  • Re: Campi obbligatori e duplicati(no key) nel "beforeupdate"

    Allego schemate...
    Allegati:
    9208_25fdf9e9e233eddb13fcf95c4901939e.gif
    9208_25fdf9e9e233eddb13fcf95c4901939e.gif

    9208_b46e60a314290b198d617872c8e0c775.gif
    9208_b46e60a314290b198d617872c8e0c775.gif
  • Re: Campi obbligatori e duplicati(no key) nel "beforeupdate"

    Non ho capito la logica nei minimi particolari, ma mi pare di capire che poi, alla fine, tutto funziona.
    Ebbene sì, è del tutto normale che, se pretendi che per ogni input, avvenga un controllo sulla validità dei dati, devi crearti un labirinto di istruzioni di controllo. Se funziona, ti tornano utili poi.
    Se sei accorto nel digitare solo valori corretti, puoi evitare il bagno di sangue.
  • Re: Campi obbligatori e duplicati(no key) nel "beforeupdate"

    Il titolo usato non è consono al Forum... è normale che sia un problema di ACCESS vista la sezione...
    Il titolo deve servire per consentire agli utenti di capire l'argomento senza dover entrare o per fare RICERCHE funzionali.

    Ti chiedo cortesemente di MODIFICARLO.
  • Re: Campi obbligatori e duplicati(no key) nel "beforeupdate"

    Ciao maxiteris, ti chiedo di modificare il 3d e cambiare il titolo come ti ha fatto notare @Alex altrimenti sarà eliminarlo.
  • Re: Campi obbligatori e duplicati(no key) nel "beforeupdate"

    Credo il titolo vada meglio... il 3d non ho capito cosa intendi.
    Fammi sapere
  • Re: Campi obbligatori e duplicati(no key) nel "beforeupdate"

    3D è l'abbreviazione di "thread" che presuppone una discussione, come questa...!

    Il titolo ora mi pare adeguato.

    Per venire alla tua analisi.
    In prima cosa serve che tu riesca a comprendere in modo NETTO la distinzione tra JET e ACCESS.

    JET è il DB_Engine, quello che contiene le tabelle per capirci.
    ACCESS è il Client che comprende Mashcere/Queries/Report/Macro e VBA(Moduli)

    Ci sono 2 metodi per gestire le cose:
    1) Definire a livello di DB(quindi JET e Tabelle) l'obbligatorietà ed i criteri di Validazione dei Campi.
    2) Si scrive nelle Form quanto serve per evitare il Duplicato e confermarne la validazione.

    Che differenza sostanziale c'è tra i 2 sistemi...?
    Con Access-JET non moltissimo in sostanza, come dovresti sapere JET non è un motore di Database particolarmente performante... tuttavia...

    Se definisci nelle Tabelle i vincoli e le validazioni, otterrai ERRORI nelle Form(giustamente Evento Form_Error) in quanto generati da JET ed ereditati dalla Form.
    Chiaramente la gestione erorri della Form sarà ben più complessa, dovrai gestire l'ActiveControl ecc...

    A quel punto il Before Update... non serve, e se non devi essere troppo attento ai dettagli con pochissime righe di codice nell'errore risolvi tutto...

    Se invece gestisci il tutto a livello di Form direi che gestire l'Error di Form dovrebbe non servire... in quanto gestire il Before di Form con il relativo CANCEL dovrebbe bastare...
    Ovvio che nell'evento BeforeUpdate di Form dovrai ciclare tutti i controlli e, controllarne l'eventuale Duplicazione e la Validazione, quì chiaramente serve un pò più di struttura.
    Lo svantaggio è che per ogni controllo/Campo hai un criterio specifico che da qualche parte devi definire...

    A questo punto il Salvataggio, quindi CANCEL=FALSE si otterrà se tutti i controlli(campi) soddisfano.

    Da quanto ho capito, ma magari sbaglio, tu hai fatto un'ibrido, nulla di trascendentale, anche questo è fattibile, io però non di norma sono abituato a CONCENTRARE in un solo punto tutti i criteri, così non devo ricordarmi cosa o fatto e dove.

    La risposta alla tua domanda a questo punto è semplice e banale... Access è uno strumento banale se lo usi in modo banale con l'autocomposizione senza spingere i tecnicismi a livelli professionali, senza fare controlli di sicurezza...
    Se invece, come hai fatto tu, cerchi di predisporre uno strumento a prova di "UTENTE" allora le cose cambiano.

    Ti ricordo che Access basato su Database relazionali seri(SQL o ORACLE), stanno gestendo i magazzini e la produzione di aziende che fatturano qualche cedina di milioni di € l'anno... ormai dal 95 , questo solo per farti capire che è un pò come la frase di Forrest Gump "stupido è chi lo stupida fa..."

    Sono ormai 18anni che uso Access a livelli +/- professionali e, a parte ora che è uscito NET direi che se non hai necessità di Grafica particolari, offre vantaggi di sviluppo rispetto a VB6 non di poco conto, ha dei contro proprio nell'ottica di componenti aggiuntivi(Activex) e nel gestire librerie di comunicazione... ma non è stato pesato per questo.
  • Re: Campi obbligatori e duplicati(no key) nel "beforeupdate"

    Direi che è una ottima risposta e che hai centrato il problema.
    Ho fatto un ibrido che funzione bene. Il thread nasce dalla necessità come hai indicato tu
    di concentrare tutti i controlli in un solo punto e cioè nel beforeupdate che poi permette
    di personalizzare i messaggi per ogni campo e richiedere una conferma all'utente cose che
    ovviamente delegando al DB non si possono fare. Quindi ricapitolando e seguendo questa strada
    ho due problemi:

    1. duplicazione: nei campi obbligatori la logica è molto semplice una serie di if a cascata. Nel caso però di duplicazione del campo (per esempio nome prodotto) il problema nasce dal fatto che in apertura della maschera non cè un parametro in inserimento o modifica quindi non basta verificare se il nome esiste già come per l'inserimento perchè in modifica chiaramente non funziona. Occorre ricorrere ad una logica che verifichi prima se si è in ins o modif ecc.... molto contorta usando oldvalue etc... Non cè un modo di trovare con una sola condizione se si tratta di duplicato sia in caso di inserimento che di modifica cosi da ricondurre il tutto ad una semplice cascata di IF? Da qui putroppo la scelta ibrida!

    2. gestione della query su campo esterno:
    utilizzando i campi esterni mediante chiave esterna, cosa molto gradita, se viene posto a null il campo da parte dell'utente prima di ogni evento la query definita su "origine riga" del tab dati del campo va giustamente va in errore. Come fare? Stavo pensando di usare il parametro "valido se" ma non riesco a farlo funzionare a dovere? Hai delle idee?

    Grazie
  • Re: Campi obbligatori e duplicati(no key) nel "beforeupdate"

    maxiteris ha scritto:


    Direi che è una ottima risposta e che hai centrato il problema.
    Ho fatto un ibrido che funzione bene. Il thread nasce dalla necessità come hai indicato tu
    di concentrare tutti i controlli in un solo punto e cioè nel beforeupdate che poi permette
    di personalizzare i messaggi per ogni campo e richiedere una conferma all'utente cose che
    ovviamente delegando al DB non si possono fare.
    Diciamo che non ho detto esattamente questo, ed è palese la tua interpretazione volta a sostenere la tua strategia attuale... ma è bene distinguere le cose...!!

    La gestione sulle Tabelle consente di fare MOLTISSIMO, anche di discriminare il Controllo/Campo che ha generato il problema in quanto è di norma l'active control... o al massimo il Prevous se si è premuto un Button...
    Questo codice poi consente di sapere qual'è il Testo che ha generato l'errore, sempre che l'errore dia di JET...
    
    Private Sub Form_Error(DataErr As Integer, Response As Integer)
    
    End Sub
    Tuttavia ci possono essere delle limitazioni, e su questo posso concordare.

    maxiteris ha scritto:


    Quindi ricapitolando e seguendo questa strada
    ho due problemi:

    1. duplicazione: nei campi obbligatori la logica è molto semplice una serie di if a cascata. Nel caso però di duplicazione del campo (per esempio nome prodotto) il problema nasce dal fatto che in apertura della maschera non cè un parametro in inserimento o modifica quindi non basta verificare se il nome esiste già come per l'inserimento perchè in modifica chiaramente non funziona. Occorre ricorrere ad una logica che verifichi prima se si è in ins o modif ecc.... molto contorta usando oldvalue etc... Non cè un modo di trovare con una sola condizione se si tratta di duplicato sia in caso di inserimento che di modifica cosi da ricondurre il tutto ad una semplice cascata di IF? Da qui putroppo la scelta ibrida!
    Quando sei in modalità di Inserimento Nuovo... c'è una proprietà di Maschera che viene attivata
    ma fai attenzione che in questo caso prima di BeforeUpdate viene generato il BeforeInsert...
    La proprietà da leggere è [NewRecord].

    maxiteris ha scritto:


    2. gestione della query su campo esterno:
    utilizzando i campi esterni mediante chiave esterna, cosa molto gradita, se viene posto a null il campo da parte dell'utente prima di ogni evento la query definita su "origine riga" del tab dati del campo va giustamente va in errore. Come fare? Stavo pensando di usare il parametro "valido se" ma non riesco a farlo funzionare a dovere? Hai delle idee?
    Grazie
    Se il Campo non è obbligatorio il campo non è necessario che venga compilato, tuttavia se il campo è Numerico o Stringa l'errore viene generato se viene posto a NULL.
    Ti ricordo che NULL è un valore molto particolare e completamente diverso da NullString o "" come si usa spesso in modo erroneo...
Devi accedere o registrarti per scrivere nel forum
8 risposte