Newsgroup: it.comp.appl.access
Titolo: Gestione errore di violazione di chiavi

Ciao a tutto il ng.
 
Se, come purtroppo accade, l'operatore commette degli errori nell'imput dei dati, si rischia che questi comportino una violazione di chiavi durante la fase di accodamento in una tabella.
In questo caso purtroppo potrebbero essere anche numerose.
Allora invece del classico messaggio di access che ci comunica per l'appunto che non è stato possibile accodare un certo numero di record a causa della violazione suddetta, sarebbe più utile conoscere quali chiavi sono state violate, magari memorizzando i record non accodati in una tabella creata all'occorrenza.
Qualcuno di voi ha già avuto questa esigenza? Come l'avete affrontata?
Grazie, cranze


Le violazioni di chiave ci sono solo se cerchi di duplicare una chiave primaria, o inserisci record-figli senza record-padri. Tutte cose che non DEVONO succedere se la gestione della form di inserimento è corretta. In pratica che problema hai?


Ciao.
infatti. Il problema è che i dati vengono importati da un'altro database e relazionati per un id che in quello corrente ha la chiave primaria.
Se nell'altro database vengono imputati degli id non corrispondenti a quelli del db corrente,  durante l'importazione (accodamento in una tabella) ovviamente si verifica la violazione di chiave e il record contenente quell'id non può essere importato. Sarebbe interessante quindi intercettare l'errore per popolare una tabella con i record non importati.

 Come l'avete affrontata? Grazie, cranze
 
Mi ï¿œ capitato un'infinitï¿œ di volte: inappropriata definizione delle 
relazioni, errori dell'operatore, errori del computer, etc.
Non credo sia possibile ottenere di piï¿œ come messaggio di errore.
Occorre ragionarci un po' sopra (a volte si perde molto tempo) e 
individuare e correggere gli errori.
Ci si riesce sempre (una serie nutrita di moccoli puï¿œ essere 
d'aiuto...)
 
Bruno
 
 

Io pensavo di fare una cosa del genere:
prima di tutto una query per dati non corrispondenti in modo da rilevare quali ID non sono presenti nel DB corrente. Poi se il numero di record è diverso da 0, allora lanciare una query di creazione tabella per accodare i suddetti record contenenti le chiavi non corrispondenti e magari un bel msgbox che ci avvisa dell'impossibilità di accodarli con tanto indicazione del numero (recordset.recordcount), suggerendo quidi di controllare il risultato nella tabella appena creata.
Se invece il numero di record è uguale a 0, allora lanciare la procedura per l'importazione (accodamento) di tutti i record.
Non so se esista un modo più semDovrebbe funzionare

 record. Non so se esista un modo piï¿œ semDovrebbe funzionare
 
Sï¿œ il sistema che uso anch'io normalmente ï¿œ proprio quello di 
confrontare con delle query poche tabelle alla volta onde verificare 
dove mancano dati che dovrebbero essere relazionati.
 
Mi ï¿œ capitato l'errore anche questa settimana, perï¿œ, trattandosi di due 
dati soltanto, per farla breve li ho eliminati e reinseriti 
correttamente.
 
Bruno
 
 

Sì il sistema che uso anch'io normalmente è proprio quello di confrontare con delle query poche tabelle alla volta onde verificare dove mancano dati che dovrebbero essere relazionati. Mi è capitato l'errore anche questa settimana, però, trattandosi di due dati soltanto, per farla breve li ho eliminati e reinseriti correttamente. Bruno
 
 
Si il problema non è tanto cosa fare dopo... ognuno agisce secondo le proprie esigenze eliminando, inserendo o modificando i record non relazionati, ma cosa fare prima. Cioè se dopo l'avviso di access all'operatore si lascia comunque la possibilità di continuare l'importazione dei dati, si rischia di avere dati non congruenti. Quindi lo scopo di questa procedura è quella di evitare che l'operatore proceda con l'importazione dei dati finchè non allinea tutti i campi contenenti le chiavi primarie.
 
Saluti, cranze


Puoi fare 2 cose. SE (e sottolineo SE) gli Id li puoi cambiare, accodi tutti i record creando tu l'id (e SICURAMENTE non avrai problemi). Se no, come pensavi tu, lanci delle query a ripetizione con join con le tabelle in cui scriveresti i record nuovi. Basta il join (seleziona tutti i recod con id uguale). Il risultante lo sbatti in una tab a parte (se non trova nulla, non incolla nulla, non c'è necessità di dover decidere). Alla fine della procedura, esporti la tabella in xls, txt o quello che vuoi per l'utente, o visualizzi un mess (ci sono record problematici! Li vuoi vedere?) e poi una maschera in cui, magari,  puoi cambiare il fantomatico id. Ma, se puoi cambiare l'id, vuol dire che non te ne frega nulla di quello originale....ergo, fregatene e inserisci tutto con l'id giusto fin dall'inizio.

> Puoi fare 2 cose. SE (e sottolineo SE) gli Id li puoi cambiare, accodi tutti i record creando tu l'id (e SICURAMENTE non avrai problemi). Se no, come pensavi tu, lanci delle query a ripetizione con join con le tabelle in cui scriveresti i record nuovi. Basta il join (seleziona tutti i recod con id uguale). Il risultante lo sbatti in una tab a parte (se non trova nulla, non incolla nulla, non c'è necessità di dover decidere). Alla fine della procedura, esporti la tabella in xls, txt o quello che vuoi per l'utente, o visualizzi un mess (ci sono record problematici! Li vuoi vedere?) e poi una maschera in cui, magari,  puoi cambiare il fantomatico id. Ma, se puoi cambiare l'id, vuol dire che non te ne frega nulla di quello originale....ergo, fregatene e inserisci tutto con l'id giusto fin dall'inizio.
 
 
 
Esatto. Però la maschera la faccio solo perchè l'operatore prenda visione dei record incongruenti. La correzione dell'id deve essere fatta esclusivamente ed obbligatoriamente (altrimenti non permetto l'importazione) nel db da cui esporta i dati, altrimenti ogni volta si ripresentano gli stessi problemi.
 
Ciao