Oledbconnection non cambia parametri

martedì 01 maggio 2012 - 20.25

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

Elenco Tags VB.NET | .NET 4.0 | Windows 7 | Visual Studio 2010 | Access (.mdb)

Lucchinet Profilo | Newbie

31 messaggi | Data Invio: mar 1 mag 2012 - 20:25

Ciaoa a tutti.

Mi succede una cosa strana.

In un progetto che sto sviluppando, ho diversi form con al loro interno dei OleDbConnection, che all'inizializzazione del form chiamato modifica la stringa di connessione con una passata da me con il pattern del DB corretta e tutto funziona bene.
Però la cosa strana è che in un form preciso, questo non avviene, l'oledbconnection, modifica i propri parametri ma va a ricercare comunque il vecchio DB.
Anche usando il Debug, vedo che i parametri cambiano, ma niente da fare.

Come posso fare? Non capisco perchè non si comporta come gli altri.

freeteo Profilo | Guru

6.542 messaggi | Data Invio: mar 1 mag 2012 - 22:58

Ciao,
non so se ci sia un motivo specifico per tenere la Connessione dentro alla form, solitamente si fa come spiegato qui:
http://www.dotnethell.it/forum/messages.aspx?ThreadID=40822

Nel tuo caso sarebbe OleDbConnection, ma non cambia niente se noti infatti il ritorno della funzione è "DbConnection" ossia la classe base di questo tipo di oggetto, quindi "intercambiabile".
Potrebbe esserti utile un approccio del genere? secondo me sì, poi chiaramente è da capire come mai hai quel determinato problema in quella form, ma ti volevo suggerire questo approccio a mio avviso migliore per impostare l'applicazione.

Ciao.

Matteo Raumer
[MCAD .net, MVP Visual C#]
http://blogs.dotnethell.it/freeteo

Lucchinet Profilo | Newbie

31 messaggi | Data Invio: mer 2 mag 2012 - 07:58

Ciao,
Ho capito cosa vuoi dire.
Non ho una connessione unica globale, ma ogni form ha una connessione propria.
Per capirci meglio, il progetto ha circa 40 form, quasi tutte connesse a db.
Funzionano tutte bene, tranne una che, solo su computer dove c'è Visual Studio, anche se avviata come applicazione finita (quindi non da VS), si connette anche a DB con nome diverso e in posizione diversa.
Se lo faccio girare su un'altra macchina, non c'è verso, non modifica i propri parametri di connessione.
La cosa strana è che solo quel OleDbConnection di quella form si comporta così, tutti gli altri delle altre form no.
Ho provato a cancellare e sostituire il Connection ma niente.

Idee?

freeteo Profilo | Guru

6.542 messaggi | Data Invio: mer 2 mag 2012 - 09:23

>Idee?
come dicevo nel post che ti ho suggerito, potresti usare una classe dove esporre un metodo statico che ti torna la connessione impostata come vuoi tu, e dentro alle form, usare questo metodo per creare l'oggetto connection da usare.
Così facendo hai un solo punto in cui viene creata la connessione, ed una volta che hai verificato in debug che funziona in un posto, sei sicuro che funziona correttamente anche in tutte le altre form...

Ciao.

Matteo Raumer
[MCAD .net, MVP Visual C#]
http://blogs.dotnethell.it/freeteo

Lucchinet Profilo | Newbie

31 messaggi | Data Invio: mer 2 mag 2012 - 23:56

Grazie per l'aiuto, non ci pensavo.
Ho risolto così, siccome anche creando un Connection da codice con la mia connectionstring e chiudendo il vecchio connection del form , riassegnandogli la nuova connessione e riaprendo la connessione, mi dava lo stesso errore, ho preferito assegnare alle dataadapter che utilizzo il connection creato via codice e tutto funziona bene.
Un po' laborioso se le dataadapter sono molte ma va bene.
Premetto che alcune dataadapter non sono create via codice ma presenti nel form (nella barra degli oggetti sotto la finestra del form).
Se hai suggerimenti migliori, attendo.
Grazie e ciao.

freeteo Profilo | Guru

6.542 messaggi | Data Invio: gio 3 mag 2012 - 23:15

Ciao,
premetto che quello che hai fatto non è sbagliato, ma solitamente il mio approccio è diverso.
Mi pare di capire che usi dataadapter quindi presumo anche dataset o datatable per farti tornare i dati dal database, anche se è funzionante tranquillamente è un approccio un po' "datato" a livello di architettura applicativa.
Questo perchè ti leghi ad una specifica struttura molto "orientata" alla connessione con il database, poi il fatto che ce l'hai come variabile sotto alla Form ancora peggio, perchè leghi lo strato UI (Interfaccia utente) con quello che riguarda l'accesso ai dati, e se domani ti dovessi trovare nella situazione di cambiare l'accesso ai dati (incece di un db, usare un file di testo, o un xml etc...) saresti costretto a toccare il codice delle form, che di fatto non dovrebbero sapere che ti stai attaccando ad un db.
E tutto questo è sicuramente aiutato dal fatto che Visual Studio ti crea questi oggetti a livello di designer, per facilitarti la vita.

L'approccio a mio avviso più corretto è quello di avere uno strato applicativo (quindi di fatto un progetto dentro alla soluzione) per i singoli layer applicativi, quindi un'organizzazione:
1) Entita => comune a tutti gli altri layer: definisco gli oggetti che fanno parte del mio progetto, ad esempio una classe "Utente" con le sue proprietà, una classe "Ordine" una classe "Cliente etc...tutto quello che fa parte del dominio dell'applicazione

2) Strato dati (DAL) => qui dentro scrivi le classi che vanno a popolare List<Utente>, List<Cliente> etc... dove viene fatta la connessione, la lettura dei dati, e il popolamento appunto di queste Collection che poi vengono usate nel progetto.
Se dovesse cambiare il db, sia come connessione o proprio come "tipologia" (ti dicevo appunto un file xml etc...) cambi questa libreria ed il resto del programma rimane invariato.

3) Strato Business (BOL) => qui dentro hai tutte le logiche applicative, implementate da delle classi che vengono chiamate dalla UI e usano i provider (li creano, li distruggono, tengono delle cose in cache etc...).
Ad esempio qui dentro puoi decidere che quando si salva un utente, venga controllato che abbia un'email associata, oppure venga salvato qualcosa da qualche altra parte etc...insomma qui passano i dati in lettura/scrittura, e vengono validati.
Poi questo strato che referenzia lo strato DAL, si arrangia a fare le chiamate a quelle classi.

4) UI => qui le form, i controlli etc... tutto quello che rigurda l'aspetto dell'applicazione, con cui l'utente interagisce.
Se ad esempio ti chiedessero di portare sul web alcuni funzionamenti di un'applicazione Win32, senza problemi puoi referenziare i progetti dei layer che hai fatto, e poi cambiare solo questa parte di visualizzazione, usando i controlli di asp.net.

Io quasi sempre anche per i progetti semplici approccio lo sviluppo così, in modo se vogliamo più frammentato ma sicuramente più pluggabile e soprattutto più riciclabile tra i vari progetti

Chiaramente il mio è uno spunto, ma nella programmazione OO (Object Oriented) è praticamente sempre così, anzi spesso ci sono ancora più strati.

Ciao.

Matteo Raumer
[MCAD .net, MVP Visual C#]
http://blogs.dotnethell.it/freeteo

Torna su

Stanze Forum

Elenco Threads

Partecipa anche tu! Registrati!

Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !