SQL/ASP > hoe is jouw code verhouding?

[blijhoofd_bennie]

Ik had een klein vraagje over de SQL code en ASP (van webpages) code verhouding die je het beste zou kunnen toepassen bij een pagina.

Ik vroeg me namelijk af welke van de (naar mijn mening 3) gevonden programmeer manieren van ASP en SQL het beste is (kwa snelheid,veiligheid, serverload).
En natuurlijk welke volgens jullie het beste is (uitgaande van eigen ervaring zou dan wel handig zijn)

Hieronder mijn 3 gevonden manieren:

- Gebruik je ASP pagina om te rekenenen/controleren etc (dus veldwaarde1 + veldwaarde 2 etc). En alleen de SQL code gebruiken om waarden in de SQL database in te voeren.

Voordelen: Het is over het algemeen de makkelijste manier van programmeren, ken je ASP goed dan kom je heel ver. Je SQL kennis hoeft niet op een mega hoog niveau te zijn. Dit is tevens niet de snelste manier (denk ik tenminste) en niet de veiligste (kwa datahiding).

- Gebruik je ASP pagina om de berekende waarden(dit wordt wederom door de ASP pagina gedaan) via stored procedures weg te schrijven in de database.

Voordelen: Deze manier is sneller dan de voorgaande manier (denk ik) en je datahiding is beter. Je kunt een rollback gebruiken (= is een handige functie om fouten op te vangen, maar persoonlijk houd ik er het idee op na, zover als de rollback moet je het nooit laten komen). Je SQL kennis moet wel iets hoger zijn (kennis met storedprocedures en hun mogelijkheden)

- Gebruik je SQLcode voor zowel het invoeren van de waarden in de database en om de berekeningen uit te voeren (je zou ASP kunnen laten controleren of er bijvoorbeeld een numerieke waarde is ingevoerd etc, maar is dit misschien ook handig om dat met SQL te doen?). En je ASP pagina heeft dan alleen als functie de waarden door te geven (je zou misschien ook dan alleen html kunnen gebruiken, maar dat doe ik persoonlijk liever niet m.b.t het datahiding aspect). Je moet bij deze manier wel behoorlijk wat kennis van SQL hebben.

Voordelen (geen ervaring mee neem ik aan):
- Deze manier is het snelst, kwa server load en tijd, en kwa datahiding het veiligst.

Maar mijn vraag aan julie is dus de volgende:
- Welke manier is het snelste (en heb je er een voorbeeld van, page duurde eerst zoveel sec en nu zoveel sec..)
- Wat is de server load op de verschillende manieren (iemand ervaring mee).
- En kun je goed met SQL rekenen? (persoonlijk dus nooit echt gedaan op heeel diep niveau gedaan, wel eens 1+1 principen, maar dan in het SQL statement van de ASP pagina).
- En persoonlijke ervaringen van de hierboven genoemde manieren is ook altijd welkom.

Alvast bedankt

[Verwijderd]

Ik denk dat het beste kunt gaan voor de ASP/stored procedure combi. Dit omdat stored procedures sneller zijn in tegenstelling tot het uitvoeren van gewone queries op je database omdat stored procedures gecompileerd worden opgeslagen voor zover ik weet. Over datahiding hoef je je volgens mij niet echt zorgen te maken indien je je ASP server-side draait. Het enige wat de client ziet is plain HTML. Wat wil je eigenlijk verbergen? Iets wat ze zelf invoeren? Indien je handig bent in VB zou ik een dll schrijven die je als object in je ASP pagina kunt gebruiken. De dll kun je dan gebruiken om de communicatie met de database te regelen. Dan heb je een veilige en snelle combi. Verder zou ik voor het rekenwerk Javascript aanraden of client-side ASP omdat je het rekenwerk dan bij de client zelf laat doen wat de server-load ten goede zal komen.

[blijhoofd_bennie]

