Newsgroup: it.comp.appl.access
Titolo: Maschera di inserimento

Ciao a tutti.
Nel mio db ho due tabelle relazionate; Istituti e Conto corrente, uno a
molti.
Domanda: E' possibile creare una sola maschera di inserimento senza usare la
sottomaschera, utilizzando una combobox come prima casella che farà
riferimento alla tabella Istituti (come relazione uno) in modo da poter
scegliere l'istituto desiderato e successivamente immettere i restanti dati
riferiti alla tabella Conto (come relazione molti) ?
Se non è possibile, come posso procedere?
Grazie a tutti.
Roberto


E' Possibile.
Cbx non associato in testata form a fronte dell'afterupdate imponi il 
filtro sul form. Se non e' chiaro "ritelefona"
--
ac

 ac
Sono costretto a "ritelefonare". Ho fatto "quasi" come sopra, dico quasi in 
quanto non ho capito bene come devo imporre il filtro sul form. Risultato, 
un errore che dice: "Impossibile aggiungere o modificare il record. Nella 
tabella "Istituti" è necessario un record correlato".
Ho saltato qualcosa?
Grazie.
Rob.


Questa e' un'altra storia.
Hai, evidentemente, imposto la relazione di integrita' fra conti e 
istituti. Nella gestione dei conti quando inserisci un nuovo record ti 
devi ricordare di mettere un codice Istituto valido, che sia presente 
gia' presente sulla tabella istituti, altrimenti ottieni il messaggio 
che hai ricevuto
IL filtro sul form si impone cosi'
Sub controllocombo_afterupdate()
	me.filter = controllocombo
	me.filteron = true
end sub
neanceh ti posso dire eventualmente "videochiamami" perche' ho un 
telefono mobile antidiluviano.
--
ac

 ac
Nemmeno io sono maniaco "dell"upgrade" di telefonia mobile, pertanto
lasciamo videochiamare la Marini...! A parte questa battuta scherzosa,
innanzittutto ti ringrazio per l'aiuto anche se non sono ancora riuscito a
metterlo in pratica. Il mio intento era questo, Combobox inserisco
l'istituto X anche se non è già residente in tabella Istituti. Nelle
successive caselle di testo collegate alla tabella Conto andrò ad inserire;
Data operazione, data valuta, codice operazione, descrizione operazione,
assegno numero, movimento dare, movimento avere. Successivamente quando per
esempio farò la ricerca per istituto, movimenti dalla data X alla data Y,
dovrò ottenere tutti i movimenti dell'istituto selezionato dalla data X alla
Y.
In questo mio db originariamente il campo Istituto faceva parte della
tabella Conto. Ho voluto separarlo per creare un'altra tabella relative alle
condizioni bancarie e per non ripetere nuovamente il campo in questione,
pensando di relazionarlo. Però ho la vaga sensazione che sto percorrendo una
strada alquanto tortuosa e magari inutile. Boh
Roberto


Un codice di relazione fra conto e istituto devi pur averlo da qualche 
parte. Hai impostato una relazione di integrita' istituto-->conto, bene 
  quando inserisci un nuovo movimento quel codice di relazione ci "deve" 
