[VB.NET]: ADODC e NullReferenceException

[newbie]

Tentando di aggiornare un vecchio progetto VB6 in VB.NET con la conversione guidata, ovviamente (e c'era da chiederselo?) non tutto funzionava a dovere... a partire dal controllo ADODC, quello con le frecce per navigare tra i dati, che avevo usato in modo massiccio.

Nel vecchio codice usavo infatti i recordset ADO, ottenuti da un database esistente, che connettevo all'ADODC usando la riga

Adodc1.Recordset = rs

invece di impostare manualmente connessione e comando sottostanti.
Fatto sta che, in esecuzione, questa riga mi genera una fastidiosissima "NullReferenceException - Oggetto non impostato su istanza di oggetto", che non ha molto senso, dato che il recordset esiste e contiene i dati giusti, la proprietà Adodc1.Recordset" non è nulla e quindi esiste anche se chiusa... insomma, non si capisce *quale* sia l'istanza non impostata. L'unico indizio che ho dallo stacktrace dell'eccezione è che l'errore è in una funzione che si chiama "ADODC.UnhookRecordsetEvents"...

Dov'è l'inghippo? Devo per forza riscrivere tutta l'applicazione?

[alka]

Originariamente inviato da newbie
Devo per forza riscrivere tutta l'applicazione?

In genere, effettuando il porting a VB.NET, a meno che non si tratti di un progetto davvero elementare, si devono apportare molte correzioni al codice e nel contempo acquisire padronanza della libreria di classi e dei principi di funzionamento del .NET Framework.

[newbie]

Originariamente inviato da alka
In genere, effettuando il porting a VB.NET, a meno che non si tratti di un progetto davvero elementare, si devono apportare molte correzioni al codice e nel contempo acquisire padronanza della libreria di classi e dei principi di funzionamento del .NET Framework.

In realtà nel mio caso la parte più pesante del porting consiste nel rifare le finestre, le procedure di convalida dei campi, di visualizzazione e così via, perchè la parte di accesso ai dati è relativamente poca. Avevo pensato quindi di partire da una versione dell'applicazione scritta in VB.NET che usasse però ancora il vecchio ADO, in modo che le modifiche fossero circoscritte alla parte di accesso ai dati.

Eppure mi pare comunque strano che una cosa che era normale, come impostare la proprietà Recordset di un controllo ADODC, in VB.NET (usando sempre ADO ) dia problemi del genere... a meno che non sia io che ho sbagliato qualcosa.

[alka]

Per analizzare più a fondo la situazione, il codice che hai riportato è insufficiente.

Si dovrebbe vedere cosa accade prima e dopo, ispezionare il resto del codice, soffermarsi ad esaminare il valore delle variabili in gioco quando si verifica l'eccezione e così via...

[newbie]

La cosa strana è proprio questa: l'errore viene fuori anche se al codice creato automaticamente non aggiungo assolutamente niente. L'unico dubbio è se sia ancora possibile impostare la proprietà Recordset di un controllo ADODC in VB.NET.
In preda alla disperazione, ho addirittura provato a usare un form completamente vuoto, con solo l'ADODC (versione .NET, quella che appare nell'elenco "Aggiungi riferimento... scheda .NET), di cui impostavo solo la proprietà Recordset. Niente da fare.
So solo che nell'InitializeComponent del form vengono impostate le proprietà standard cel controllo... e che il recordset che uso è valido e contiene i dati giusti.
A parte questo, non so che pesci pigliare...

[alka]

Io rinuncerei all'uso di ADODC e lo sostituirei con il ricorso alle classi di ADO.NET.

[newbie]

Originariamente inviato da alka
Io rinuncerei all'uso di ADODC e lo sostituirei con il ricorso alle classi di ADO.NET.

Noooo.... non mi dire così...

Speravo di poter adottare una soluzione più "dolce" e meno drastica...
In pratica, il problema più fastidioso che ho trovato è che l'applicazione precedente era completamente basata su recordset ADO estratti da database, che avevano come comodità immensa il fatto che le modifiche apportate al recordset, tramite ADODC, erano automaticamente fatte anche nel database.
Nel porting che tento di fare, sarò costretto a
[list=1][*]sostituire tutti i recordset con dei DataAdapter[*]rifare a mano tutti i tastini Precedente, Successivo, Primo, Ultimo, e l'etichetta che mostra la posizione corrente, e scrivere il relativo codice (sto pensando a uno UserControl), dato che uso VS.NET 2003 e il BindingNavigator esiste solo nel .NET Framework 2.0 ...[*]nei form, ricavare una DataTable dal DataAdapter (che sarà scollegata dal database, al contrario dei recordset ADO), e fare a mano il binding con i controlli[*]capire se e quando ripercuotere gli aggiornamenti della DataTable sul DataAdapter (e quindi sul database) con il metodo table.Update(adapter)[/list=1]
Tutta roba che in ADO era praticamente automatica

Usando invece ancora ADODC, avrei potuto intanto salvare tutto il codice dei form già pronto, comprese le convalide dei campi (che fanno spesso riferimento al recordset sottostante) e il modulo di gestione dati. Una volta riavuto quel codice funzionante, sarei passato al livello successivo.
Certo sono due passaggi, ma sempre meglio che rifare tutto invece di modificarlo...

[alka]

A questo punto, però, mi chiedo quale senso abbia fare il porting dell'applicazione a VB.NET... :master:

[newbie]

Originariamente inviato da alka
A questo punto, però, mi chiedo quale senso abbia fare il porting dell'applicazione a VB.NET... :master:

Non c'è una sola ragione...
[list=1][*]E' il mio primo progetto "serio", nell'ambito di un esame universitario di Ingegneria del Software (bei vecchi tempi!), ed è completo di tutto: analisi dei requisiti, progettazione, codifica, system test (mi sono convertito all'unit test solo in seguito), e mi dispiacerebbe buttare via tutto quel lavoro, o lasciarne marcire il codice in un formato in via di estinzione...[*]Sarebbe un esempio completo e funzionante di un'applicazione gestionale in VB.NET, capace di interagire con un database esterno, da cui prendere spunto per scopi futuri... perchè copiare è un'arte![*]E' una buona "scusa" per provare a fare un porting, e imparare il VB.NET e le tecnologie correlate, come Crystal Reports, ADO.NET e così via... e dato che esistono aziende che richiedono il VB.NET e io sono ancora a caccia, un'applicazione reale (pouttosto che un "lo so fare..." detto senza un "l'ho già fatto") può essere un biglietto da visita...[/list=1]
A parte questo, mi sa che alla fine rinuncerò... o sarò costretto a installare VB6...

[alka]

Originariamente inviato da newbie
Sarebbe un esempio completo e funzionante di un'applicazione gestionale in VB.NET, capace di interagire con un database esterno, da cui prendere spunto per scopi futuri... perchè copiare è un'arte!

Non direi, visto che di VB.NET non usi praticamente nulla, facendo riferimento a tutti gli oggetti COM/ActiveX che sei abituato ad utilizzare in VB6.

Originariamente inviato da newbie
E' una buona "scusa" per provare a fare un porting, e imparare il VB.NET e le tecnologie correlate, come Crystal Reports, ADO.NET e così via... e dato che esistono aziende che richiedono il VB.NET e io sono ancora a caccia, un'applicazione reale (pouttosto che un "lo so fare..." detto senza un "l'ho già fatto") può essere un biglietto da visita...

E' una buona scusa, ma non ne approfitti in quanto, siccome l'adozione di ADO.NET che hai citato anche tu richiede la riscrittura di parte dell'applicazione, la escludi, rimanendo sugli oggetti adoperati in VB6 (vedi sopra), quindi non è un buon esempio di porting.