Op dinsdag 23 april 2002 09:23 schreef kikkei01 het volgende:
Over datahiding hoef je je volgens mij niet echt zorgen te maken indien je je ASP server-side draait. Het enige wat de client ziet is plain HTML.
....
Dan heb je een veilige en snelle combi. Verder zou ik voor het rekenwerk Javascript aanraden of client-side ASP omdat je het rekenwerk dan bij de client zelf laat doen wat de server-load ten goede zal komen.

Bij 1:

Dit klopt, maar hier biedt SQL weer een extra laag.
Bedoel een ASP pagina binnen krijgen is makkelijker te doen dan in het binnenkomen van de SQL database (toch?)
En als ze dan de ASP binnen zouden halen (zou niet weten waarom) weten ze precies hoe de page werkt en kunnen ze zich misschien toegang verschaffen tot bepaalde punten.

Bij 2:
Is dit een veel gebruikte manier? Ok ik ben geen hacker ofzo, maar dit lijkt mij persoonlijk niet echt veilig. Bedoel kan het helemaal mis hebben, maar als je iets clientside laat bereken, zou je deze waarden toch kunnen aanpassen (dus bijvoorbeeld prijzen van producten, aantallen etc).
En als je dit zou opvangen door de server de waarden laten te vergelijken, zou je dan niet beter niet direct de waarden door de server laten berekenen? (het percentage kwa performance wat je hiermee zou bereiken lijkt me persoonlijk zeer klein, als je de mijn bescherven manier bedoeld tenminste).

[Verwijderd]

Ik snap niet helemaal wat je bedoelt met het feit dat SQL een extra laag is. In principe is het niet mogelijk om ASP pagina's van een server te trekken zodat je de code kan bekijken. Maak je daar dus maar geen zorgen om. Tuurlijk, alles is mogelijk. Maar je komt er echt niet makkelijk achter wat er in een ASP pagina staat mits de webserver goed is ingesteld. Als je gebruik maakt van een dll die de communicatie met de database regelt hoef je je niet echt zorgen te maken over dat iemand in de database komt of bij gevoelige info komt.

Het valideren van gegevens client-side dmv Javascript of eventueel client-side ASP gebeurt veel. Dit zal je zeker merken in je server-load indien het om een pagina gaat die veel gebruikt/bezocht wordt. Het gaat ook alleen om het valideren van gegevens, dus gegevens die door de gebruiker zelf zijn ingevuld.

Ik weet niet precies wat je wilt maken maar kijk eens naar wat oline winkels ofzo. Daar kun je een aardig idee krijgen van wat client-side gebeurt en wat dus naar alle waarschijnlijlheid op de server nog gedaan moet worden. Op basis daarvan kun je denk ik wel een aardige indeling maken in wat je op de server laat doen en wat je bij de client laat doen.

[blijhoofd_bennie]

Op dinsdag 23 april 2002 10:00 schreef kikkei01 het volgende:

Ik weet niet precies wat je wilt maken maar kijk eens naar wat oline winkels ofzo. Daar kun je een aardig idee krijgen van wat client-side gebeurt en wat dus naar alle waarschijnlijlheid op de server nog gedaan moet worden. Op basis daarvan kun je denk ik wel een aardige indeling maken in wat je op de server laat doen en wat je bij de client laat doen.

Ok, zal eens een beetje rondneuzen. Maar ja ik kan natuurlijk niet alles checken (gegevens die je niet te zijn krijgt)
Maar ik zou graag wel eens meer willen weten over die laatste manier (geheel SQL dus) of daar mensen ervaring mee hebben? iemand?

[Verwijderd]

Ik heb ervaring met SQL, ASP, Javascript en PHP. Ik heb tot nu toe SQL alleen gebruikt om data op te halen, weg te schrijven, up te daten enz. Als je je queries onnodig groot gaat maken zal dat je systeem alleen maar vertragen. Mijn ervaring is dat als je het snel wilt hebben je er voor moet zorgen dat de interactie naar de database tot een minimum beperkt wordt. Oftewel: laat het bereken over aan ASP(VBScript bv) of aan een dll of iets anders en gebruik SQL of stored procedures om dingen weg te schrijven, te halen, te deleten, te updaten enz.

