Newsgroup: it.comp.lang.visual-basic
Titolo: Perchè l'oggetto ADODC non funziona in scrittura?

Ciao a tutti,
ho realizzato una form dove ho inserito un oggetto ADODC (Microsoft ADO Data
Control 6.0).
Poi ho inserito una serie di oggetti TextBox ai quali ho impostato alla
proprietą DataSource il ADODC1 e nella proprietą DataField il valore di un
campo.
Finchč visualizzo e scorro tutti i record nessun problema, ma quando
all'interno di un TextBox modifico qualcosa mi dice:
"Informazioni sulla colonna chiave insufficienti o errate, Troppe righe
interessate dall'aggiornamento".
Dove sbaglio? Ho dimenticato di impostare qualche proprietą?
Ringrazio tutti in anticipo.
Ciao
Emiliano

 Emiliano
ciaociao

 righe interessate dall'aggiornamento".
Questo, occorre ammettere, non può dar la colpa all'oggetto data (ma il club
dei masochisti lo fondiamo o no?!), bensì a una tabella senza un indice con
chiave univoca...


Non ho impostato nessuna query, il codice del programma è praticamente vuoto
(Non c'è codice da nessuna parte!), mi sono limitato a inserire il Microsoft
ADO Data
Control 6.0 nella form ed impostare le proprietà DATASOURCE e DATAFIELD dei
vari TEXTBOX.
Tutti i dati del file MDB vengono visualizzati correttamente ma mente alcuni
campi riesco modificarli senza problemi altri mi danno l'errore:
"Informazioni sulla colonna chiave insufficienti o errate, Troppe righe
interessate dall'aggiornamento".
che non appare sempre ma comunque nel 90% dei casi.
Ciao
Emiliano

 DATAFIELD dei vari TEXTBOX.
allora vedi post di Lupo
ciaociao


Ciao Lupo,
scusami ma probabilmente la mia inesperienza mi fa fare errori banali.
Potresti essere piů chiaro?
Il file MDB ha una sola tabella con un campo ID con Tipo dati contatore e a
fianco c'č il disegno della chiave, e poi tutta una serie di campi alcuni
dei quali obbligatori (almeno in access) e altri no.
Cosa c'č nella mia tabella che non va?
Grazie.
Emiliano

Ho tolto la chiave al database e adesso sembra funzionare bene.
Che sia stata quella?
Ciao
Emiliano

 Che sia stata quella?
Mi scappa da ridere! Senza offesa per te.
Io sostengo (e così faccio) che ogni tabella di qualsiasi tipo di database
debba avere almeno un indice con chiave univoca. SQL Server lo pretende,
salvo restituirti (lato Server e Static) recordset non modificabili. Se quel
simbolo di chiave (mostrato da chi, Ms Access?...) vuol dire che quel campo
è campo di un indice, beh, lo lascerei e, anzi, lo verificherei con
qualcos'altro...
Il fatto che ti funzioni dopo aver tolto la chiave, mi fa pensare che
dipenda solo dai dati che hai inserito/modificato, e dalle combinazioni che
gli stessi generano. Non canterei vittoria, anche perchè è del tutto
illogico. Fermo restando che a un controllo Data non affiderei nemmeno il
mio borsellino vuoto.

 mio borsellino vuoto.
Quindi cosa utilizzeresti?
Ciao e grazie.
Emiliano

 Quindi cosa utilizzeresti?
Beh, Emiliano, mi par di poter dire che frequenti il NG... Davvero non lo
sai?
Tutto, per esempio solo codice, tutto meno che i controlli Data-Eccetera...
Li considero dei virus e considero delinquenti (in subordine, visto che
nessuna legge potrebbe considerarli tali, bevitori sin dall'alba) coloro che
li hanno scritti, seriamente.

 li hanno scritti, seriamente.
Effettivamente dopo che ho scoperto come fare sono d'accordo con te...
E' sicuramente più elaborioso come scrittura del codice, ma sicuramente si
ha maggior controllo su tutto.
Ciao e grazie mille per l'aiuto.
-- 
Emiliano - Webmaster di EmiCAD® - Tutto per AutoCAD e ProgeSOFT® IntelliCAD
e-mail:  
webm...@emicad.it
web:  
www.emicad.it