[VB.NET] SQL integratie - hoe te werk te gaan

[der_roedie]

Hallo,

ik ben bezig met het maken van een programma in VB.NET voor mijn werk.
Dit programma haalt en slaat gegevens op in een SQL-database.

Het ophalen en wijzigen van data is op zich niet mijn probleem, dit gaat op zich allemaal goed.
Echter wat ik nu doe zijn de volgende stappen:

- Gebruiker voert handeling uit
- Handeling resulteert erin dat er 3 tabellen moeten worden beschreven vanuit de applicatie.
- Tabel 1 wordt gewijzigd via SQL commando
- Tabel 2 wordt gewijzigd via SQL commando
- Hetzelfde geldt voor tabel 3

Nou weet ik niet goed hoe ik e.e.a. moet programmeren om ervoor te zorgen dat in geval van een fout bij 1 van de stappen, de andere stappen worden teruggedraaid in SQL.

Hoe kan ik voor zoiets het beste te werk gaan?

[oldsmelly]

Meest voor de hand liggend is dit te doen in een Stored Procedure.
Daarin kun je ten alle tijden een roll Back doen op alle tabellen die je hebt ge-update.

[ Voor 14% gewijzigd door oldsmelly op 30-12-2015 08:46 ]

[Marber]

Term die je zoekt is transaction logging. zie MSDN: BEGIN TRANSACTION (Transact-SQL)

[RobIII]

oldsmelly schreef op woensdag 30 december 2015 @ 08:43:
Meest voor de hand liggend is dit te doen in een Stored Procedure.
Daarin kun je ten alle tijden een roll Back doen op alle tabellen die je hebt ge-update.

Een stored procedure heeft er niets mee te maken. Je moet een transactie hebben.

[Marber]

RobIII schreef op woensdag 30 december 2015 @ 08:55:
[...]

Een stores procedure heeft er niets mee te maken. Je moet een transactie hebben.

Al helpt het wel om in complexere transacties Stored Procedures te gebruiken. Maar vooral vanuit het beheersbaarheidoogpunt

[oldsmelly]

RobIII schreef op woensdag 30 december 2015 @ 08:55:
[...]

Een stored procedure heeft er niets mee te maken. Je moet een transactie hebben.

Sorry hoor maar ik was er even vanuit gegaan dat dit wel voor de hand zou liggen !
BTW er stond ook "Je kan een Rollback doen"

[ Voor 7% gewijzigd door oldsmelly op 30-12-2015 09:00 ]

[RobIII]

Marber schreef op woensdag 30 december 2015 @ 08:57:
[...]

Al helpt het wel om in complexere transacties Stored Procedures te gebruiken. Maar vooral vanuit het beheersbaarheidoogpunt

Daar zijn de meningen over verdeeld; het hangt er maar net van af waar je je logica onderbrengt en dat kan prima in een SP maar ook best in je code.

oldsmelly schreef op woensdag 30 december 2015 @ 08:59:
Sorry hoor maar ik was er even vanuit gegaan dat dit wel voor de hand zou liggen !

Huh? TS vraagt duidelijk naar een oplossing waar transacties voor bedoeld zijn en jij komt op de proppen met iets dat er totaal geen moer mee te maken heeft (maar waarin je ook een transactie kunt gebruiken). At best help je TS ermee de verkeerde richting in.

oldsmelly schreef op woensdag 30 december 2015 @ 08:59:
BTW er stond ook "Je kan een Rollback doen"

Op een transactie ja, niet op een SP.

[ Voor 46% gewijzigd door RobIII op 30-12-2015 09:01 ]

[oldsmelly]

RobIII schreef op woensdag 30 december 2015 @ 08:59:
[...]

Huh? TS vraagt duidelijk naar een oplossing waar transacties voor bedoeld zijn en jij komt op de proppen met iets dat er totaal geen moer mee te maken heeft (maar waarin je ook een transactie kunt gebruiken). At best help je TS ermee de verkeerde richting in.

[...]

Op een transactie ja, niet op een SP.

Geen ene moer? verkeerd been uit bed gestapt ?

