[MSSQL] Query true of false waarde ophalen

[Friedchicken]

Ik heb een form die gegevens netjes wegschrijft in de DB(MSSQL). Naast die 2 invoervelden wordt er ook een filegeupload en gerenamed aan de hand van de ingevulde waarden.

Nu wil ik er voor zorgen dat de gebruiker niet 2x hetzelfde kan invoeren c.q. uploaden (upload script overschrijft bestand dan). Een invoerveld week en een invoerveld jaar. Nu moet bij de knop opslaan gekeken worden of de ingevoerde waarden voorkomen in de database. Het liefts zie ik de uitkomst als 1= True en staat dus in DB of 0=False en staat niet van in DB en gaat door met het uploaden.

Ik heb namelijk al wat dingen geschreven die afhangen weer van de waarde 1 of 0.

Wie zou mij even een schopje in de goede richting kunnen geven om dus waarde 1 of 0 te krijgen als variabelen al in de DB staan of niet.

[whoami]

code:

SELECT ISNULL(COUNT(1) , 0 ) FROM tabel WHERE ...

[Icey]

http://nl2.php.net/empty

Kijken of iets leeg is, of juist niet leeg is en daar komt uiteindelijk weer een true of false uit.

Bedoel je zoiets?

[whoami]

Icey schreef op maandag 18 april 2005 @ 16:43:
http://nl2.php.net/empty

Kijken of iets leeg is, of juist niet leeg is en daar komt uiteindelijk weer een true of false uit.

Bedoel je zoiets?

Dat gaat over PHP.
AFAIK heeft de TS nergens vermeld dat ie met PHP werkt..... Er zijn ook nog andere programmeertalen enzo.

[Friedchicken]

Euh, sorry het is ASP.NET met MSSQL
Draait op win2003 machine

[whoami]

