[Linq / C#] SubmitChanges() werkt niet

[jvaneijk]

Hoi allemaal,

Het volgende is het probleem. Ik heb een windows applicatie welke informatie haalt uit een database en mogelijk ook terug stopt mits SubmitChanges werkt.

Ik heb textboxen in een form welke ik vul, op het moment dat ik de knop opslaan indruk moet hij een insert doen op de database.

Informatie uit de database halen is geen probleem dat werkt perfect. De code die ik heb in staan in de button_click is de volgende:

C#:

private void button1_Click(object sender, EventArgs e)
        {
            try
            {
                GroenDataContext db = new GroenDataContext();
                Klant k = new Klant();
                //k.klantID = textBoxKlantnummer.Text;
                k.aanhef = textBoxAanhef.Text;
                k.voornaam = textBoxVoornaam.Text;
                k.achternaam = textBoxAchternaam.Text;
                k.bedrijfsnaam = textBoxBedrijfsnaam.Text;
                k.adres = textBoxAdres.Text;
                k.huisnummer = Convert.ToInt16(textBoxHuisnummer.Text);
                k.toevoeging = textBoxToevoeging.Text;
                k.postcode = textBoxPostcode.Text;
                k.plaats = textBoxPlaats.Text;
                k.email = textBoxEmail.Text;
                k.telefoonnummer = textBoxTelefoon.Text;
                k.mobielnummer = textBoxMobiel.Text;
                k.faxnummer = textBoxFax.Text;
                k.rekeningnummer = textBoxRekeningnummer.Text;
                k.aanmelddatum = dateTimePickerAanmelddatum.Value;
                k.geboortedatum = dateTimePickerGeboortedatum.Value;

                db.Klants.InsertOnSubmit(k);
                db.SubmitChanges();
            }
            catch (ChangeConflictException ex)
            {
                Console.WriteLine(ex.Message);
                
                //aanpasingen maken
                //db.SubmitChanges();
            }

        }

deze code zou gewoon moeten werken. Er komt geen error omhoog ook als ik debug en door mijn methode heen loop is alles netjes gevuld. Echter als ik via management studio in de database kijk dan is de klant er niet bijgekomen. Sluit ik mijn applicatie af en start ik hem opnieuw op dan staat de klant die ik zojuist heb toegevoegd wel netjes in mijn listbox, echter nog steeds niet in mijn applicatie. Volgens mij doe ik alle stappen goed. Heb ook nog even deze link bekeken en doe precies zelfde als scott doet.

Hoop dat iemand mij opheldering kan geven in mijn probleem.

[Sebazzz]

Ik vrees dat we hier in de code nogal wat relevante code missen. Wat doet SubmitChanges bijvoorbeeld? Zit in die methode een rare try/catch waardoor deze niets toevoegt of vergeet is daarin een call te doen?

[jvaneijk]

Sebazzz schreef op maandag 23 maart 2009 @ 18:29:
Ik vrees dat we hier in de code nogal wat relevante code missen. Wat doet SubmitChanges bijvoorbeeld? Zit in die methode een rare try/catch waardoor deze niets toevoegt of vergeet is daarin een call te doen?

Ik denk niet dat je relevante code mist. SubmitChanges is onderdeel van DataContext (Linq)

[Vincenz0]

Hmm klinkt bekent, heb een vergelijkbaar probleem gehad.
Wat mijn fout was dat ik geen auto increment primary key in de database tabel had.

zodra ik die er in had gezet en de tabel opnieuw aan linq toevoegde werkte het perfect.

[jvaneijk]

Vincenz0 schreef op maandag 23 maart 2009 @ 20:50:
Hmm klinkt bekent, heb een vergelijkbaar probleem gehad.
Wat mijn fout was dat ik geen auto increment primary key in de database tabel had.

zodra ik die er in had gezet en de tabel opnieuw aan linq toevoegde werkte het perfect.

Hmm klinkt wel mogelijk. Zal eens kijken. Wat ik dan trouwens wel vreemd vindt. Stel mijn primary key is dus niet auto increment maar hij is wel verplicht. Als ik hem dan niet invul dan zou je toch een melding moeten krijgen van nullable bla bla bla???

[Vincenz0]

jvaneijk schreef op maandag 23 maart 2009 @ 20:52:
[...]


Hmm klinkt wel mogelijk. Zal eens kijken. Wat ik dan trouwens wel vreemd vindt. Stel mijn primary key is dus niet auto increment maar hij is wel verplicht. Als ik hem dan niet invul dan zou je toch een melding moeten krijgen van nullable bla bla bla???

Dat klopt, Ik kreeg gewoon helemaal geen error/exception, toen ik in de debugger er door heen stepte zag ik duidelijk dat alle vars goed gezet werden in memory, maar bij de SubmitChanges() heeft ie niks gecommit naar de database...

Linq is nieuw/buggy denk ik.

[jvaneijk]

Vincenz0 schreef op maandag 23 maart 2009 @ 21:05:
[...]


dat klopt, iig kreeg ik gewoon helemaal geen error of iets, toen ik in de debugger er door heen stepte zag ik duidelijk dat alle vars goed gezet werden in memory, maar bij de SubmitChanges() heeft ie niks gecommit naar de database...

Linq is nieuw/buggy denk ik.

Nog even CSI kijken en dan even snel een testje doen met losse DB. en losse app

[Snake]

Kijk eens in je debugger window. Daar zou iets moeten verschijnen. Eventueel kan je er ook een try catch rondzetten, die Exception catched, en dan eens kijken naar de stack.

Even een lijst van digen die je kan checken

• Is id auto increment
• Is id primary key
• Zijn je values uit de textboxen correct?
• Probeer eens een minimale insert, that is alleen de variablen die een not null status hebben in de database.

[ Voor 43% gewijzigd door Snake op 23-03-2009 23:53 ]

[gorgi_19]

Heb je ook al gekeken met Profiler en wat hij als Insert Statement wil geven?

[jvaneijk]

gorgi_19 schreef op dinsdag 24 maart 2009 @ 07:44:
Heb je ook al gekeken met Profiler en wat hij als Insert Statement wil geven?

Ik heb nog niet met de profiler gekeken probleem is een beetje. Ik gebruik een database file en geen SQL server DB. Mijn test die ik gisteravond heb gedaan maakt wel gebruik van SQL server. Deze werkt wel. Dus ik denk dat ik mijn MDF maar even in de SQL server gooi om zo de profiler te kunnen gebruiken.

[Verwijderd]

Snake schreef op maandag 23 maart 2009 @ 21:11:
Kijk eens in je debugger window. Daar zou iets moeten verschijnen. Eventueel kan je er ook een try catch rondzetten, die Exception catched, en dan eens kijken naar de stack.

Even een lijst van digen die je kan checken

• Is id auto increment
• Is id primary key
• Zijn je values uit de textboxen correct?
• Probeer eens een minimale insert, that is alleen de variablen die een not null status hebben in de database.

Bedoel je niet toevallig het output window? Wanneer je hier iets van "First-change exception occurred bla bla bla" ziet staan wordt er ergens een exception gethrowed die waarschijnlijk weer gecatched wordt aangezien deze niet in je debugger verschijnt.

Wat je ook nog kan checken (zeker als bovenstaande regel in je output window verschijnt) is wanneer je Visual Studio gebruikt (weet niet of het in alle versies is) dan kun je in het menu Debug -> Exceptions een vinkje zetten in de "Thrown" kolom voor CLR Exceptions. Dan breakt je debugger al op het moment dat de exception wordt gethrowed ipv wanneer de exception niet gehandled wordt.

[Niemand_Anders]

De DataContext heeft een Log property waaraan je een TextWriter kunt koppelen. Alle queries welke linq dan uitvoert worden dan gelogged. Eventuele problemen met de query zie je dan ook terug.

C#:

GroenDataContext db = new GroenDataContext(); 
db.Log = new StreamWriter(@"c:\temp\GroenDataContext.log");

Voorbeeld output uit MSDN:

SELECT [t0].[CustomerID], [t0].[CompanyName], [t0].[ContactName], [t0].[ContactTitle], [t0].[Address], [t0].[City], [t0].[Region], [t0].[PostalCode], [t0].[Country], [t0].[Phone], [t0].[Fax]
FROM [dbo].[Customers] AS [t0]
WHERE [t0].[City] = @p0

-- @p0: Input String (Size = 6; Prec = 0; Scale = 0) [London]

-- Context: SqlProvider(Sql2005) Model: AttributedMetaModel Build: 3.5.20810.0

AROUT
BSBEV
CONSH
EASTC
NORTS
SEVES

[jvaneijk]

Niemand_Anders schreef op dinsdag 24 maart 2009 @ 11:14:
De DataContext heeft een Log property waaraan je een TextWriter kunt koppelen. Alle queries welke linq dan uitvoert worden dan gelogged. Eventuele problemen met de query zie je dan ook terug.

C#:

GroenDataContext db = new GroenDataContext(); 
db.Log = new StreamWriter(@"c:\temp\GroenDataContext.log");

Voorbeeld output uit MSDN:

SELECT \[t0].\[CustomerID], \[t0].\[CompanyName], \[t0].\[ContactName], \[t0].\[ContactTitle], \[t0].\[Address], \[t0].\[City], \[t0].\[Region], \[t0].\[PostalCode], \[t0].\[Country], \[t0].\[Phone], \[t0].\[Fax]
FROM \[dbo].\[Customers] AS \[t0]
WHERE \[t0].\[City] = @p0

-- @p0: Input String (Size = 6; Prec = 0; Scale = 0) \[London]

-- Context: SqlProvider(Sql2005) Model: AttributedMetaModel Build: 3.5.20810.0

AROUT
BSBEV
CONSH
EASTC
NORTS
SEVES

Nice dat van die log wist ik niet.. Dat is perfect voor testen als je geen gebruik kunt maken van SQL profiler. Moet hem wel uit zetten tijdens een release build neem ik aan want het zou de performance niet echt ten goede komen?

Maar voor debug is het perfect.

[Vincenz0]

jvaneijk schreef op dinsdag 24 maart 2009 @ 11:42:
[...]


Nice dat van die log wist ik niet.. Dat is perfect voor testen als je geen gebruik kunt maken van SQL profiler. Moet hem wel uit zetten tijdens een release build neem ik aan want het zou de performance niet echt ten goede komen?

Maar voor debug is het perfect.

C#:

#if debug

// Do stuff

#endif

[Niemand_Anders]

Ja, uitzetten is wel verstandig voor release builds. Maar zelf maak ik standaard niet gebruik van de log. Daarom koppel ik de logger ook aan de context instance en zet ik hem niet standaard in de constructor (van GroenDataContext).

Ik maak bijna niet gebruik van Linq To Sql omdat zowel de DataContext als Table geen events kennen (en daarmee geen mogelijk tot ingrijpen bij bepaalde processen). Echter bij de projectjes waarbij we hem wel gebruiken gebruiken we de DataContext zoals we een IDbConnection gebruiken, namelijk kort. Ofwel je creëert een DataContext instance, voert een statement uit en vervolgens sluit je de context. Als je dan aan de instance je logger koppelt is de logging output beperkt tot je probleem.

Omdat o/r mappers meestal niet de meest efficiëntste queries weten te genereren, maken wij dus ook bijna niet gebruik van dat soort tools. LLBLGen genereert wel de beste queries, maar de handmatig geschreven queries (vooral de complexere) wisten wij toch nog tot 5% performance winst te pakken. Grappig is soms wel te zien dat developers LLBLGen gebruiken als query template en hem vervolgens af 'tunen'.

Wel maken wij gebruik van iBatis zodat we niet elke keer handmatig de database resultaten handmatig naar objecten hoeven te mappen. Een extra frontend machine kost alleen een windows licentie. Het plaatsen van een extra database node kost een veelvoud vanwege de zeer dure sql enterprice licenties.

[Gerrit88]

Is de database die je gebruikt een local database? Dan denk ik namelijk dat je in een tijdelijke database schrijft. Als bij het compileren de versie in de projectmap nieuwer is dan in de debug map wordt ie overschreven en heb je weer een lege database...