Informaticando.NET un intorno web sull'informatica di Giorgio Borelli

Il campo contatore o Id Replica in un database Access è un numero naturale crescente di 16 bytes, non può essere ri-ordinato e non può essere fatto ripartire da zero o da un numero intermedio rispetto al numero più grande che attualmente è inserito. Proprio per queste sue particolarità, viene usato quasi sempre come chiave primaria in una tabella, proprio perchè essendo un numero unico, identifica in maniera univoca il record. Se ad es. abbiamo 3 records, numerati con Id 5, 6 e 7, se cancelliamo il record 6, il contatore ad un nuovo inserimento comincerà a partire da 8 perdendo la posizione intermedia; o ancora se il nostro contatore è arrivato al record 120 e svuotiamo la tabella, questo ripartirà da 121 e non da zero.

Sebbene questo non sia un problema determinante, tuttavia, da parte degli utilizzatori di Access è molto sentita l'esigenza di azzerare i campi contatore, vuoi perchè la fase di sviluppo è terminata e si desidera partire con un database vuoto ed i contatori azzerati, vuoi per una maggiore precisione e pulizia del database. Qualunque sia lo scopo o l'esigenza Come fare per azzerare il campo contatore in Access?

Prosegue...

Durante la fase di sviluppo di un'applicativo, possiamo imbatterci in questo messaggio d'errore "OleDbException (0x80040e57): Inserire o incollare meno dati" generato a run-time, ovvero si manifesta solo in fase di esecuzione, e non ne capiamo il motivo, il tutto sembra girare perfettamente, funziona, eppure in qualche particolare caso compare questa eccezione, qual'è la causa? Quale errore commettiamo?

L'eccezione a cui faccio riferimento è generata dal Data Provider OleDb, compatibile sia con Access che con le vecchie versioni di Sql Server (dalla 7.0 in giù), il problema però è generico e può presentarsi anche con Data Provider specifici come il Jet Engine di Access. Il problema è nella insert, o meglio si manifesta durante un comando sql insert, risolverlo è davvero banale, andiamo a scoprire come fare.

Prosegue...

Quando si progetta un database per un'applicativo, dopo aver pensato bene e fatta un'analisi dell'architettura della sorgente dati e steso il diagramma ERD (Entità Relazioni), il passo successivo è quello di cominciare a definire le tabelle con i propri tipi.

La definizione dei tipi in un database è un'operazione molto importante, poichè la scelta adeguata del tipo di dato adatto a rappresentare un'informazione, costituisce la base per lo sviluppo di un'applicazione funzionale e manutenibile, e permette inoltre di ottimizzare le tabelle, archiviando i dati nel loro formato corretto e rispare bytes gestendo il tipo corretto.

Anche per Access vale quanto detto, sebbene sia usato spesso per applicazioni di piccole dimensioni, la definizione dei tipi in Access assume un'importanza se vogliamo ancora più rilevante, proprio per ottimizzare al meglio la base di dati e risparmiare spazio, sfruttando così appieno le sue potenzialità ed il limite di 2Gb di spazio per l'archiviazione dati che esso ci mette a disposizione.

Conoscere e definire i tipi di dati corretti in Access, è di fondamentale importanza per la stesura di un database performante. Andiamo a vedere quali sono i tipi di dati definibili in Access.

Prosegue...

Un database Relazionale, a differenza di un database "normale", permette di definire delle relazioni tra le varie entità (tabelle) del db in modo tale da correlare i vari dati secondo una logica che astrae la realtà. Le relazioni tra le tabelle, permettono di manipolare i dati più facilmente e soprattutto evitano la ridondanza dei dati, ovvero la duplicazione inevitabile delle informazioni che si avrebbe nel caso di definizione di tabelle indipendenti. Un Diagramma Entità Relazioni (Entity-Relationship Diagram o ERD) come quello mostrato in figura, rende immediatamente idea di come le tabelle del database sono collegate tra di esse e quali siano le loro relazione.

La potenza e la flessibilità delle relazioni tra l'entità del db ci consente di collegare i dati che andremo a gestire con la nostra applicazione, collegando i record delle nostre tabelle in modo da gestire più informazioni (lettura, scrittura, aggiornamento) con una singola query sql, anzichè con molteplici query su singole tabelle indipendenti, ed evitare di fatto la replicazione di record (ridondanza dei dati) ed informazioni già presenti. Tutti i più moderni e diffusi database  quali: Sql Server, MySql, Oracle, Postgree SQL sono relazionali, e sebbene meno potente di quest'ultimi anche Microsoft Access è un database relazionale e permette di definire le relazioni tra le tabelle sia in maniera manuale che in modo guidato con estrema semplicità.

Un'altro aspetto fondamentale da tenere in considerazione durante la progettazione di un database e per la definizione delle relazioni tra le tabelle e se queste devono soddisfare o meno determinate regole di unicità e vincoli d'integrità, che assicurino la correttezza e la consistenza dei dati. Uno dei vincoli sicuramente più usato e diffuso è quello d'integrità referenziale.

Il Vincolo d'Integrità Referenziale è una "regola" che stabilisce che la presenza dei record tra le entità relazionate soddisfi necessariamente la presenza delle chiavi nell'una e nell'altra tabella. Tale vincolo assume pertanto il significato di predicato, che può assumere il valore di vero o falso, a seconda che la base di dati definita lo soddisfi o meno. Il Vincolo d'Integrità Referenziale (uno dei più diffusi ed usato), assicura la consistenza e la correttezza dei record presenti in un database, evitando che ci siano record orfani, ovvero che non hanno riferimento nella tabella collegata.

Anche con Access è possibile definire il Vincolo d'Integrità Referenziale, peremettendo di specificare anche quali azioni (effetto a catena) intraprendere sui record nel caso venga modificato o cancellato un record relazionato con record di altre tabelle.

Prosegue...