Newsgroup: it.comp.lang.visual-basic
Titolo: agenda visualbasic , funge ma senza duplicati

Salve ho realizzato una agenda co VB6 basato su foglio access , tutto funge,
ma il problema è che quando immetto nomi duplicati mi da errore di run time
e si chiude l'appliocazione.
Ho cercato di modificare il foglio di access , il campo "nome" è impostato
come chiave primaria , con proprietà  non ammette duplicati, l'ho
modificata, ma poichè è chiave primaria access non me lo fa fare, ho
spostato come chiave primaria il campo ID contatore, ma poi l'agenda non
funziona.
Come fare?
L'agenda in questione l'ho realizzata seguendo questo tutorial:
http://programmazione.html.it/visualbasic/visualbasic_18.htm
mentre l'agenda è questa:
http://programmazione.html.it/visualbasic/Lezione23.zip
Grazie mille

 duplicati
Per un'agenda semplice come quella, mi sembra corretto, ovvero ritengo
giusto che la chiave primaria e univoca sia impostata sul Nome, da
intendersi come Nome+Cognome (vista la struttura del database che non
prevede due campi distinti per Nome e Cognome).
Fermo restando che non è certo l'unica soluzione possibile e tenuto conto
del tuo fallito tentativo di impostare la chiave primaria e univoca sull'ID
(certamente univoco), c'è solo da pensare che il programma preveda nella sua
logica una ricerca per campo Nome univoco e non consenta, per esempio, di
esporre un elenco in caso di omonimie per tale campo. Ominimia, infatti,
assolutamente vietata.
A questo punto credo che che debba essere tu a risolvere eventuali (pur
possibili) omonimie del campo Nome, Rossi Mario e Rossi Mario - Milano

Aggiungo, che l'ho modificato un po il programma, inquanto ho aggiunto anche
un campo cognome, lostesso vale a dire per il data base, e quindi cosa mi
consigli per risolvere il problema delle omonimie?
Grazie1000

 wrote in message
news:dpWCb.90825$AX1.3...@news1.tin.it...

Confermo quanto detto da Lupo: una chiave che non sia nome+cognome non ha
senso (non serve a niente).
Se ci sono 2 Mario Rossi sei *tu* utente che devi differenziarli, magari
puoi rendere la chiave univoca Nome+Cognome+SegniParticolari, in modo che
comunque quando l'utente ha la lista *deve* poter capire chi sono i due a
colpo d'occhio.
Immagina di avere la lista
ID     NOME     COGNOME    TELEFONO
123    Mario    Rossi      1234-567890
321    Mario    Rossi      4321-987654
Spiegami come può l'utente capire a chi deve telefornare dal solo ID :)
Ciao
--
Math Parser : 
http://www.neodatatype.net
Sito Comune : 
http://www.it-lang-vb.net

siccome io ho anche aggiunto oltre al campo  nome e cognome, il campo citta,
è piu facile trovare 2 o piu persone che sono dello stess paese, ad esempio
2 di di milano ecc.

 wrote in message
news:ZSYCb.91464$AX1.3...@news1.tin.it...

Evidentemente la città nella chiave non è adatta.


[*Nico* = 
gi...@li.it
 in news:dpWCb.90825$
AX1.3...@news1.tin.it
] ha
scritto:

Avere un unico campo Nome (chiave primaria e univoca) contenente Rossi Mario
o due campi Cognome e Nome (entrambi in chiave primaria e univoca)
contenenti Rossi e Mario è praticamente la stessa cosa e non risolve il
problema delle omonimie.
Quello che devi fare, volendo ammettere (come dovrebbe essere) le omonimie,
è elencare (se più d'uno) tutti quelli che corrispondono a nome e cognome
(unico campo o due campi è indifferente), ovviamente accompagnando con altri
elementi che aiutino l'operatore a scegliere manualmente.
L'eventuale idea di mettere in chiave (per rendere il tutto veramente
univoco) anche il numero di telefono (completo di internazionale e prefisso)
non sarebbe evidentemente buona, perchè costringerebbe l'operatore a
conoscere proprio quello che cerca: il numero di telefono.