[C#] Hergebruik eerder gedefinieerde variabele

[Equator]

Ik hoop dat ik dit duidelijk uit kan leggen.

Ik heb in een project een public void gedefinieerd genaamd dbConnect(string strArg).
Deze roep ik dan aan vanuit het project.

code:

dbConnect("OPEN");

Ik maak een SqlConnection (sqlConn) aan en definieer een connectionstring.
Het openen van de database loopt goed.
Nu is de tweede case dus CLOSE.
Als ik daar de eerder gedefinieerde sqlConn wil aanroepen, dan kent hij die niet.
Als ik hem weer opnieuw maak(regel 33), dan krijg ik de melding:
A local variable named 'sqlConn' is already defined in this scope

Een SqlConnection kan je blijkbaar ook niet public maken(mijn idee hierover was dat je een publiek iets ergens anders ook kan gebruiken..), dus ik vraag me even af: Hoe kan ik deze sqlConn verder gebruiken..
Ik heb gegoogled, en kwam ergens tegen dat je de sqlConn eerst moet definieren als null, maar als ik dat eerst doe, en regel 12 commentarieer, dan krijg ik op regel 37 alsnog de melding
Use of unassigned local variable sqlConn


Hier de code.. (Sorry voor de layout.)
Gebruikte variablelen worden uit het register opgehaald, maar heb ik even weggelaten.

C#:

public void dbConnect(string strArg)
        {
            switch (strArg)
            {
                case "OPEN":
                    // Display message on StatusBar
                    this.barMain.Text = "Opening connection to Database on: " + Application.UserAppDataRegistry.GetValue("SERVERNAME").ToString();
                    // Create DB connectstring
                    strConnection = "server=" + dbConnectServerName + "; uid=" + dbConnectSQLuser + "; pwd=" + dbConnectSQLPass + "; database=" + dbConnectDatabaseName + "";

                    // Create Sqlconnection
                    SqlConnection sqlConn = new SqlConnection();
                    sqlConn.ConnectionString = strConnection;

                    // Open the database connection
                    try
                    {
                        sqlConn.Open();
                        this.barMain.Text = "Connection to database " + dbConnectDatabaseName + "on " + dbConnectServerName + "succeeded.";
                    }
                    catch (Exception Ex)
                    {
                        this.barMain.Text = "Error connecting to database: " + Ex.Message;
                    }
                    break;




                case "CLOSE":
                    // display message on statusbar
                    this.barMain.Text = "Closing connection to Database on: " + Application.UserAppDataRegistry.GetValue("SERVERNAME").ToString();
                    //SqlConnection sqlConn = new SqlConnection();
                    // Close the database connection
                    try
                    {
                        sqlConn.Close();
                        this.barMain.Text = "Connection closed.";
                    }
                    catch (Exception Ex)
                    {
                        this.barMain.Text = "Error disconnecting from database: " + Ex.Message;
                    }
                    break;
                default:
                    // return error message 
                    break;
            }
        }

[whoami]

Hum, dit is wel een ranzig stukje code imo....

Waarom maak je geen apart project aan, waarin je een class creeërt die al die database-stuff voor je encapsuleert?
Doordat die class dan in een ander project zit (in een aparte dll dus), kan je diezelfde class(es) die in die dll gedefinieerd zijn, ook in andere projecten gaan hergebruiken.

[ Voor 10% gewijzigd door Creepy op 29-11-2004 12:56 ]

[Creepy]

Je declareert nu los een variabele in de method dbConnect. De volgende keer dat je deze functie uitvoert bestaat deze dus nog niet (en ben je ook de link met de al geopende connectie kwijt).

Waarom declareer je sqlConn niet als property van hetzelfde object waar de method dbConnect in zit?

Edit: wat whoami zegt dus

[ Voor 6% gewijzigd door Creepy op 29-11-2004 12:57 ]

[Equator]

@ whoami: Snap ik.. zo gebruik ik ook een Encryption.dll (via een howto van MS) voor het versleutelen van gegevens.
Maar dat is voor mij van later zorg. NOFI, maar ik wil dit eerst ff doorhebben.

dat het smerige/ranzige code is, begrijp ik. (Still learning)
Maar als ik iets dergelijk in vbscript maak, dan werkt dit prima. Ik weet dat het niet echt te vergelijken is, maar wat ik wil moet toch wel kunnen..

@Creepy:
Je zegt als ik het goed begrijp dat ik een public property sqlConn moet definieren binnen mijn namespace?
Deze definieer ik dan in de methode dbConnect, en kan ik dan vanuit het gehele project bereiken.. Ik ga iig ff proberen..
Does it make any sense

[ Voor 32% gewijzigd door Equator op 29-11-2004 13:06 ]

[whoami]

Het is best logisch dat je je variable die de connectie bevat 'kwijt' bent, je definieert ze namelijk binnen in die Connect Method.
De scope van die variable is dus slechts beperkt tot die connect method; eens je die method verlaat, ben je alle variablen kwijt die je binnen die method gedefinieert hebt.

[Equator]

Ik snap hem helemaal.
Ik heb nu deze code

C#:

SqlConnection sqlConn = new SqlConnection();

in de namespace staan. Deze kan ik dan als het goed is door het gehele project gebruiken..

[whoami]

Dat kan je doen, maar het is immens evil, slecht en bad practice.

* whoami slaat Creepy en gooit 'm heen en weer in de DevSchuur omdat hij zoiets durft te adviseren.
Sure, het is een quick'n dirty fix, maar het is en kan alleen maar voor problemen zorgen.

[ Voor 60% gewijzigd door whoami op 29-11-2004 13:16 ]

[Equator]

Oke, ik loop net tegen nog een probleem aan, dus ik ga even naar jou verhaal luisteren Whoami.
Je zegt dus dat ik een dll zou moeten maken, waarin deze method wordt gemaakt.
Deze geef ik dan als reference aan, en kan ik dan altijd gebruiken..

Kan ik voor deze class de code gebruiken die ik nu al heb, of moet daar veel aan veranderen
* Equator gaat nog wel even op zoek naar een manual voor het maken van dll's

bedankt iig voor de adviezen..

[whoami]

Een dll aanmaken is een piece of cake; gewoon een nieuw class library project starten.

Het moeilijkste is om een goed design te zoeken voor je component.

[EfBe]

<slappe humor>
"My eyes! My EYES!!
</slappe humor>

Ik denk dat je er goed aan doet een goed boek over C# te kopen, bv Programming C# van Jesse Liberty. Bv de "OPEN" en "CLOSE" parameter values die je meegeeft. Waarom geen enum?

[Equator]

* Equator is in het bezit van een beginnersboek voor c#
Maar ach, iemand de raad geven om een boek te kopen is nogal makkelijk in mieijn ogen.
Yep, ik ben geen keiharde programmeur, maar ik is niet gek.

En alle begin is moeilijk, en wat ik wil staat niet in elk boek. Daar heb ik internet voor
En als ik een vraag heb die ik niet kan vinden op google (of niet goed kan omschrijven..) dan kan ik volgens mij hier gewoon vragen.

[whoami]

Wat EfBe probeert te zeggen is dat je toch enkele fundamentele basis-kennis mist (misschien niet direct over C#, maar wel over programmeren en software engineering in 't algemeen), en dat je die best even kan opdoen mits een goed boek (en geen C# for dummies of Teach yourself C#in 24hrs ofzo).

[ Voor 21% gewijzigd door whoami op 29-11-2004 13:58 ]

[Equator]

whoami schreef op maandag 29 november 2004 @ 13:57:
Wat EfBe probeert te zeggen is dat je toch enkele fundamentele basis-kennis mist (misschien niet direct over C#, maar wel over programmeren en software engineering in 't algemeen), en dat je die best even kan opdoen mits een goed boek (en geen C# for dummies of Teach yourself C#in 24hrs ofzo).

Snap ik, en ik ben ook niet boos ofzo..
Mijn boek C# voor beginners van easy computing is ook niet alles. Het o'Reilly boek ASP.net daarintegen weer wel. Maar dat is te specifiek asp.net.

Probleem is echter dat ik heel slecht kan leren uit een boek. Uit de praktijk leer ik veel meer. Door het te doen, en te gebruiken kom ik er sneller achter.
Probleem is inderdaad dat je wel wat fundamentele kennis mist.

Ik heb nu een test .dll gemaakt, en daar slechts hele karige dingen ingedaan.
Een connect methode, en een disconnect methode.
Connecten lukt nu prima. Disconnecten ook.

Wat ik me nog wel afvraag.
In mijn project (Een MDI interface) met enkele MDIchild's.
Moet je voor je MDIchild form's ook apart de dll aanroepen, of kan je gebruik maken van de connectie die het MDIparent heeft gemaakt.

[whoami]

Je moet wel eerst de basis snappen eer je kan gaan experimenteren en uitproberen. Daarvoor moet je dus eerst wel wat theorie en best practices kennen.

Om op je vraag te beantwoorden: daar kan ik niet op antwoorden, aangezien ik niet weet hoe het opgezet is.
Trouwens, als je eens eea leest over databases, ado.net, scalability van DB applicaties etc.. dan zal je zien dat je je connectie het best direct weer sluit als je ze niet meer nodig hebt. (ttz, als je ze voor een onbepaalde tijd niet meer nodig hebt).

[D4Skunk]

Om op de correcte manier een programmeertaal te leren, ben je beter dat je vertrekt vanuit een bestaand programma waarvan je ook de source hebt.
Pas dit aan naar wens, en test het stap voor stap (F11 in visual c# express).

Het is wel aan te raden met eenvoudige programma's te beginnen, waarvan je zeker bent dat ze de juiste methodieken gebruiken.
Een goede bron voor zo'n programma's in c# / .Net is www.codeproject.com. Kijk naar de artikels die het hoogste aantal punten hebben (die zijn zeker goed gestructureerd etc).

[no flame intended]
Verder zou het ook geen kwaad kunnen om eens wat meer te leren over theorie, met name 'hoe software modeleren'.
Veel info kan je trouwens ook terugvinden in de faq van P & W
[/no flame intended]

Veel succes !

[Creepy]

whoami schreef op maandag 29 november 2004 @ 13:15:
Dat kan je doen, maar het is immens evil, slecht en bad practice.

* whoami slaat Creepy en gooit 'm heen en weer in de DevSchuur omdat hij zoiets durft te adviseren.
Sure, het is een quick'n dirty fix, maar het is en kan alleen maar voor problemen zorgen.

* Creepy smijt whoami terug Belgie in . Ik heb het hele woord namespace niet eens gezegd! Ik stelde voor om een class te maken met daarin een method die de connectie maakt m.b.v. een (private) property die de connectie zelf bevat (zoals jij ook al voorstelde .

Dat de TS dit ziet als een "we zetten het in de namespace".. tjah, nee dat is NIET wat ik bedoelde. Dan wordt het een global variabele en die zijn 99 van de 100 keer niet nodig.

[whoami]

Oké,
* whoami aait creepy.

[Creepy]

whoami schreef op maandag 29 november 2004 @ 14:41:
Oké,
* whoami aait creepy.

* Creepy aait whoami.
Ik ben weer eens veel te traag

[curry684]

whoami schreef op maandag 29 november 2004 @ 14:20:
Trouwens, als je eens eea leest over databases, ado.net, scalability van DB applicaties etc.. dan zal je zien dat je je connectie het best direct weer sluit als je ze niet meer nodig hebt. (ttz, als je ze voor een onbepaalde tijd niet meer nodig hebt).

Met daarbij de mental note dat ADO.NET intern een pool van connections aanhoudt waar de verbinding terug in gaat zodra je Close() aanroept, en het dus indien je consequent Close() doet absoluut geen overhead kost maar juist een optimalisatie is om iedere keer opnieuw de connection te moeten Open()en

[whoami]

curry684 schreef op maandag 29 november 2004 @ 15:21:
[...]

Met daarbij de mental note dat ADO.NET intern een pool van connections aanhoudt waar de verbinding terug in gaat zodra je Close() aanroept, en het dus indien je consequent Close() doet absoluut geen overhead kost maar juist een optimalisatie is om iedere keer opnieuw de connection te moeten Open()en

Hmm, dat doet ie enkel als je connection-pooling op de DB aan hebt staan. (Althans, dat kan ie enkel optimaal doen als je ook connection-pooling in je DB aan hebt staan,
ADO.NET zorgt ervoor dat deze default aan staat, en als je 't niet wilt gebruiken moet je dat expliciet opgeven in je connectionstring.

dingen die je moet weten over connection pooling