[blijhoofd_bennie]

Op dinsdag 23 april 2002 10:24 schreef kikkei01 het volgende:
Ik heb ervaring met SQL, ASP, Javascript en PHP. Ik heb tot nu toe SQL alleen gebruikt om data op te halen, weg te schrijven, up te daten enz. Als je je queries onnodig groot gaat maken zal dat je systeem alleen maar vertragen. Mijn ervaring is dat als je het snel wilt hebben je er voor moet zorgen dat de interactie naar de database tot een minimum beperkt wordt. Oftewel: laat het bereken over aan ASP(VBScript bv) of aan een dll of iets anders en gebruik SQL of stored procedures om dingen weg te schrijven, te halen, te deleten, te updaten enz.

En wat is in jou geval de server load weet jij dat toevallig, ik ben namelijk wel benieuwd hoeveel geheugen een actie bij jou ongeveer in beslag neemt en wat de tijdsduur er van is.
Anders mag je wel ff een pagina noemen, die jij gemaakt hebt op jou manier, kan ik die eens bekijken.

[Verwijderd]

Ik weet niet helemaal waar je naartoe wilt maar ik probeer jou te helpen door aan te geven wat mijn ervaringen zijn. De projecten die ik gedaan heb waren in het kader van mijn studie waarbij producten opgeleverd moesten worden die van tijdelijke aard waren -> bestaat geen site meer van. Een ander project was een stage-opdracht en was een applicatie die zich in een intranet bevond. Ik kan je niet vertellen wat de server-loads waren. We hebben maar tijdens 1 project gebruik gemaakt van een performance monitor en dat was in PHP en draaide onder linux, database was Sybase.

Ik kan me niet voorstellen dat je serieus geinteresseerd bent in de server-load van een vreemd systeem. Welke info denk je daaruit te halen?

Ik kan me dan ook niet helemaal aan de indruk ontrekken dat je niet tevreden bent met de verkregen info of dat je me niet gelooft ofzo.

Wat je met de info doet is aan jou. Het enige wat ik kan doen is mijn ervaringen met je delen, niet meer dan dat.

[blijhoofd_bennie]

Op dinsdag 23 april 2002 10:59 schreef kikkei01 het volgende:
Ik weet niet helemaal waar je naartoe wilt maar ik probeer jou te helpen door aan te geven wat mijn ervaringen zijn. De projecten die ik gedaan heb waren in het kader van mijn studie waarbij producten opgeleverd moesten worden die van tijdelijke aard waren -> bestaat geen site meer van. Een ander project was een stage-opdracht en was een applicatie die zich in een intranet bevond. Ik kan je niet vertellen wat de server-loads waren. We hebben maar tijdens 1 project gebruik gemaakt van een performance monitor en dat was in PHP en draaide onder linux, database was Sybase.

Ik kan me niet voorstellen dat je serieus geinteresseerd bent in de server-load van een vreemd systeem. Welke info denk je daaruit te halen?

Ik kan me dan ook niet helemaal aan de indruk ontrekken dat je niet tevreden bent met de verkregen info of dat je me niet gelooft ofzo.

Wat je met de info doet is aan jou. Het enige wat ik kan doen is mijn ervaringen met je delen, niet meer dan dat.

Nou ik gebruik jou info ook, maar ik houd er ook het volgende idee op na, zien is geloven. Hierdoor kan ik ook een indruk maken van hoe snel het ongeveer is.
En de serverload zou ik persoonlijk graag willen weten (gewoon in percentage), want dit is wel een belangrijk aspect (bedoel je bent meestal wel afhankelijk van je provider).
Ik neem jou informatie dus zeker weten ook mee, maar al mijn vragen zijn nog niet beantwoordt, maar aangezien jou ervaring op 1 punt hoog was (mijn 2de programmeer manier), zou ik graag het resultaat van jou werk willen zien indien dit mogelijk was. Ok?

