Newsgroup: it.comp.lang.visual-basic
Titolo: Problema con ADO

Salve a tutti, ho un problema con la cancellazione di record usando ADO.
Allora, mi connetto ad un database di file (dbf) con ODBC, l'aggiunta di
record funziona:
        Recset.AddNew
        Recset.Fields("COD_ART") = 9
        Recset.Update
        Recset.UpdateBatch (adAffectCurrent)
I problemi sorgono quando devo cancellare record aggiunti uguali... cioč se
aggiungo 4 record uguali (con il codice sopra) quando seleziono tramite
datagrid il record da eliminare mi da il seguente errore:
    Errore di run-time '-
2147467259
 (80004005)'
    Informazioni sulla colonna chiave insufficienti o errate.
    Troppe righe interessate dall'aggiornamento
Il fatto č che se non cancello i record "uguali" ma altri, funziona!
Come posso correggere l'errore? Il codice di cancellazione che uso č:
        Recset.Delete
        Recset.Update
        Recset.UpdateBatch (adAffectCurrent)
Poi come posso fare per modificare i dati? Non trovo l'opzione "edit" come
c'era in DAO.
Grazie, ciao.

 come c'era in DAO.
ADO pone in Edit un record solo per il fatto di modificarne un campo, anche
se con contenuto identico.
Per questo il metodo Edit non esiste più in ADO. E, attenzione, spostandosi
su altro record, quello precedende posto implicitamente in Edit viene
automaticamente aggornato, a meno di non esplicitare un .CancelUpdate prima
dello spostamento.


Bene, allora è quello, ma adesso mi dovresti dire come fare un indice, cioè
è sufficiente fare "ORDER BY" sulla query di apertura del recordset? O
altro?
Cmq per la modifica uso: recset.fields("CAMPO") = "Dato"
poi update.
Grazie della risposta.

 del recordset? O altro?
Altro. Devi aggiungerlo alla struttura della tabella con lo stesso strumento
che hai usato per creare il database, le tabelle e i campi. Se hai fatto
tutto da codice, hai già tutte le nozioni per creare anche l'indice...
Ogni tabella (IMHO) di qualunque database deve avere almeno un indice con
chiave univoca. Se non hai campi che (combinati) garantiscano una chiave
univoca, prevedi un campo autoincrementante e usa quello per l'indice.


Ok, quindi con database dbf creo un indice col dbu e lo aggancio all'odbc..
Cmq forse è meglio un campo autoincrementante, almeno non sbaglio. Però con
un campo autoincrementante non ci sono limiti di record con il tipo di dati?
cioè vabbè che più di 1.000.000 di record non ci saranno mai, ma purtroppo
se cancello record non posso sostituire il progressivo con quello
cancellato, ma continua in sequenza dall'ultimo + 1. Per grandi database non
è un problema??
Grazie di tutto.

 sequenza dall'ultimo + 1. Per grandi database non è un problema??
Senti un po': chettifrega? L'autoincrementante prima non l'avevi ora lo vuoi
"governare"...
No, non non puoi agire sullo stesso, comunque, se ne potevi fare a meno
prima, ora puoi anche accettare che lasci dei buchi, no?!. Usalo per
l'indice e basta.

 Per grandi database non č un problema??
Se hai un database che (compresi gli annullati) raggiunge 2 miliardi e rotti
di records (sempre che la dimensione fisica del file li sopporti), prevedi
un campo tuo (numero o stringa) da assegnare/gestire a tuo piacimento.

Effettivamente con una stringa si possono catalogare tutti gli abitanti
della terra ancora un po' :-) Comunque ho provato anche ad evitare di
assegnare il campo, ma non ci sono riuscito, neanche ad usare la posizione
assoluta (recset.absoluteposition) per fargli capire qual è la riga da
cancellare... niente da fare, faccio il campo.. (sempre se non hai la
soluzione per l'absoluteposition in fase di cancellazione :-) )
Grazie 1000

[Ste = 
circa_NOSP...@tin.it
 in zfblc.132595$
hc5.5...@news3.tin.it
]
ha scritto:

Il motore ha bisogno di sapere quale sia il record da cancellare, con
esattezza e con i soli dati relativi al record corrente (e alla struttura
della tabella, leggi indice), sia esso in testa o in coda. AbsolutePosition
non c'entra nulla.

 non c'entra nulla.
Ok, perfetto, ho già fatto il campo dedicato nel database che mi serve, poi
ho riflettuto... nei clienti non mi serve xkè il codice è univoco :-) Così
come in tante altre situazioni, dal magazzino ai ddt alle fatture... Mi
facevo problemi inutili.
Però ho notato una cosa un po' "strana", cioè non capisco come mai è mooolto
più lento ADO con ODBC rispetto a DAO con data1... cioè non dovrebbe essere
un sistema più moderno e veloce? Vabbè, non mi interessa la velocità, però
mi sembra strano. (la velocità bassa l'ho notata nel fare il campo con
numeri consecutivi con un archivio dbf da 10000 record, ha impiegato un
casino, mentre con dao è velocissimo, il codice era un semplice ciclo...)
Forse con SQL l'odbc è + veloce? Vabbè, illuminami x l'ennesima volta :-)
Grazie di tutto!

[Ste = 
circa_NOSP...@tin.it
 in dMdlc.182234$
rM4.7...@news4.tin.it
]
ha scritto:

ADO è molto più lento di DAO, specialmente con database di tipo Access.
ADO è una nuova tecnologia che ha lo scopo principale di potersi collegare a
più tipi di database.
DAO è una vecchia tecnologia fatta su misura per database di tipo Access,
anche se può collegarsi ad altro.
Questo è quanto la mamma e tanti altri dicono. Io ho la mia opinione...

 Questo è quanto la mamma e tanti altri dicono. Io ho la mia opinione...
Ok, però conviene usare ADO visto che DAO non è più supportato, credo. Ora
avrei un problema di "gestione degli archivi" Cioè siccome devo lavorare con
+ anni (5 - 6) con ODBC devo creare tante connessioni quanti sono gli anni
(visto che gli archivi stanno in directori diverse "archivi\2004
archivi\2003 ecc..." , solo che ancora non ho capito come farle da codice,
ora guardo se ho problemi spero di contare sul tuo aiuto. Grazie.
P.S. Però con Data1 questi problemi non c'erano :-) Ciao.

 P.S. Però con Data1 questi problemi non c'erano :-) Ciao.
Ma ce n'erano degli altri... Evita, se puoi, di usare gli oggetti Data...

 DAO.
Si con oggetti ADO e DAO non cambia, ma con ODBC devo fate tante connessioni
quanti sono gli anni, poi gestire il tutto con variabili che assumono il
nome della connessione in base all'anno.
Grazie, Ste.