Als de TS een beetje eigen initiatief toont . wat hier op Tweakers wordt gepredikt, dan snapt de TS zelf ook wel dat een Rollback niet op de SP slaat op maar op transacties...

[RobIII]

oldsmelly schreef op woensdag 30 december 2015 @ 09:07:
Geen ene moer?

Nee, geen ene moer nee. Een SP heeft vierkant werkelijk waar geen ene drol te maken met een transactie noch rollback daarvan. Dat je een transactie in een SP kunt gebruiken (en dat een SP vaak, impliciet, in een transactionele context draait) is iets anders.

oldsmelly schreef op woensdag 30 december 2015 @ 09:07:
verkeerd been uit bed gestapt ?

Nee hoor Maar klaarblijkelijk wel wakkerder dan jij
Als je nou je eigen post nog eens even terug leest:

oldsmelly schreef op woensdag 30 december 2015 @ 08:43:
Meest voor de hand liggend is dit te doen in een Stored Procedure.
Daarin kun je ten alle tijden een roll Back doen op alle tabellen die je hebt ge-update.

...is het dan niet makkelijker te zeggen: "ooops, goeie morgen, ik bedoelde een transactie, my bad "?

@TS: Ik zou even hier beginnen en dan bij de examples kijken.

[ Voor 47% gewijzigd door RobIII op 30-12-2015 09:19 ]

[johnkeates]

Een stored procedure heeft inderdaad niks met de probleemstelling of de oplossing te maken om het nog maar even te bevestigen. Een transactie is wat nodig is om een wijziging over meerdere plekken in een keer te doen en daarna ongedaan te kunnen maken.

[oldsmelly]

Lezen is ook een vak he , zeker voor een admin hier..

Er staat toch duidelijke "Meest voor de hand liggend is dit te doen IN een Stored Procedure."
Daarnaast staat er dat je dan een rollback kan doen.
Een beetje ontwikkelaar gaat dan even een google doen ern ziet dan vanzelf dat er een transactie nodig is voor een Rollback

Beetje zelf initiatief tonen kom op zeg als je dat niet kan of wilt kan je beter iets anders gaan doen dan programmeren

[johnkeates]

Denk je nou echt dat iemand die moeite heeft met database gebruik en nog VB.NET gebruikt iets met een stored procedure op een database gaat doen? Iemand die nog uit moet zoeken hoe een transactie werkt gaat daar echt niet ook nog even SP's of PS's achteraan gooien.

[RobIII]

oldsmelly schreef op woensdag 30 december 2015 @ 09:17:
Er staat toch duidelijke "Meest voor de hand liggend is dit te doen IN een Stored Procedure."

Het is ook niet het meest voor de hand liggende. Het meest voor de hand liggende is gewoon:

Visual Basic .NET:

Using connection As New SqlConnection(connectionString)
    connection.Open()
    Using transaction As connection.BeginTransaction()
        Try
            ' Doe je ding hier
            transaction.Commit()
        Catch ex As SqlException
            transaction.Rollback()
        End Try
    End Using
    connection.Close()
End Using

(Uit de losse pols, mijn VB is wat roestig )
Staat ook in de examples maar daar wordt geen Using statement gebruikt voor de transactie en dat is niet bepaald netjes IMHO.

[ Voor 13% gewijzigd door RobIII op 30-12-2015 09:27 ]

[oldsmelly]

Wellicht heb ik een te grote verwachting van een topic wat onder PRO staat hier op tweakers.

Maar vroeger werd er op een topic niet eens gereageerd als de TS niet de moeite had genomen zelf op onderzoek uit te gaan en te vertellen wat de TS zelf al had geprobeerd.
TS plempt hier gewoon zijn probleem neer zonder zelf ook maar te vertellen wat hij zelf al had geprobeerd.

Maar goed we gaan wel erg Off topic daar heeft de TS niets aan ... en that's idd My Bad !

[ Voor 10% gewijzigd door oldsmelly op 30-12-2015 09:25 ]

[RobIII]