Met SQL kan je dus checken of er al een record is met de waarden die jij hebt.... (zie m'n eerste post).

Die query kan je uitvoeren dmv een SqlCommand object, waarvan je de executescalar method oproept.

[stp_4]

Je zou gebruik kunnen van een output parameter vanuit een stored procedure die true of false teruggeeft, maar ik denk dat dit misschien wel iets buiten de scope valt..

[Friedchicken]

Ik heb even het volgende gedaan,

Heb de volgende query gebruikt
in vb code page:

code:

   Dim test As String = "SELECT ISNULL(COUNT(1) , 0 ) FROM nieuwsbrieven WHERE week = " & week & " and jaar = " & jaar & ""
        Dim cmdTest As SqlCommand = New SqlCommand(test, connectie)

    connectie.Open()

              Response.Write(test)

        connectie.Close()

ik krijg netjes terug de waardes uit het formulier (aan het hoofd van de pagina). Alleen als ik naar SQL Enterprise Manager ga, om query daadwerkelijk uit te voeren, krijg ik terug Exp1 met getal 34 en geen waarde 1 of 0...

[P_de_B]

Omdat hij weergeeft hoeveel records er zijn, je kunt in je clientcode testen op > 0. Anders moet je een query gebruiken met EXISIST, of bijvoorbeeld met CASE. Maar ik zou gewoon in de clientcode testen op 0 of op > 0

[Friedchicken]

tuurlijk stom van me, dit gaat wel werken iig nu, want hij komt nu 1x voor heb even wat deleted, en meer invoeren gaat simpelweg gewoon niet straks, dus dat is mooi
toppie en bedankt

[Friedchicken]

En we gaan weer verders

Het maken van de juiste query en die in SQL Enterprise manager runnen is gelukt, nu moet ik alleen die gegevens in mijn pagina gaan lezen. Dus of 1 of 0

Ik ben met een datareader bezig om gegevens uit te lezen deze ziet er als volgt uit:

code:

Dim Bestaan As String = "SELECT ISNULL(COUNT(1), 0) AS uitkomst FROM nieuwsbrieven WHERE week = " & week & " AND jaar = " & jaar & ""

        Dim cmdBestaan As SqlCommand = New SqlCommand(Bestaan, connectie)
        Dim dtrBestaan As SqlDataReader = cmdBestaan.ExecuteReader()

        dtrBestaan.Read()

        Response.Write(dtrBestaan.GetSqlString(0).Value)

        dtrBestaan.Close()

Ik krijg alleen de volgende error:
Details van uitzondering: System.IndexOutOfRangeException: De index ligt buiten de matrixgrenzen.


Response.Write(dtrBestaan.GetSqlString(0).Value)

De null in bovenstaande response.write moet toch de gegevens ophalen van de eerste rij of ben ik achterlijk ? De eerste rij die je ook in sql enterprise manager krijgt als je netjes query uitvoert daar.....

[whoami]

Waarom doe je GetSqlString en gebruik je niet de gewone indexer of de 'gewone' methods?
Waarom gebruik je trouwens een datareader, en niet de ExecuteScalar method van het command object?

* whoami zwijgt verder ook maar over sql injection en parametrized queries.

ps: null != 0.

[Friedchicken]

En de oplossing:

code:

dtrBestaan.Read()

        Response.Write(dtrBestaan.GetValue(0))

        dtrBestaan.Close()

P.S. ik gaat eerst maar meer pielen voordat ik hier loop te spammen

whoami thnx, voor de hulp
Kben nu ander halve week bezig met ASP.NET VB en MSSQL maar het is echt wel kikke !

[ Voor 22% gewijzigd door Friedchicken op 18-04-2005 21:25 ]

[whoami]

PS: maak die site ook maar veilig genoeg als je de url hier gaat pasten, want anders is je DB voor je het weet leeg.

[Friedchicken]

URL wordt niet gepasted

Mgoed wat betreft SQL injection, daarmee moet je toch eerst op de pages komen ?
Voor iedere page is login vereist, wat opgehaald wordt uit session ID, maatje van me schrijft rechten gedeelte en beveiliging

[whoami]

Friedchicken schreef op maandag 18 april 2005 @ 21:37:
URL wordt niet gepasted

Mgoed wat betreft SQL injection, daarmee moet je toch eerst op de pages komen ?

Ja, en dan ?
Het risico blijft.

Voor iedere page is login vereist, wat opgehaald wordt uit session ID, maatje van me schrijft rechten gedeelte en beveiliging

Hij maakt toch wel gebruik van de functionaliteit die door .NET geboden wordt, hoop ik.

[ Voor 32% gewijzigd door whoami op 18-04-2005 22:41 ]

[NMe]

Friedchicken schreef op maandag 18 april 2005 @ 21:37:
URL wordt niet gepasted

Mgoed wat betreft SQL injection, daarmee moet je toch eerst op de pages komen ?
Voor iedere page is login vereist, wat opgehaald wordt uit session ID, maatje van me schrijft rechten gedeelte en beveiliging

Beter teveel beveiliging dan te weinig. Stel, iemand werkt om je beveiliging heen. Dan kan ie, als je je spul niet goed beveiligd hebt, in principe alles. Beveilig je wel gewoon alles (wat gewoon good practice is, IMO), dan heb je al een heel risico minder wat betreft de toegankelijkheid van je database.

[Verwijderd]

Friedchicken schreef op maandag 18 april 2005 @ 21:08:

Het maken van de juiste query en die in SQL Enterprise manager runnen is gelukt, nu moet ik alleen die gegevens in mijn pagina gaan lezen. Dus of 1 of 0

code:

Dim Bestaan As String = "SELECT ISNULL(COUNT(1), 0) AS uitkomst FROM nieuwsbrieven WHERE week = " & week & " AND jaar = " & jaar & ""

        Dim cmdBestaan As SqlCommand = New SqlCommand(Bestaan, connectie)
        Dim dtrBestaan As SqlDataReader = cmdBestaan.ExecuteReader()

        dtrBestaan.Read()

        Response.Write(dtrBestaan.GetSqlString(0).Value)

        dtrBestaan.Close()

Onderstaande code is in ieder geval beter dan wat je nu hebt.

code:

Dim Bestaan As String = "SELECT COUNT(*) AS uitkomst FROM nieuwsbrieven WHERE week = " & week & " AND jaar = " & jaar & ""

        Dim obj as object = nothing
        Dim waarde as integer = 0
        Dim cmdBestaan As SqlCommand = connectie.CreateCommand(Bestaan)
        try
          obj = cmdBestaan.ExecuteScalar()
          if not (waarde is system.dbnull.value) then waarde = convert.toint32(obj)
        finally
          cmdBestaan.dispose()
        end try

        Response.Write(waarde.tostring())

[ Voor 8% gewijzigd door Verwijderd op 19-04-2005 22:20 ]

[whoami]

^^
jouw code is nog altijd niet veilig.

[Friedchicken]

Want ?

Je had het daarstraks over het gebruik maken van ASP.NET codes en die van mij zijn relatief simpel opgezet.

Het betreft wel een gesloten systeem, dus geen website die vrij toegang geeft voor alles en iedereen.
Is ook geen excuses om steken te laten vallen betreft de beveiliging..

Onderstaande code is in ieder geval beter dan wat je nu hebt.

Het gebruik maken van meer ASP.NET "standaard" codes verhoogt veiligheid ?

[ Voor 21% gewijzigd door Friedchicken op 19-04-2005 09:31 ]

[P_de_B]

Friedchicken schreef op dinsdag 19 april 2005 @ 09:31:
Want ?

Je had het daarstraks over het gebruik maken van ASP.NET codes en die van mij zijn relatief simpel opgezet.

Het betreft wel een gesloten systeem, dus geen website die vrij toegang geeft voor alles en iedereen.
Is ook geen excuses om steken te laten vallen betreft de beveiliging..

Google maar eens op SQL Injection: [google= sql injection]

[Friedchicken]

Google maar eens op SQL Injection: zoeken bij google naar 'sql injection'

Daar is in ieder geval zeker rekening gehouden bij de login, er is geen sql injection toepasbaar daar.

[whoami]

Friedchicken schreef op dinsdag 19 april 2005 @ 09:33:
Google maar eens op SQL Injection: zoeken bij google naar 'sql injection'

Daar is in ieder geval zeker rekening gehouden bij de login, er is geen sql injection toepasbaar daar.

Hoe ben je dat zo zeker ?

[whoami]

klik

[P_de_B]

Friedchicken schreef op dinsdag 19 april 2005 @ 09:33:
Google maar eens op SQL Injection: zoeken bij google naar 'sql injection'

Daar is in ieder geval zeker rekening gehouden bij de login, er is geen sql injection toepasbaar daar.

Dit hoeft niet alleen bij de login pagina een probleem te zijn. Elke pagina die hier kwetsbaar voor is, kan in principe je hele db op straat leggen.

[stp_4]

Om onder andere sql injection tegen te gaan, zou ik gebruik maken van stored procedures waarin je kan werken met parametrized queries.

[ Voor 3% gewijzigd door stp_4 op 19-04-2005 09:56 ]

[gorgi_19]

stp_4 schreef op dinsdag 19 april 2005 @ 09:52:
Om onder andere sql injection tegen te gaan, zou ik gebruik maken van stored procedures waarin je kan werken met parametrized queries.

Je hebt geen SP's nodig om gebruik te maken van parametrized queries

[stp_4]

gorgi_19 schreef op dinsdag 19 april 2005 @ 09:53:
[...]

Je hebt geen SP's nodig om gebruik te maken van parametrized queries

Dat zeg ik er toch niet bij?

[P_de_B]

stp_4 schreef op dinsdag 19 april 2005 @ 09:55:
[...]


Dat zeg ik er toch niet bij?

Wat zijn dan je argumenten voor het gebruik van sp's?

Niet om je aan te vallen hoor, maar de argumenten voor het gebruik van sp's zijn de laatste jaren aardig verwaterd. Zie ook:[rml][ ALG] zeg nee tegen Stored Procedures *[/rml]

[ Voor 16% gewijzigd door P_de_B op 19-04-2005 09:58 . Reden: verkeerde link ]

[stp_4]

- tegengaan injection ( beveiling )
- onderhouds vriendelijker ( geen code te builden bijvoorbeeld )
- sp's worden uitgevoerd op de server ipv dat berichten uitgewisseld tussen client

Dit zijn onder andere de redenen waarom ik gebruik maak van sp's.

[P_de_B]

stp_4 schreef op dinsdag 19 april 2005 @ 10:06:
- tegengaan injection ( beveiling )
Kan ook met parameterized queries, whoami geeft geheid nog de link

- onderhouds vriendelijker ( geen code te builden bijvoorbeeld )
Als je de data access code in een aparte data access layer hebt, of werkt met een ORM mapper ook

- sp's worden uitgevoerd op de server ipv dat berichten uitgewisseld tussen client
Dit begrijp ik niet helemaal, het is wel zo dat voor bepaalde intensieve queries misschien een sp beter is. Voor de gewone CRUD operaties iig niet.
Dit zijn onder andere de redenen waarom ik gebruik maak van sp's.

[stp_4]

Die laatste daar bedoel ik mee dat elke keer als de client een query uitvoert, de database server gedwongen is de querie te recompilen. Met een sp is dat niet zo. Ik bedoel er eigenlijk performance winst mee. Maar goed, voor iedereen kan de keuze anders liggen.

[ Voor 13% gewijzigd door stp_4 op 19-04-2005 10:20 ]

[P_de_B]

stp_4 schreef op dinsdag 19 april 2005 @ 10:19:
Die laatste daar bedoel ik mee dat elke keer als de client een query uitvoert, de database server gedwongen is de querie te recompilen. Met een sp is dat mij niet zo. Ik bedoel er eigenlijk performance winst mee.

Vanaf versie 2000 is dat geen issue meer. Het is niet zozeer het recompilen dat tijd kost, maar het bepalen van het executieplan. Dat executieplan wordt ook gecached bij geparameterizeerde queries, niet alleen bij sp's. Performancewinst is er niet.

[whoami]

Ik denk niet dat het hier de bedoeling is om SP vs PQ te gaan doen.

SP's hebben hun voordelen, PQ's ook; echter, het is niet zo dat je SP's nodig hebt om op een veilige manier data access te doen.
SP's hebben wel degelijk performance winst als je daarin een 'data intensieve' operatie kunt plaatsen, waardoor je een paar roundtrips naar de server kunt besparen. Echter, dan wil dat meestal zeggen dat je BL in je DB gaat verweven, en da's dan ook weer iets....

[whoami]

stp_4 schreef op dinsdag 19 april 2005 @ 09:52:
Om onder andere sql injection tegen te gaan, zou ik gebruik maken van stored procedures waarin je kan werken met parametrized queries.

Dit begrijp ik niet goed....

[stp_4]

whoami schreef op dinsdag 19 april 2005 @ 10:44:
[...]


Dit begrijp ik niet goed....

Ik bedoel meer dat ik geen parametrized queries vanuit mn code gebruik maar ik roep sp's aan met variabelen. Het tegengaan van injection als reden is ooit vroeger ontstaan omdat ik geen gebruik maakte van parametrized queries. Dat het woord kan dik gedruk stond was omdat iemand dacht ik bedoelde dat je een sp nodig hebt om met parametrized queries te werken.

[Verwijderd]

whoami schreef op dinsdag 19 april 2005 @ 08:42:
^^
jouw code is nog altijd niet veilig.

Dat moet FriedChicken zelf maar oplossen.

Friedchicken schreef op dinsdag 19 april 2005 @ 09:31:

Je had het daarstraks over het gebruik maken van ASP.NET codes en die van mij zijn relatief simpel opgezet.

Het betreft wel een gesloten systeem, dus geen website die vrij toegang geeft voor alles en iedereen.
Is ook geen excuses om steken te laten vallen betreft de beveiliging..

Onderstaande code is in ieder geval beter dan wat je nu hebt.

Het gebruik maken van meer ASP.NET "standaard" codes verhoogt veiligheid ?

Er was al door iemand anders iets gezegd over de veiligheid. Ik heb hier geen aandacht aan besteed.
Dit is gewoon ranzig programmeren. Ze hebben niet voor niets try ... finally, etc. ingevoerd.
Zet desnoods dtrBestaan.Close() in het finally-block

[D4Skunk]

ik kan me vergissen, maar vroeger was

SQL:

select count(*) from tabel

trager dan

SQL:

select count(1) from tabel

IMHO

Het zou natuurlijk kunnen dat dit db-specifiek was, en enkel voor oudere versies geldt...

[ACM]

Als je er trouwens een boolean uitwilt (aka als er één of meer is, dan true anders false) kan je natuurlijk ook nog gewoon zoiets doen:

code:

SELECT count(*) > 0 FROM ...

Overigens hoef je niet te testen of count(*) null is, want dat is ie per definitie niet, altijd 0 (geen records die voldeden) of meer.

[P_de_B]

D4Skunk schreef op dinsdag 19 april 2005 @ 18:41:
ik kan me vergissen, maar vroeger was

SQL:

select count(*) from tabel

trager dan

SQL:

select count(1) from tabel

IMHO

Het zou natuurlijk kunnen dat dit db-specifiek was, en enkel voor oudere versies geldt...

Klopt, als je (*) gebruikt kan de queryengine zelf bepalen welke index hij kan gebruiken, dit kan wat snelheidswinst opleveren.

[whoami]

ACM schreef op dinsdag 19 april 2005 @ 19:13:
Als je er trouwens een boolean uitwilt (aka als er één of meer is, dan true anders false) kan je natuurlijk ook nog gewoon zoiets doen:

code:

SELECT count(*) > 0 FROM ...

Overigens hoef je niet te testen of count(*) null is, want dat is ie per definitie niet, altijd 0 (geen records die voldeden) of meer.

Hmm, ja, da's waar.
Ik had die ISNULL daar gezet omdat ik een SUM() in m'n gedachten had.