Database condiviso con doppia maschera

Ciao a tutti,
devo creare un database (access 2007) per i miei magazzinieri.
Il database ha lo scopo di dare a loro quotidianamente la lista dei giri da fare (quindi riporta i codici da movimentare, i fornitori o i clienti da cui andare, la fascia oraria, ecc...).
Io l'ho pensato diviso in due parti: la prima per l'immissione dei dati e la seconda per la consultazione ed il feedback.

Vista la mia scarsa conoscenza di access ho proceduto nel seguente modo:
Creato la tabella movimenti (con campo "Fatto?" come campo "Si/No")
Creato la maschera di immissione
Diviso il database in back end (su una cartella di rete condivisa) e front end

Ora mi sono bloccato perché non so come strutturare la parte del magazzino: consultazione e feedback.
Io deduco che si debba creare una seconda maschera (perché c'è un dato da inserire) che però consenta di visualizzare solo alcuni dati (i giri di oggi o più vecchi senza il flag "Fatto?").
Qualcuno ha dei consigli?

Secondo me confondi i 2 concetti:
- strutturare per bene (si dice "normalizzare") il database
- dividerlo per motivi di condivisione e/o protezione.

Il secondo direi che viene in un secondo momento, mentre il tuo problema più imminente è quello di strutturare correttamente l'insieme di tabelle che devono interagire.
Però...credo che hai fornito scarsi indizi per capire quello che hai fatto e quello che vuoi ottenere.

Va anche bene che tu voglia separare/schematizzare ciò che è INPUT da ciò che è CONSULTAZIONE. Anche questo aspetto va affrontato successivamente.

Per ora ho semplicemente creato la tabella "Movimenti" con i campi:

• ID (contatore)
• FORNITORE (casella combinata con elenco valori)
• CODICE (casella combinata con elenco valori)
• TIPO (casella combinata con elenco valori)
• DATA (data ora)
• FASCIA ORARIA (casella combinata con elenco valori)
• NOTE (testo)
• FATTO? (spunta SI/NO)

Su questa ho creato una mschera con la procedura guidata.

Tu cosa suggerisci?

Un campo con il ? non è affatto consigliabile.

Comunque, partire dalla tabella dei movimenti mi sembra sbagliato. Dovresti fare un progetto complessivo del DB, partendo dalle anagrafiche (ad es. quella dei Fornitori) con relative tabelle, chiavi primarie e chiavi esterne nelle altre tabelle dove servono. Che senso ha replicare il Fornitore nei Movimenti?

Utilizzare Access è solo una minima parte del lavoro. Quello che è importante, a prescindere dal DB utilizzato, è avere una buona conoscenza delle problematiche di progettazione DB.

Il campo ID meglio chiamarlo IDMovimento.

FORNITORE? Casella combinata ELENCO VALORI?
Hai detto che i magazzinieri vanno tanto da un Fornitore quanto da un Cliente. Ma a loro cosa importa della differenza? Dovresti predisporre una tabella RagioniSociali (che non fa distizione fra Fornitore o Cliente) con i classici campi anagrafici:
IDRagioneSociale
RagioneSociale
Indirizzo
IDComune (se gradisci servirti di una tabella Comuni che alimenta questo campo)
Poi relazioni RagioniSociali.IDRagioneSociale uno-a-molti Movimenti.IDRagioneSociale

CODICE e TIPO non ho capito cosa rappresentano.

Per tutte le caselle combinate ti consiglio di usare sempre una tabella/query di riferimento. "Elenco valori" si usa solo per pochi e insignificanti valori (ad es. Sesso=F/M; Sig./Sig.ra/Sig.na).

Mi raccomando quando crei le relazioni uno-a-molti di mettere sempre il segno di spunta su "Applica integrità referenziale".