oldsmelly schreef op woensdag 30 december 2015 @ 09:24:
TS plempt hier gewoon zijn probleem neer zonder zelf ook maar te vertellen wat hij zelf al had geprobeerd.

...en daar kun je gewoon een Topic Report (klik op ' rapporteer' bovenaan een topic) voor doen en hoef je niet in 't topic zélf over te klagen Dan handelen de mods 't vanzelf af.

oldsmelly schreef op woensdag 30 december 2015 @ 09:24:

Maar goed we gaan wel erg Off topic daar heetr de TS niets aan ... en that's idd My Bad !

Gaan we weer ontopic

[ Voor 23% gewijzigd door RobIII op 30-12-2015 09:26 ]

[der_roedie]

Gellukkig NieuwJaar allemaal

Zonder teveel in detail te reageren op de vorige posts:
Ik heb al heel wat opgezocht maar echt een duidelijk antwoord op mijn vraag kan ik niet zo snel vinden dus ik vind het wel terecht dat ik hier dan de echte professionals, die geen VB.NET meer gebruiken, om raad vraag. Immers kan ik als eenvoudige VB.NET beginneling daar een hoop van leren.

Anyway; ik ben bekend met stored procedues en transactions binnen SQL, ik doe hier ook wel eens wat mee maar niet heel uitgebreid.
Dat is ook mijn manco, ik programmeer wat eenvoudige applicaties binnen mijn bedrijf en doe wat SQL-admin achtige taken maar van de hoed en de rand weet ik ook niet. Vandaar mijn vraag dus.

Is het handiger om een grote stored procedure te schrijven die alle tabellen beschrijft? Of zoals ik nu doe, aparte SQL-statements in mijn VB.NET code en die een voor een af trappen. Wat is zelf ervaar is dat ik het dan lastig vindt om te controleren waar eventueel een fout optreedt en dan de boel terug draaien. Dit zal makkelijker zijn in een stored procedure denk ik.

[Haan]

der_roedie schreef op maandag 04 januari 2016 @ 11:38:

Is het handiger om een grote stored procedure te schrijven die alle tabellen beschrijft? Of zoals ik nu doe, aparte SQL-statements in mijn VB.NET code en die een voor een af trappen. Wat is zelf ervaar is dat ik het dan lastig vindt om te controleren waar eventueel een fout optreedt en dan de boel terug draaien. Dit zal makkelijker zijn in een stored procedure denk ik.

Allebei niet: je schrijft 1 SQL statement die alles doet (en ja, dat kan in een stored procedure, maar dat hoeft niet, zie discussie hierboven ) bijv (UPDATE table x; UPDATE table y; UPDATE table z; etc), wat je binnen een transactie plaatst (zie voorbeeld RobIII). Als vervolgens de update van table z faalt, wordt alles teruggedraaid.

[der_roedie]

Dat snap ik dat het zo werkt. Ik wil eigenlijk meer weten wat vanuit een programmeer-standpunt het beste/handigste is om te doen.

[Woy]

Haan schreef op maandag 04 januari 2016 @ 13:47:
[...]

Allebei niet: je schrijft 1 SQL statement die alles doet (en ja, dat kan in een stored procedure, maar dat hoeft niet, zie discussie hierboven ) bijv (UPDATE table x; UPDATE table y; UPDATE table z; etc), wat je binnen een transactie plaatst (zie voorbeeld RobIII). Als vervolgens de update van table z faalt, wordt alles teruggedraaid.

Ik zie niet wat het voordeel is van in 1 SQL statement schrijven, dat kan prima in meerdere statements ( Die in dezelfde transactie uitgevoerd worden. ).

Wat je vooral niet wil is dat je SQL statements over je hele applicatie verdeeld zijn. Liever abstraheer je dit naar een apart gedeelte van je applicatie ( Je Data Access Layer ). Je kan daarbij prima gebruik maken van SP's, maar zoals RobIII ook aangeeft zijn de meningen verdeeld of dat nou mooier is of niet.

Ongeacht of je nou SP's gebruikt, wil je de database code niet over je hele applicatie verspreid hebben, want dat maakt onderhoud en wijzigingen lastiger.