Maar samenvattend, jou ervaringen over punt 2 neem ik natuurlijk mee, maar nu de andere punten nog.

[Crazy D]

Op dinsdag 23 april 2002 10:24 schreef kikkei01 het volgende:
Ik heb ervaring met SQL, ASP, Javascript en PHP. Ik heb tot nu toe SQL alleen gebruikt om data op te halen, weg te schrijven, up te daten enz. Als je je queries onnodig groot gaat maken zal dat je systeem alleen maar vertragen. Mijn ervaring is dat als je het snel wilt hebben je er voor moet zorgen dat de interactie naar de database tot een minimum beperkt wordt. Oftewel: laat het bereken over aan ASP(VBScript bv) of aan een dll of iets anders en gebruik SQL of stored procedures om dingen weg te schrijven, te halen, te deleten, te updaten enz.

Mijn ervaring is dat bv in een loopje je records doorwandelen om een totaalbedrag te bereken, dit trager is en vooral meer load oplevert, dan wanneer je sql dat zelf kan laten doen. Misschien simpel geredeneert, maar als bv een sum() zo performancevertragend zou zijn, zou het niet in sql zjin ingebakken. Gezien het feit dat het er wel in zit, is het dus an sich geen slecht iets. Kan het hooguit bij jou slecht (lees: traag) zijn, en dat zegt denk ik iets over je db model. (zoals ik al zei, ff simpel geredeneert). Zonder benchmark, ik kan me gewoon niet voorstellen dat een sum()metje hier en wat + en - 'tjes daar in je query langzamer is, dan dat je dat in je script uitvoert.
En zeker als dit queries zijn die je als view of stored proc hebt in gebouwt in je db, aangezien dat weet sneller is dan een query vanuit code.

[Verwijderd]

Ok, das natuurlijk wel begrijpelijk. Maar zoals ik al zei, ik kan alleen mijn ervaringen delen, helaas. Maar ik heb dus ervaring met manier 1 en manier 2. Ik heb ze beiden gebruikt. Ik neem aan dat je met SQL-server gaat werken? Als ik het had moeten proggen dan zou ik voor de stored procedures gaan omdat ik weet dat dat sneller is dan SQL-statements in je ASP.

Ik ben ook geneigd om te zeggen dat manier 3 niet eens kan. Maar dat kan natuurlijk ook een gebrek aan kennis zijn. Ik weet dat je met SQL nog wel iets meer kunt dan alleen het ophalen, updaten, deleten enz. van data uit je database. Ik heb echter nog nooit iemand gezien die alle functionaliteit van een, bijvoorbeeld, online winkel in SQL wist op te lossen.

[blijhoofd_bennie]

Op dinsdag 23 april 2002 11:27 schreef kikkei01 het volgende:
Ok, das natuurlijk wel begrijpelijk. Maar zoals ik al zei, ik kan alleen mijn ervaringen delen, helaas. Maar ik heb dus ervaring met manier 1 en manier 2. Ik heb ze beiden gebruikt. Ik neem aan dat je met SQL-server gaat werken? Als ik het had moeten proggen dan zou ik voor de stored procedures gaan omdat ik weet dat dat sneller is dan SQL-statements in je ASP.

Ik ben ook geneigd om te zeggen dat manier 3 niet eens kan. Maar dat kan natuurlijk ook een gebrek aan kennis zijn. Ik weet dat je met SQL nog wel iets meer kunt dan alleen het ophalen, updaten, deleten enz. van data uit je database. Ik heb echter nog nooit iemand gezien die alle functionaliteit van een, bijvoorbeeld, online winkel in SQL wist op te lossen.

Manier 3 weet ik zelf ook niet helemaal zeker (of het zo werkt als ik denk), maar ik weet wel dat je met SQL kunt rekenen en heb het ook wel eens gedaan (maar dan in de ASP code zelf). Maar het hoe en wat moet ik ook eens na zoeken (of weet iemand direct een goede page?)

