Filippo70 ha scritto:
Dopo innumerevoli prove e riprove il succo stava nell' aver spuntato solo la casella applica integrità referenziale e non le altre due!!!
Ci sono arrivato perchè dovevo scrivere il codice dei nuovi pulsanti (suggerimento di Phil) ma non mi faceva convertire le macro in VBA con access 2010. Allora ho provato a copiarmi il DB su access 2003 e li tutto funzionava regolarmente!!! (perchè ho dovuto riscrivere le relazioni a mano e ho spuntato tutto, già che c' ero). Allora perchè su Access 2003 funzionava e su Access 2010 no? L' ultimo input me l' ha dato Osvaldo facendomi ricontrollare le relazioni. Dovevo semplicemente spuntare tutto, cosicchè Access (con un solo pulsante nella maschera principale) adesso prima mi chiede se voglio veramente cancellare il record e i sui figli, e poi però mi consente la sua cancellazione
Attento! le tre opzioni da spuntare nelle relazioni tra tabelle sono in ordine crescente di pericolosità (e di frequenza di utilizzo)
La prima, Applica integrità referenziale: pericolosità quasi nulla e di uso fondamentale. E' pericolosa solo per chi ha scritto codice di pessima qualità o strutturato male il db perché evidenzia immediatamente tutti i difetti
La seconda, Aggiorna campi correlati a catena: pericolosità intermedia perché pur non cancellando niente è difficile "tornare indietro" in caso di manovre sbagliate. Ma insomma... seppur relazionati male i dati ci sono ancora.
La terza, Elimina record correlati a catena: pericolosità massima. Qui i record vengono cancellati. Certo, ci sono gli avvisi ma... si possono anche disabilitare, in via permanente, intenzionalmente, da interfaccia grafica o perché inseriti in qualche
DoCmd.SetWarnings = False
del codice che si considera innocuo.
Che sia molto comodo, per quello che volevi fare, averle abilitate è indubbio ma molto pericoloso.
Tanto che queste operazioni di aggiornamento - cancellazione "a cascata" dovrebbero (a mio avviso) essere oggetto di maschere ad hoc perché hanno un impatto notevole sui dati, delegando il tutto a codice appositamente studiato (che ad esempio può essere inserito in una transaction per avere un'ulteriore possibilità di ripensamento o che automaticamente crea copie di sicurezza delle tabelle o che riepiloga i dati aggiornati - cancellati salvandoli da qualche parte o ad esempio esportandoli in un foglio di calcolo o in un file di testo).
Se ci metti le mani solo tu: chi è causa del suo mal pianga se stesso. Se ci mettono mano altri... potresti essere sempre tu la causa del mal (solo tuo o di tutti i fruitori del db) avendo permesso troppo facilmente alcune operazioni. Ehi, sia chiaro: anche da codice si possono far danni, ma se studiato bene è meno probabile.
In qualche sito ricordo di aver visto che un utente aveva indicato nella parte relativa alla personalizzazione dei suoi post una frase che suona, in italiano, più o meno così: il mio codice è a prova di bug, non a prova di utonto (in inglese era user ma utonto rende meglio la traduzione).