[.net/llblgen]delete werkt niet

[Verwijderd]

Ik heb een methode "delete" voor mijn custom object.
Deze gebruikt drie tabellen , die moeten worden verwijderd.

probleem: hij verwijdert de records niet vanuit de tabellen fysiek

De code runt zonder problemen (er wordt nergens een exception gethrowed).
en ziet er als volgt uit

Visual Basic .NET:

        dalgrond.GrondId = New SqlInt32(grondId)

        Try
            dalgrond.SelectOne()
            dalvastgoed.VastgoedId = dalgrond.VastgoedId
            dalVastgoed_taal.VastgoedId = dalgrond.VastgoedId


            result = connectionprovider.OpenConnection
            connectionprovider.BeginTransaction("deleteGrond")
            Try
                result = dalgrond.Delete
                result = dalVastgoed_taal.DeleteAllWvastgoedIdLogic
                result = dalvastgoed.Delete

            Catch ex As Exception
                result = connectionprovider.RollbackTransaction("deleteGrond")
                Throw ex

            End Try

        Catch ex As Exception
            Throw New Exception("er was een probleem met het verwijderen van deze grond", ex)
        Finally
            connectionprovider.CloseConnection(False)

        End Try
    End Sub

Ik heb al op google gezocht maar niets relevant gevonden.

[justmental]

Ik ben echt los
Je hebt het over tabellen, dus er hangt een db onder.
Wat voor een db is dat?
Je zit methodes op objecten uit te voeren, wat gebruik je voor de object-relational mapping?

[Verwijderd]

ik gebruik sql server

deze methode staat in de klasse Vastgoedmapper (mijn object is een instantie van grond, maar dat doet er hier niet toe)
methode delete met als parameter grondId

[whoami]

Een dataset is een disconnect representation van je data.
Je kan dus de data wijzingen in je dataset, maar daarom is ze nog niet gewijzigd in je DB.

Je moet die dus nog committen naar je DB.

[Verwijderd]

mijn DAL is gegenereerd door llblgen, die roept de gepaste stored procedures op (delete, deleteALLFKlogic...)
ik gebruik geen dataset.
mijn disconnected representation staat in mijn objecten.
maw>> hier ga ik de status van mijn objecten doorvoeren naar mijn database >> delete dus.

[whoami]

Je gebruikt geen DataSet, maar je start wel een transactie.
Het principe dat llblgen gebruikt zal wel ongeveer hetzelfde zijn als dat van ado.net.

Trouwens, je start een transactie, maar je commit ze nergens. Het probleem situeert zich daar.
Spit de llblgen documentatie eens door op zoek naar een method om een transactie te committen, of hoe je transacties gebruikt.

[whoami]