Dus leek mij de logische stap dat het in de SQL server ook wel zou moeten kunnen (maar ja wie ben ik?)
Misschien ga ik mij het volgende boek aanschaffen.

Transact SQL (van de 21 dagen man, boeken)
En daar stonden hele stukken SQL code in waarmee ook gerekend werd (maar echt ik heb niet echtgoed gekeken hoe het zit m.b.t het internet heb ik niet, staat ook zo vaag in de winkel, maar dit doe ik de volgende keer).

[blijhoofd_bennie]

Op dinsdag 23 april 2002 11:24 schreef Crazy_D het volgende:

[..]

Mijn ervaring is dat bv in een loopje je records doorwandelen om een totaalbedrag te bereken, dit trager is en vooral meer load oplevert, dan wanneer je sql dat zelf kan laten doen. Misschien simpel geredeneert, maar als bv een sum() zo performancevertragend zou zijn, zou het niet in sql zjin ingebakken. Gezien het feit dat het er wel in zit, is het dus an sich geen slecht iets. Kan het hooguit bij jou slecht (lees: traag) zijn, en dat zegt denk ik iets over je db model. (zoals ik al zei, ff simpel geredeneert). Zonder benchmark, ik kan me gewoon niet voorstellen dat een sum()metje hier en wat + en - 'tjes daar in je query langzamer is, dan dat je dat in je script uitvoert.
En zeker als dit queries zijn die je als view of stored proc hebt in gebouwt in je db, aangezien dat weet sneller is dan een query vanuit code.

Kun jij mij missschien een situatie noemen waarin jij echt een goed verschil merk (want jou beredenering lijkt mij ook logisch heb alleen geen voorbeeld )

[Verwijderd]

Misschien dat dit nog wat is:

Boek : Het SQL leerboek
Auteur: Rick F. van der Lans
ISBN : 9039507554

[PdeHoog]

Op dinsdag 23 april 2002 11:50 schreef blijhoofd_bennie het volgende:

[..]

Kun jij mij missschien een situatie noemen waarin jij echt een goed verschil merk (want jou beredenering lijkt mij ook logisch heb alleen geen voorbeeld )

Je vraagt hier vooral voorbeelden, maar de beste manier om er achter te komen is het zelf uitproberen. Dan leer je ook nog wat .

Zo moeilijk is het tenslotte allemaal niet en de performance is toch erg situatie-afhankelijk (hoeveelheid data, indices etc.).

[Crazy D]

Op dinsdag 23 april 2002 11:50 schreef blijhoofd_bennie het volgende:
Kun jij mij missschien een situatie noemen waarin jij echt een goed verschil merk (want jou beredenering lijkt mij ook logisch heb alleen geen voorbeeld )

Faktuur met 100 regels, in de regel is de artikelprijs opgenomen (zodat bij prijswijzigingen later de fakturen blijven voor de prijs die op dat moment gold), kortingsbedrag veld omdat veel klanten graag de verkoopprijs en kortingsbedrag willen laten zien i.p.v. 1 verkoopprijs (waar de korting al in zit).
Totaalbedrag berekenen van de faktuur (BTW nog even weggelaten).
Mogelijkheid 1:

code:

SELECT SUM(artikelprijs * aantal) - SUM(kortingsbedrag) AS totaalbedrag
FROM faktuurregels
WHERE faktuurnr = 11