[der_roedie]

Dank je Woy, dat is iets wat ik wilde horen.
Ik kan dus het beste een aparte module maken met daarin de te gebruiken statements in verschillende procedures of als ik de database statements wil hergebruiken in een aparte class of dll?

[Woy]

der_roedie schreef op maandag 04 januari 2016 @ 14:46:
Dank je Woy, dat is iets wat ik wilde horen.
Ik kan dus het beste een aparte module maken met daarin de te gebruiken statements in verschillende procedures of als ik de database statements wil hergebruiken in een aparte class of dll?

Klopt. Op die manier scherm je je database en de verantwoordelijkheid om daar mee te communiceren af van de rest van de applicatie. Die hoeft dan ook geen weet te hebben hoe dat gebeurt, het is gewoon een dienst die geleverd wordt door die module. ( Het hoeft overigens niet perse in 1 class te gebeuren natuurlijk. Als je een wat complexer design hebt kan het best een set van classes zijn )

Er zijn overigens een hele hoop verschillende aanpakken die kunt nemen. Tegenwoordig wordt er vaak gebruik gemaakt van een zogenaamd ORM ( Object Relational Mapper ), daarbij wordt veel werk je al uit handen genomen. Sommige nemen heel erg veel werk uit handen waardoor je zelf minder SQL hoeft te schrijven, andere nemen echt alleen de mapping van de resultset naar objecten over. ( Frameworks om naar te kijken: NHibernate, Entity Framework, Dapper, LLBLGEN, ActiveRecord en nog vele andere )

[ Voor 36% gewijzigd door Woy op 04-01-2016 14:55 ]

[der_roedie]

Helaas ontbreekt het op mijn werk aan veel tijd om daar op het gemak eens naar te kijken en heb ik thuis daar ook geen tijd voor (2 kleine kinderen en een studie) maar ik zal zeker de het DDM-stuk uit de rest van de applicatie halen en wellicht eens zien of ik dan beter gebruik kan maken van een SP of losse statements.

[Russel88]

der_roedie schreef op maandag 04 januari 2016 @ 15:27:
Helaas ontbreekt het op mijn werk aan veel tijd om daar op het gemak eens naar te kijken en heb ik thuis daar ook geen tijd voor (2 kleine kinderen en een studie) maar ik zal zeker de het DDM-stuk uit de rest van de applicatie halen en wellicht eens zien of ik dan beter gebruik kan maken van een SP of losse statements.

Tijd investeren in het begrijpen van een ORM mapper gaat je heel veel tijd besparen. Zelf CRUD queries kloppen is niet meer van deze tijd.

[Gomez12]

Russel88 schreef op maandag 04 januari 2016 @ 15:36:
[...]
Tijd investeren in het begrijpen van een ORM mapper gaat je heel veel tijd besparen. Zelf CRUD queries kloppen is niet meer van deze tijd.

Een ORM mapper enkel gebruiken voor CRUD queries is dan ook weer complete tijdsverspilling, het hangt simpelweg heel erg van de toepassing af...

Een ORM-Mapper is namelijk over het algemeen niet echt geoptimaliseerd, hij doet wat die moet doen, maar "echt snel" is die nou niet echt als je het gaat vergelijken met optimized sql (let er wel op dat dit relatieve inschattingen zijn, in de praktijk boeit het veelal niet zo erg of een query 50ms of 100ms duurt)

Een ORM-Mapper is voornamelijk extra gemak / beheersbaarheid tegen de kosten van performance, wat je dus voornamelijk dev-tijd scheelt.

Maarja, als het je enkel om CRUD-queries gaat hoeveel tijd kost het om daar een heel simpele eigen laag overheen te gooien...
Voornamelijk mass-updates in loopjes wilden vroeger nog wel eens leuk gaan (nu is het wel wat verbeterd maar ik zie het nog vaak genoeg fout gaan)
Of ORM-Mappers die complete objecten ophalen die giga-velden bevatten die niet noodzakelijk zijn voor deze CRUD-bewerking (maar wel voor het model)