BeginTransaction
Return Type bool (C#) or Boolean (VB.NET)
Return Type desc. True if the method succeeded, false otherwise. When an error occures, the method will throw an exception, which is the exception caught encapsulated in a new Exception exception.

Purpose
Starts an ADO.NET transaction over the open SqlConnection connection, which is opened by OpenConnection. The started connection is then used by all data-access tier objects among which this instance of the [Class prefix]ConnectionProvider class is shared and can be commited by calling the method CommitTransaction or rolled back by RollbackTransaction(TransactionName)

Parameters
TransactionName. Type: string (C#) or String (VB.NET).
The name of the transaction which is started. Use this name to refer to this transaction when calling RollbackTransaction.

Ik denk dat de kous hiermee af is.... Gewoon ff logisch nadenken, en de doc's doornemen.
(thx to gorgi_19 voor het aanleveren van de doc).

[gorgi_19]

whoami schreef op 07 August 2003 @ 21:34:
Je gebruikt geen DataSet, maar je start wel een transactie.
Het principe dat llblgen gebruikt zal wel ongeveer hetzelfde zijn als dat van ado.net.

Trouwens, je start een transactie, maar je commit ze nergens. Het probleem situeert zich daar.
Spit de llblgen documentatie eens door op zoek naar een method om een transactie te committen, of hoe je transacties gebruikt.

Hint: Ik denk dat het staat in Documentation\ref_connectionprovider.htm.

[Verwijderd]

thx!
(btw, was het gewoon vergeten te commiten, ik heb dit gebruikt over heel mijn classe, hier vergeten)

[whoami]

Verwijderd schreef op 07 August 2003 @ 21:39:
thx!
(btw, was het gewoon vergeten te commiten, ik heb dit gebruikt over heel mijn classe, hier vergeten)

In het vervolg: logisch nadenken, code debuggen, goed kijken dus....

[EfBe]

Verwijderd schreef op 07 August 2003 @ 21:39:
thx!
(btw, was het gewoon vergeten te commiten, ik heb dit gebruikt over heel mijn classe, hier vergeten)

Ik moet toegeven, die docs had ik wel wat uitgebreider kunnen maken, mbt die connectionprovider, maar ach, op zich is het niet zo complex.

offtopic:
Het is wel ego-strelend als je ziet dat mensen vragen stellen over jouw tool en anderen die vragen dan kunnen en ook gaan beantwoorden.

[Verwijderd]

EfBe schreef op 07 augustus 2003 @ 22:06:
[...]

Ik moet toegeven, die docs had ik wel wat uitgebreider kunnen maken, mbt die connectionprovider, maar ach, op zich is het niet zo complex.

offtopic:
Het is wel ego-strelend als je ziet dat mensen vragen stellen over jouw tool en anderen die vragen dan kunnen en ook gaan beantwoorden.

Maar je documentatie is wel goed hoor.
Ik ben fier op je, bangelijk programma!
(ik wacht vol ongeduld op versie 2.0)

[whoami]

Verwijderd schreef op 07 August 2003 @ 22:13:
[...]

(ik wacht vol ongeduld op versie 2.0)

Die komt er niet dacht ik.

NOTES: No new updates will be made on this codebase after this release. The next version will be LLBLGen Pro, the O/R mapper/code generator for .NET.

[gorgi_19]

Verwijderd schreef op 07 August 2003 @ 22:13:
[...]

Maar je documentatie is wel goed hoor.
Ik ben fier op je, bangelijk programma!
(ik wacht vol ongeduld op versie 2.0)

Mja, imho hadden bepaalde dingen wel uitgebreid mogen worden.

De pagina die ik eerder quotte had imho voorzien mogen worden van een klein voorbeeldje, met bijvoorbeeld transactions.

Wat ik verder nergens ben tegen gekomen is de constructie met het gebruik van:

Visual Basic .NET:

Dim _testWaarde As Integer = 4
Dim _sqlInt As SqlTypes.SqlInt32 = New SqlTypes.SqlInt32(_testWaarde)

Waar ik me wezeloos in eerste instantie naar gezocht heb..

[Verwijderd]

ik ook [rml][ vb.net]conversie sqlint32 en int32[/rml] :-)

@whoami: ik wacht dus op de pro.

[EfBe]

whoami schreef op 07 augustus 2003 @ 22:16:
[...]
Die komt er niet dacht ik.
[...]

Psst Ik ben al 7 maanden fulltime ermee bezig hoor



Dit is de pre-beta die nu bijna feature complete is (catalog refresh is nu in development). Verwachtte release date: 1 september. Niet gratis, wel kick ass

[EfBe]

gorgi_19 schreef op 07 August 2003 @ 22:22:
De pagina die ik eerder quotte had imho voorzien mogen worden van een klein voorbeeldje, met bijvoorbeeld transactions.

Dat zit er wel in hoor: usingdataaccess.htm, onderaan, maar niet zo duidelijk zoals ik al zei

Wat ik verder nergens ben tegen gekomen is de constructie met het gebruik van:

Visual Basic .NET:

Dim _testWaarde As Integer = 4
Dim _sqlInt As SqlTypes.SqlInt32 = 
New SqlTypes.SqlInt32(_testWaarde)

Waar ik me wezeloos in eerste instantie naar gezocht heb..

Is ook erg triest, dit wist ik niet toen ik de 1e versie releasede. VB.NET heeft geen operator overloading, en kan dus niet de implicit operators gebruiken die gedefinieerd zijn in die types. Je moet dus die klote constructie gebruiken. Die SqlDbTypes zijn verder rampzalig omdat ze niet serializable zijn. In de nieuwe gebruik ik dus die dingen niet maar gewoon native types, wat ook beter werkt omdat je met objects werkt, bv een CustomerEntity object en niet een datarow oid.

[whoami]

EfBe schreef op 08 August 2003 @ 11:01:
[...]

Psst Ik ben al 7 maanden fulltime ermee bezig hoor

[afbeelding]

Dit is de pre-beta die nu bijna feature complete is (catalog refresh is nu in development). Verwachtte release date: 1 september. Niet gratis, wel kick ass

Dat had ik al eens gezien op je blog.
Echter, ik dacht dat LLBLGEN Pro niet hetzelfde is als LLBLGEN 2, en dat deze niet gratis is.

[EfBe]

whoami schreef op 08 augustus 2003 @ 11:10:
[...]
Dat had ik al eens gezien op je blog.
Echter, ik dacht dat LLBLGEN Pro niet hetzelfde is als LLBLGEN 2, en dat deze niet gratis is.

LLBLGen v1.x is als code base niet hergebruikt, LLBLGen Pro is wel de successor van v1.x qua concept, het genereert geen DAL maar een business facade tier incl. DAL, wat dus een stap meer is dan een DAL alleen, plus genereert een 100% functionele BL facade, m.a.w., je hoeft geen eigen DAL code te bouwen om eigen selecties uit te voeren. llblgen 2 komt er dus nooit, want de codebase is te beperkt qua opzet om uberhaupt een versie 2 te kunnen maken. Qua concept wel degelijk. Zie het maar als windows 2000 die weinig hergebruikt heeft van NT4, maar wel de opvolger is

[whoami]

Ik las ook ergens dat je geen gebruik meer ging maken van stored procedures maar van dynamic queries.
Is dat eigenlijk geen beperking?
Door gebruik te maken van stored procedures kan je nl. toch een extra niveau van beveiliging toevoegen. Je geeft bv aan geen enkele role SELECT, INSERT, UPDATE rechten, en laat alles via stored procedures doen. Je grant dan enkel EXECUTE rechten aan de roles voor bepaalde SP's.

[EfBe]

whoami schreef op 08 augustus 2003 @ 11:42:
Ik las ook ergens dat je geen gebruik meer ging maken van stored procedures maar van dynamic queries.
Is dat eigenlijk geen beperking?
Door gebruik te maken van stored procedures kan je nl. toch een extra niveau van beveiliging toevoegen. Je geeft bv aan geen enkele role SELECT, INSERT, UPDATE rechten, en laat alles via stored procedures doen. Je grant dan enkel EXECUTE rechten aan de roles voor bepaalde SP's.

Nee dat is geen beperking. Je kunt die rechten nl. ook gewoon toekennen op de elementen zelf, bv tables en daar selectierechten toekennen voor bepaalde roles.

(overigens ook de manier hoe veel Oracle DBA's te werk gaan)

Verder heb je de beperking NIET die je wel hebt bij stored procedures en dat is dat je flexibel kunt filteren zonder de database server in te hoeven. Dat bereik je nooit met stored procedures. Ik wilde dit eerst ook niet geloven, maar geloof me, het is echt zo, die flexibiliteit betaalt zich echt terug.

Wil je toch bepaalde berekeningen direct in een sp gieten, of bv rapportage gegevens direct vanuit een sp betrekken, dan kan dat, je kunt 'calls' definieren naar sp's en die worden dan gegenereerd als methods van een class, met de sp parameters als method parameters.

[ Voor 4% gewijzigd door EfBe op 08-08-2003 12:02 ]

[whoami]

EfBe schreef op 08 augustus 2003 @ 11:49:
[...]

Nee dat is geen beperking. Je kunt die rechten nl. ook gewoon toekennen op de elementen zelf, bv tables en daar selectierechten toekennen voor bepaalde roles.

Idd, maar niet iedereen wil dat users direct rechten hebben op een table.

Verder heb je de beperking NIET die je wel hebt bij stored procedures en dat is dat je flexibel kunt filteren zonder de database server in te hoeven. Dat bereik je nooit met stored procedures. Ik wilde dit eerst ook niet geloven, maar geloof me, het is echt zo, die flexibiliteit betaalt zich echt terug.

Idd, daar hebben we het al eens over gehad (ISNULL, COALESCE).
Voor dergelijke queries is het idd interessant; echter, voor andere queries en SQL statements vind ik SP's netter.

Heb je al enig idee wat de prijs zal zijn van de Pro versie?

[EfBe]

whoami schreef op 08 augustus 2003 @ 12:01:
[...]
Idd, maar niet iedereen wil dat users direct rechten hebben op een table.

Dat hoeft toch niet? Je kunt toch een set users definieren die gebruikt worden door applicaties? Die users zijn bij gebruikers dus niet bekend. En of een applicatie nu via een stored proc een insert doet of direct, dat maakt niet uit. Voor selects kun je ook views definieren (daar zijn ze overigens voor) om beperkte columns terug te geven voor bepaalde users.

[...]
Idd, daar hebben we het al eens over gehad (ISNULL, COALESCE).
Voor dergelijke queries is het idd interessant; echter, voor andere queries en SQL statements vind ik SP's netter.

Er valt wat voor te zeggen natuurlijk Je hebt dan wel een aparte API. het is echter nauwelijks onderhoudbaar, vooral bij veel custom queries.

Heb je al enig idee wat de prijs zal zijn van de Pro versie?

175EUR ex BTW/VAT voor een site license ( == 1 license per department) (er zijn geen per-developer licenses). dus 1 prijs voor je complete team. Uiteraard is de runtime license free.

[ Voor 4% gewijzigd door EfBe op 08-08-2003 12:06 ]

[whoami]

EfBe schreef op 08 August 2003 @ 12:05:
[...]

Dat hoeft toch niet? Je kunt toch een set users definieren die gebruikt worden door applicaties? Die users zijn bij gebruikers dus niet bekend. En of een applicatie nu via een stored proc een insert doet of direct, dat maakt niet uit. Voor selects kun je ook views definieren (daar zijn ze overigens voor) om beperkte columns terug te geven voor bepaalde users.

Bedoel je hier application roles?
Dan nog kan het zijn dat SP's veiliger zijn. Stel dat je een web-applicatie hebt, die web-applicatie heeft toegang tot de DB via een application-role, en die role heeft SELECT rechten op de tabellen zelf.
Stel nu dat jij je query dynamisch gaat gaan opbouwen, en dat er een query uitgevoerd wordt op een tabel om -ik zeg maar wat- productinformatie op te halen.
De URL ziet er bv zo uit:

code:

http://www.mysite.be/ProductDetail.aspx?ProductId=1

Stel nu dat ik die url als volgt verander:

code:

http://www.mysite.be/ProductDetail.aspx?ProductId=1;SELECT * FROM tabel

Dan zou die query na de ; ook uitgevoerd worden (tenzij je natuurlijk gebruik maakt van parametrized queries). Daarbij komt natuurlijk ook nog dat je al de naam van die tabel moet kennen.

Er valt wat voor te zeggen natuurlijk Je hebt dan wel een aparte API. het is echter nauwelijks onderhoudbaar, vooral bij veel custom queries.

Wat is er dan nauwelijks onderhoudbaar? Die stored procedures? Dat valt zeer goed mee vind ik. Alle DB code zit in 1 centrale plaats.

_{eigenlijk ging dit topic over heel iets anders...}

[EfBe]

whoami schreef op 08 augustus 2003 @ 12:17:
[...]
Bedoel je hier application roles?
Dan nog kan het zijn dat SP's veiliger zijn. Stel dat je een web-applicatie hebt, die web-applicatie heeft toegang tot de DB via een application-role, en die role heeft SELECT rechten op de tabellen zelf. Stel nu dat jij je query dynamisch gaat gaan opbouwen, en dat er een query uitgevoerd wordt op een tabel om -ik zeg maar wat- productinformatie op te halen.
De URL ziet er bv zo uit:

code:

http://www.mysite.be/ProductDetail.aspx?ProductId=1

Stel nu dat ik die url als volgt verander:

code:

http://www.mysite.be/ProductDetail.aspx?ProductId=1;SELECT * FROM tabel

Dan zou die query na de ; ook uitgevoerd worden (tenzij je natuurlijk gebruik maakt van parametrized queries). Daarbij komt natuurlijk ook nog dat je al de naam van die tabel moet kennen.

Natuurlijk maak ik gebruik van parametrized queries. Die worden ook gecached door bv Oracle en Sqlserver, dus verlies je geen performance. Er komt geen sql concatenation met values aan te pas. M.a.w.: het komt op hetzelfde neer, een sp uitvoeren onder de user ASPNET die een select doet of een select doen onder de user ASPNET.

[...]
Wat is er dan nauwelijks onderhoudbaar? Die stored procedures? Dat valt zeer goed mee vind ik. Alle DB code zit in 1 centrale plaats.

Met 100 tables en op elke table 3 of 4 verschillende selects loopt het rap uit de hand. het punt is: je wilt in hogere lagen een filter creeren, echter dat moet je op lagere lagen definieren met sp's, waardoor je direct in de database je filter moet maken, maar dat filter is dan wel meteen vastgezet en heeft geen directe relatie met de code die daarop ligt. Dit houdt dus in dat wanneer je de code die er op ligt wijzigt (andere filter nodig bv) je met een sp zit die niet meer wordt aangeroepen en er een nieuwe bij moet plaatsen. Bij dyn. queries verander je de filter en klaar ben je . Je loopt dan ook niet het risico dat wanneer je de sp wijzigt, ANDERE code niet meer goed werkt, want je filter die je daar ter plekke nodig hebt, definieer je ook daar ter plekke. Als je een SP api als een API ziet met een interface mag je dus in feite nooit een sp verwijderen/wijzigen, je moet altijd een nieuwe bijbouwen. Dit kan vrij snel onbeheersbaar worden.

[ Voor 9% gewijzigd door EfBe op 08-08-2003 12:26 ]

[alienfruit]

Efbe, ik zie op je screenshot dat je van die dockable windows/dockpanels hebt. Waarmee heb je die gemaakt als ik vragen mag?

[CubicQ]

http://weblogs.asp.net/fbouma/posts/9172.aspx#17412
The Magic library from Cronwood dus (http://www.dotnetmagic.com/)

offtopic:
Mooi lettertype voor je titlebar.

[Verwijderd]

zal er ook mysql of access worden ondersteund?

[gorgi_19]

Verwijderd schreef op 08 August 2003 @ 20:12:
zal er ook mysql of access worden ondersteund?

Ik vraag me af of je uberhaupt Access zou willen ondersteunen voor dit soort dingen en niet gelijk naar MSDE dan grijpt.

[Verwijderd]

Ik gebruik thuis MSDE
hosting met sql server is DUUR! (tenzij jij een goeie kent?)
mijn host gebruikt voorlopig MSDE voor mij en nog een n-aantal klanten, niet zoveel, wel vreselijk ongemakkelijk!

[EfBe]

access zit wel in de planning. MySql weet ik niet. het ding ondersteunt geen FK's, althans alleen de laatste versies geloof ik. En dan ben je rap uitgepraat wanneer je het hebt over entities en relations

[gorgi_19]

Verwijderd schreef op 08 August 2003 @ 20:20:
Ik gebruik thuis MSDE
hosting met sql server is DUUR! (tenzij jij een goeie kent?)
mijn host gebruikt voorlopig MSDE voor mij en nog een n-aantal klanten, niet zoveel, wel vreselijk ongemakkelijk!

Waarbij ik me trouwens afvraag of je niet de licentie breekt (er zijn maar een paar gevallen voor zover ik weet dat je MSDE mag gebruiken voor Internet, maar dat is een andere discussie). Je kan trouwens ook SQL Server 2k trial editie downloaden, daar zit een Enterprise Manager bij.

Verder weet ik dat SQL Server duur is; zit ook in mijn hostingpakket.

Ik verwacht trouwens dat Access steeds meer een ondergeschoven kindje gaat worden en MS meer en meer gaat bouwen op SQL Server / MSDE.

[Verwijderd]

voorlopig is het alleen voor testdoeleinden.
Hoeveel betaal je per maand voor je sql server hosting?

[EfBe]

zie oa www.is.nl voor hosting met sqlserver. ze hebben win2k3 en .net

[alienfruit]

s-man rond de 30-35euro

[gorgi_19]

Verwijderd schreef op 08 augustus 2003 @ 22:24:
voorlopig is het alleen voor testdoeleinden.
Hoeveel betaal je per maand voor je sql server hosting?

Bij mij zat het bij m'n ASP.Net hosting pakket inbegrepen..
Bij de provider waar ik zit heb je SQL Server pakketten vanaf 34 Euro, je krijgt hierbij dan 25 MB databaseruimte. Heb je meer nodig; 150 MB kost 67 Euro per maand. Ook kan je voor 15 Euro per maand 50 MB extra ruimte krijgen.

EfBe noemde er al eentje; een andere is bijvoorbeeld www.Nedcomp.nl en zo zijn er nog meerdere. Je kan anders eens kijken op www.webhosters.nl

Ik denk dat de prijzen elkaar niet heel veel ontlopen. Het is vooral aan jezelf om te kijken welke betrouwbaar is en wat voor opties je krijgt.

[ Voor 47% gewijzigd door gorgi_19 op 09-08-2003 01:00 ]

[alienfruit]

Wow. Ben ik blij dat ik onbeperkt heb voor me databaseruimte.

[gorgi_19]

alienfruit schreef op 09 August 2003 @ 01:08:
Wow. Ben ik blij dat ik onbeperkt heb voor me databaseruimte.

Ik heb het hier niet over dataverkeer..
Maar je mag dus ook een database maken van vele GB's groot? * gorgi_19 zou dat an sich vrij vaag vinden....

[ Voor 9% gewijzigd door gorgi_19 op 09-08-2003 01:11 ]

[whoami]

EfBe schreef op 08 August 2003 @ 11:49:
[...]

Verder heb je de beperking NIET die je wel hebt bij stored procedures en dat is dat je flexibel kunt filteren zonder de database server in te hoeven. Dat bereik je nooit met stored procedures. Ik wilde dit eerst ook niet geloven, maar geloof me, het is echt zo, die flexibiliteit betaalt zich echt terug.

Je kan toch je SP al volgt gaan definieren:

code:

CREATE PROCEDURE SEARCHSOMETING (@p_naam   varchar(25), @p_famnaam varchar(25))
as

SET @p_naam = @p_naam + '%';
SET @p_famnaam = @p_famnaam + '%';

SELECT * FROM tabel 
WHERE naam LIKE @p_naam
AND famnaam LIKE @p_famnaam

_{simpel voorgesteld en dit werkt alleen voor alfanumeriek velden}

Nu zou ik wel ff moeten testen wat het execution plan is van deze query als @p_naam en @p_famnaam leeg zijn , en de query dus als volgt is:

code:

select * from tabel where naam like '%' and famnaam like '%'

en dit vergelijken met het execution plan van deze query:

code:

select * from tabel

[EfBe]

whoami schreef op 09 August 2003 @ 12:51:
[...]
Je kan toch je SP al volgt gaan definieren:

code:

CREATE PROCEDURE SEARCHSOMETING (@p_naam   varchar(25), 
@p_famnaam varchar(25))
as

SET @p_naam = @p_naam + '%';
SET @p_famnaam = @p_famnaam + '%';

SELECT * FROM tabel 
WHERE naam LIKE @p_naam
AND famnaam LIKE @p_famnaam

_{simpel voorgesteld en dit werkt alleen voor alfanumeriek velden}

DIt werkt niet. Als een van beide leeg is krijg je alle rows voor dat predicate . En als ik een OR wil, hang ik al

Nu zou ik wel ff moeten testen wat het execution plan is van deze query als @p_naam en @p_famnaam leeg zijn , en de query dus als volgt is:

code:

select * from tabel where naam like '%' and famnaam like '%'

en dit vergelijken met het execution plan van deze query:

code:

select * from tabel

Verder zijn string concatenations in een stored proc niet goed. T-SQL of SQL in het algemeen zijn niet goed in string functionaliteit, logisch, het is een setbased language.

[ Voor 4% gewijzigd door EfBe op 09-08-2003 13:02 ]