essere.
Domanda: Se hai piu' conti sullo stesso istituto cosa fai? Mischi tutto?
Io come utente non sarei felice di cio'.
Ammettendo di aver un migliaio di conti distribuiti su un cemtinaio di 
istituti io metterei 2 cbx 1: Istituti 2: conti (che si popola in 
funzione della scelta su Istituti). Nel momento in cui scelgo il 
conto-istituto (non avviene ma e' sempre possibile che 2 conti su 
istituti diversi abbiano lo stesso numero) impongo il filtro sul form
i.e.
Filter = "campoistituto = '" & cbxistituto & "' and campoconto = '" & 
cbxconto & "'"
Inoltre, personalmente, non sono un tifoso sfegatato degli id e userei 
direttamente i codici di conto e istituto come chiave (questo ti 
potrebbe evitare un po' di query in join) . Lo stesso dicasi per la 
tabella condizioni. Anche questa deve essere legata al conto (ed al tempo).
Tu puoi avere due conti sullo stesso istituto con condizioni diverse.
Tipico esempio per un'azienda e' il cc ordinario ed il cc di anticipo 
fattura i quali generalmente hanno condizioni diverse sopratutto per 
l'aliquota degli interessi passivi.
--
ac

 impongo il filtro sul form i.e.
Filter = "campoistituto = '" & cbxistituto & "' and campoconto = '" &
cbxconto & "'"
Inoltre, personalmente, non sono un tifoso sfegatato degli id e userei
direttamente i codici di conto e istituto come chiave (questo ti potrebbe
evitare un po' di query in join) . Lo stesso dicasi per la tabella
condizioni. Anche questa deve essere legata al conto (ed al tempo). Tu puoi
avere due conti sullo stesso istituto con condizioni diverse. Tipico esempio
per un'azienda e' il cc ordinario ed il cc di anticipo fattura i quali
generalmente hanno condizioni diverse sopratutto per l'aliquota degli
interessi passivi.
ac
Per la poca esperienza a tutt'oggi maturata, solitamente ho sempre usato
l'id come chiave e per quanto riguarda la questione l'ho impostata nel
seguente modo: Tabella Istituti, IdIstituto (contatore) chiave primaria.
Tabella Conto, IdConto (contatore) chiave primaria, IdIstituto (numerico).
La relazione uno a molti è stata fatta da IdIstituto della tabella Istituti
(chiave primaria) a IdIstituto della tabella Conto.
Avendo la necessità di gestire solamente due conti correnti in due diversi
Istituti non mi sono posto molti interrogativi e come dici tu, ho mischiato
tutto. Se hai ancora due minuti da perdere, sono curioso di capire come
lavori ignorando gli id. Dici che useresti i codici di conto ed istituto
come chiave, se non fraintendo sarebbero i numeri di conto corrente e fin
quì tutto bene. Ma fammi capire, non metteresti gli id e per esempio nel mio
caso riportato nelle prime righe di questo scritto, come imposteresti le
relazioni ? faresti a meno del contatore? Sono un pò in tilt!
Grazie.
Roberto

 relazioni ? faresti a meno del contatore? Sono un pò in tilt!
I contatori li puoi usare, sono io che li "aborro". Nel tuo caso 
l'errore viene fuori perche' non valorizzi correttamente 
Conto.IdIstituto, non ci metti l'id dell'istituto in relazione o ce lo 
metti sbagliato (quindi non presente su tabella Istituti).
Per quanto riguarda il non uso dell'id
su Istituti:
Ammettiamo che 1004 (non mi ricordo piu' i codici ABI) sia la BNL
1004 a me diventa chiave primaria, tra l'altro e' un deterrente contro 
codici ABI duplicati.
su Conti:
definisco CodIstituto + NumeroConto come chiave primaria.
In questo NG c'e' una manica di "puristi" che sostengono che cosi' 
allungo gli indici ma io non mi curo di loro guardo e passo (talvolta se 
me ne cale "sbeffeggio" pure).
Spesso mi capita di osservare qualche db (anche non Access), se e' stato 
disegnato da un "accessarolo" lo si riconosce subito. C'e' sempre la 
sagra dell'id e fanno i salti mortali quadrupli con 27 avvitamenti per 
evitare codici duplicati.
--
ac

 ac
Grazie Ale per queste lezioni di Access. Mi sono creato un esempio a parte 
per simulare la questione delle relazioni che non funzionano e ne sono 
venuto a galla. La relazione è corretta, l'errore stava nella query di 
creazione della maschera di inserimento. Nella query non mettevo i relativi 
id delle tabelle, questo era l'errore. Farò tesoro dei consigli ricevuti.
Tnx
Rob.