Response.Write rs.Collect("totaalbedrag:(

tegen over

code:

SELECT artikelprijs, aantal, kortingsbedrag
FROM faktuurregels
WHERE faktuurnr = 11

waarna je een loopje moet doen:

code:

Dim dTotaal
dTotaal = 0
Do While Not rs.EOF
    dTotaal = dTotaal + ((rs.Collect("artikelprijs") * rs.Collect("aantal")) - rs.Collect("kortingsbedrag"))
    rs.MoveNext
Loop

Even zo ff gauw verzonnen (maar het gaat ff om het idee ). Tenzij een benchmark duidelijke winst aangeeft bij de 2e manier, blijf ik er van overtuigd dat de 1e manier sneller is en uiteindelijk dus minder belastend voor je server. Immers, stel dat sql er 1 seconde 100% CPU voor nodig heeft, en mijn script 2 seconden 100% CPU... naja je snapt het wel.

En als 100 regels niet voldoende is, neem je er een stuk meer (ja een aantal klanten van ons hebben regelmatig fakturen van een paar duizend regels).

Overigens zou je hier natuurlijk kunnen overwegen om een trigger te maken in de faktuurregels tabel, in de kopregel-tabel een totaalbedrag (en evt. een totaalkortingsbedrag), en de trigger de velden in de faktuurkop laten bijwerken... (maar ook dan laat je het sql doen

[blijhoofd_bennie]

Op dinsdag 23 april 2002 12:12 schreef PdeHoog het volgende:

[..]

Je vraagt hier vooral voorbeelden, maar de beste manier om er achter te komen is het zelf uitproberen. Dan leer je ook nog wat .

Zo moeilijk is het tenslotte allemaal niet en de performance is toch erg situatie-afhankelijk (hoeveelheid data, indices etc.).

Ik wil voorbeelden om gewoon het complete resultaat te zijn, ik maak nu ook wel queries met de queryanalyzer. Maar ik wil gewoon ff een complete pagina zien (want dat heb je niet zo snel in elkaar).
Delen kan ik dus zelf wel voor zorgen, maar ik wil dus een compleet resultaat zien, dan weet ik wat ik on the web van mijn werk mag verwachten. Bedoel als het tegen zit, waarom zou ik het dan maken op die manier

Mijn collega hiero houd er de volgende manier op na (zo dacht ik er ook over)
- Wanneer mogelijk doe je zoveel mogelijk met SQL
- Dus views, berekeningen en foutcontrolles ook door de SQLserver laten doen. We programmeren hier in delphi dus daar kun je de SQL fouten mee opvangen, maar aangezien ik de enige ben hier die met ASP heeft gewerkt, weet ik ff niet of ASP daar goede functies voor heeft (dacht zelf aan onerror, maar ik weet niet of die SQL kan opvangen, moet ik naar zoeken).
- ASP dus puur en alleen om de gebruikers interface weer te geven (en de gegevens een beetje te hiden voor de user).
- Nog een voordeel is (van collega) is dat SQL veel sneller is met het uitvoeren van berekeningen en als dat zo is kan ik ze beter in SQL doen, want als ik het nou in ASP doe of door de SQLserver, de server moet het uitvoeren (ook al zijn ze evensnel heeft SQL nog steeds meer voordelen)
- En niets (tenzij niet anders) niet clientside laten uitvoeren (citeer collega: Als je dit kunt omzeilen moet je dat doen) m.b.t. berekeningen de gebruiker zou de waarden namelijk dan kunnen aanpassen.

Ik kan me persoonlijk wel vinden in dit standpunt, wat is jullie mening hierover, ik zie namelijk nu alleen de voordelen er van in.

[blijhoofd_bennie]

Op dinsdag 23 april 2002 12:44 schreef Crazy_D het volgende:

[..]

Overigens zou je hier natuurlijk kunnen overwegen om een trigger te maken in de faktuurregels tabel, in de kopregel-tabel een totaalbedrag (en evt. een totaalkortingsbedrag), en de trigger de velden in de faktuurkop laten bijwerken... (maar ook dan laat je het sql doen

Bedankt voor je situatieschets vanuit julie situatie (= very handy)

Maar jij voert je SQL script nu toch nog steeds uit in je ASP scripts of niet?
Ik bedoelde juist ook de SQL scripts, maar dan door de SQLserver zelf m.b.v stored procedures om zo een nog grotere winst te behalen.

[Crazy D]

Op dinsdag 23 april 2002 12:54 schreef blijhoofd_bennie het volgende:
Maar jij voert je SQL script nu toch nog steeds uit in je ASP scripts of niet?

Sommige queries voer ik wel vanuit code uit, maar voor het grootste deel gebruik ik stored procedures. Ik vind het soms makkelijker om de query even in code bij de hand te hebben, en een query die normaal gesproken 2 of 3 records oplevert, dan ga je wel erg mierenneuken over een miliseconde tijds winst (maar ook dan probeer ik het wel in stored procs of views te doen, gewoon omdat het uiteindelijk imho makkelijker en overzichtelijker werkt, en als je nog eens hetzelfde moet doen vanuit bv een windowsapp i.p.v. een script, je dezelfde stored procs kunt gebruiken).

[PdeHoog]

Op dinsdag 23 april 2002 12:50 schreef blijhoofd_bennie het volgende:

[..]

Mijn collega hiero houd er de volgende manier op na (zo dacht ik er ook over)
- Wanneer mogelijk doe je zoveel mogelijk met SQL
- Dus views, berekeningen en foutcontrolles ook door de SQLserver laten doen.

Dit is de wijze waarop ik met zowel ASP (toch wel twee hele applicaties) als VB (veel meer) applicaties ontwikkel en ook de beste manier denk ik.

Ik ga dus volledig met je collega mee.

[blijhoofd_bennie]

Op dinsdag 23 april 2002 13:02 schreef Crazy_D het volgende:

[..]

Sommige queries voer ik wel vanuit code uit, maar voor het grootste deel gebruik ik stored procedures. Ik vind het soms makkelijker om de query even in code bij de hand te hebben, en een query die normaal gesproken 2 of 3 records oplevert, dan ga je wel erg mierenneuken over een miliseconde tijds winst (maar ook dan probeer ik het wel in stored procs of views te doen, gewoon omdat het uiteindelijk imho makkelijker en overzichtelijker werkt, en als je nog eens hetzelfde moet doen vanuit bv een windowsapp i.p.v. een script, je dezelfde stored procs kunt gebruiken).

Ok dat mierenneuken klopt, maar het is natuurlijk niet logisch een deel wel in stored procedures te doen en de andere niet. Maar jij doet het dan om gewoon de code bij de hand te hebben. Dat met die applicaties is ook een makkelijk onderdeel, maar ook makkelijker is het aanpassen natuurlijk (een wijziging is voldoende om je hele programma aan te passen). Maar dit laatste kun je in ASP ook opvangen door de strings op ee een apparte page te zetten.

Maar hoe vang jij foutcontroles op? doe je dat ook met SQL of laat je ASP checken op bijvoorbeeld wel invoer of juiste invoer?

[Crazy D]

Op dinsdag 23 april 2002 13:25 schreef blijhoofd_bennie het volgende:
Ok dat mierenneuken klopt, maar het is natuurlijk niet logisch een deel wel in stored procedures te doen en de andere niet. Maar jij doet het dan om gewoon de code bij de hand te hebben.

Tjah tis idd niet consequent, en ik probeer (en het gaat ook steeds beter ) om dat wel te zijn

Maar hoe vang jij foutcontroles op? doe je dat ook met SQL of laat je ASP checken op bijvoorbeeld wel invoer of juiste invoer?

Ik controleer sowieso de invoer (wel/niet numeriek, niet leeg, dat soort directe controles). Daarnaast is het afhankelijk van wat het precies is. Als er een paar velden bij zijn die in een andere tabel moeten voorkomen, wil ik die nog weleens alvast even controleren, zeker als de db niet altijd een duidelijke error geeft als die waarde niet klopt (of als je db brak is... :XExact:X). En uiteraard proberen de db errors af te vangen en om te toveren in een begrijpelijk iets voor de gebruiker

Verder moet ik veel met Sumatra werken (om Exact dos/btrieve bestanden te benaderen), behalve dat je daar geen stored procs mee kan maken, krijg je error voor error terug, wat uiteraard niet zo handig is. Dus dan moet je eigenlijk wel eerst controleren of bepaalde gegevens correct zijn, omdat het gewoon niet handig is voor de gebruiker om 10 keer op Bewaren te moeten klikken, en iedere keer te horen krijgt dat 1 veldje niet goed is...