[SQL] Meerdere SELECTs in 1 Stored Procedure

[akakiwi]

Ik heb in SQL-Server 2000 een stored procedure welke er globaal zo uit ziet:

SQL:

CREATE PROCEDURE SP_Sys_TweakerTest
    (@GebruikersId INT)
AS
    SELECT G.* 
    FROM TBL_Gebruikers G 
    WHERE G.[Id] = @GebruikersId 
        AND G.DatumVerwijderd IS NULL

    IF @@ROWCOUNT = 0
    BEGIN
        SELECT 'Er is geen gebruiker gevonden'
    END
GO

Wanneer er geen gebruiker gevonden is, wil ik dat ALLEEN de tweede SELECT wordt teruggegeven, maar zoals het nu werkt worden beide SELECT resultaten teruggegeven.

Ik heb geen oplossing kunnen vinden voor dit probleem.

Weet iemand hoe ik zelf kan kiezen welke SELECT resultaten worden teruggegeven aan mijn ASP code??

[gorgi_19]

[ranzig]

SQL:

If Exists(SELECT G.ID FROM TBL_Gebruikers G WHERE G.[Id] = @GebruikersId AND DatumVerwijderd IS NULL)
Begin
   SELECT G.* 
    FROM TBL_Gebruikers G 
    WHERE G.[Id] = @GebruikersId 
        AND G.DatumVerwijderd IS NULL
End
Else
Begin
 SELECT 'Er is geen gebruiker gevonden'

End

[/ranzig]

MAar je kan in asp ook de recordsets (niet records) doorlopen. Kom je er 2 tegen, dan is het 2e het geval, anders het eerste. Ook kan je van je 1e recordset de recordcount opvragen in ASP; is deze 0, dan is sowieso het 2e het geval.

Ik vraag me af waarom je dat eigenlijk niet doet.

[ Voor 32% gewijzigd door gorgi_19 op 24-11-2003 11:09 ]

[P_de_B]

Waarom kijk je niet gewoon in de ASP code of er records gevonden zijn

If RecordSet.EOF THEN
'geen records gevonden

[akakiwi]

hmm...
Dat mag dus niet.

Zal inderdaad wel werken, maar is niet echt een oplossing die ik zoek.

@P_de_B:
Ik wil het liefste zo veel mogelijk slimmigheid in mijn stored procedures hebben zitten, zodat de code gewoon lekker dom resultaten op het scherm kan mikken.

[ Voor 46% gewijzigd door akakiwi op 24-11-2003 11:10 ]

[gorgi_19]

akakiwi schreef op 24 november 2003 @ 11:08:
hmm...
Dat mag dus niet.

Zal inderdaad wel werken, maar is niet echt een oplossing die ik zoek.

Waarom mag dat eigenlijk niet? Imho is de asp namelijk de plaats waar je dit soort grappen moet uithalen; niet je datalaag. Imho hoort de datalaag 'dom' te zijn en gewoon domweg de data op te halen en terug te geven wat ik vraag. M'n BLL mag vervolgens wat met die data gaan doen en het naar de PL sturen.

En waarom is dat niet de oplossing? Doet in principe toch precies wat jij wilt?

[ Voor 48% gewijzigd door gorgi_19 op 24-11-2003 11:12 ]

[whoami]

Kan je niets doen met RAISERROR oid?

[gorgi_19]

whoami schreef op 24 november 2003 @ 11:10:
Kan je niets doen met RAISERROR oid?

Kan je dan in het algemeen niet een outputparameter meegeven, met de status?

[akakiwi]

whoami schreef op 24 november 2003 @ 11:10:
Kan je niets doen met RAISERROR oid?

Nee, want er treed geen error op.
Het is alleen zo dat de eerste SELECT geen resultaten terug kan geven.
In dat geval moet er een tweede select worden uitgevoerd die een alternatieve set resultaten teruggeeft.

Overigens @Gorgi_19, werk ik met een component waar al mijn stored procedures in gaan. Het kan dus geen onderscheid maken tussen verschillende stored procedures, maar mikt alleen data op het scherm.

Bijvoorbeeld:
Aan het component wordt gevraagd een formulier op het scherm te zetten met daarin gebruikersgegevens.
Dat gaat dan als volgt.

ASP:

iId = request.querystring("Id")
set oForm = server.createobject("oPool.formulier")
oForm.maakFormulier("SP_Sys_Gebruikers" & iId)
response.write oForm.formulier

Maar, de functie maakFormulier kan ook worden aangeroepen voor bedrijfsgegevens, rechtengegevens, etc..
Maar, wanneer er geen resultaten worden teruggegeven, kan het niet zo zijn dat er altijd dezelfde melding naar de gebruiker wordt teruggegeven.
Ik wil dus dat ie op zijn/haar scherm krijgt:
"Er is geen gebruiker gevonden"
"Het bedrijf wat je zocht bestaat niet of is verwijderd"

Omdat ik binnen mijn stored procedure precies weet WAAROM een opgevraagd item niet wordt gevonden, wil ik de stored procedure ook de reden terug laten geven middels een recordset.

Ik hoop dat dit mijn vraag een beetje verduidelijkt.

[gorgi_19]

Dan zal die ranzige SP iig wel werken van mij

[P_de_B]

of dit:

code:

SELECT TOP 1 * FROM (
SELECT UserName, Bla, 1 as sort FROM Table WHERE Id = 1
UNION
SELECT 'Geen user gevonden', NULL, 2
)A ORDER BY Sort

Maar mag ik wel opmerken dat je helemaal op het verkeerde pad terecht bent gekomen?

[ Voor 9% gewijzigd door P_de_B op 24-11-2003 11:25 ]

[Jaspertje]

Kan je niet een aantal variabelen gebruiken die dan wat anders terug geven? Of krijg je dan ook een hele andere output terug?

SQL:

CREATE PROCEDURE SP_Sys_TweakerTest
    (@GebruikersId INT)
AS
DECLARE @ID int
    SELECT @ID = G.id 
    FROM TBL_Gebruikers G 
    WHERE G.[Id] = @GebruikersId 
        AND G.DatumVerwijderd IS NULL

    IF @@ROWCOUNT = 0
    BEGIN --Er is geen gebruiker gevonden
        SELECT @ID = Iets anders 
    END

Select @Id As ID
GO

[ Voor 75% gewijzigd door Jaspertje op 24-11-2003 11:27 ]

[gorgi_19]

P_de_B schreef op 24 november 2003 @ 11:24:
of dit:

code:

SELECT TOP 1 * FROM (
SELECT UserName, Bla, 1 as sort FROM Table WHERE Id = 1
UNION
SELECT 'Geen user gevonden', NULL, 2
)A ORDER BY Sort

Maar mag ik wel opmerken dat je helemaal op het verkeerde pad terecht bent gekomen?

Nadeel van jouw SP is alleen dat je 2 kolommen terugkrijgt, per definitie.. Ik weet niet of z'n component dat erg fijn gaat vinden. Echter, die van jou is wel iets sneller dan die van mij.

[SuperRembo]

Ik vind dit echt slimmigheid die je niet in SP's moet stoppen. Je moet nog steeds checken of je wel resultaten heb teruggekregen. Als je wel resultaten hebt toon je een tabel, als je geen resultaten hebt toon je geen tabel maar de mededeling dat je geen resultate hebt. Wat schiet je er dan mee op om die mededeling in je SP te bouwen?

offtopic:
Ondanks al de ranzigheid nog een tipje: je eigen procedures niet met "sp_" beginnen, maar met bijvoorbeeld "pr_".
MSDN:
It is strongly recommended that you do not create any stored procedures using sp_ as a prefix. SQL Server always looks for a stored procedure beginning with sp_ in this order:
1. The stored procedure in the master database.
2. The stored procedure based on any qualifiers provided (database name or owner).
3. The stored procedure using dbo as the owner, if one is not specified.
Therefore, although the user-created stored procedure prefixed with sp_ may exist in the current database, the master database is always checked first, even if the stored procedure is qualified with the database name.

[Verwijderd]

ik heb het idd ook gelezen in de documentatie echter als ik

code:

use master
go
create procedure sp_test as
select 'hello master'
go
use pubs
go
create procedure sp_test as
select 'hello pubs'
go
exec pubs..sp_test
exec pubs.dbo.sp_test
exec sp_test

krijg ik toch als uitkomst

code:

---------- 
hello pubs

(1 row(s) affected)

           
---------- 
hello pubs

(1 row(s) affected)

           
---------- 
hello pubs

(1 row(s) affected)

Of ik lees die docs verkeerd of ze kloppen gewoon niet (getest op mssql 2000)

[akakiwi]

@SuperRembo.

Mag ik vragen waarom je vind dat deze slimmigheid niet in de SP's moet zitten?? Ik vind het een beetje onzinnig om binnen de SP al te weten waarom data niet gevonden is (3 mogelijke redenen zijn: geen rechten, data verwijderd (DatumVerwijderd = GETDATE()), geen data aanwezig) en daarvoor in de code dan nog eens een reden te zoeken.

Wanneer ik elke SP op dezelfde manier de melding terug laat geven, kan het component daar gewoon keihard op checken en hoeft het component niet zelf nog eens te gaan kijken of de teruggegeven resultatenset wel klopt.

@Yarvieh: Wat je daar hebt opgeschreven klopt idd.
Maar, ik wil dus alleen die laatste SELECT terugkrijgen en de bovenste 2 gewoon negeren.

[ Voor 12% gewijzigd door akakiwi op 24-11-2003 11:56 . Reden: Commentaar op Yarvieh ]

[gorgi_19]

@Yarvieh: Hij doet het wel, maar het was wat trager, geloof ik.

[ Voor 9% gewijzigd door gorgi_19 op 24-11-2003 11:56 ]

[nescafe]

SuperRembo schreef op 24 november 2003 @ 11:37:
Ik vind dit echt slimmigheid die je niet in SP's moet stoppen.

offtopic:
[hk-mode]ik klikte [/hk-mode]

Laat HK replies maar voor in de HK ook.

[ Voor 15% gewijzigd door whoami op 24-11-2003 12:02 ]

[SuperRembo]

akakiwi schreef op 24 november 2003 @ 11:55:
@SuperRembo.

Mag ik vragen waarom je vind dat deze slimmigheid niet in de SP's moet zitten?? Ik vind het een beetje onzinnig om binnen de SP al te weten waarom data niet gevonden is (3 mogelijke redenen zijn: geen rechten, data verwijderd (DatumVerwijderd = GETDATE()), geen data aanwezig) en daarvoor in de code dan nog eens een reden te zoeken.

Ok, dan is er wat voor te zeggen. Maar dan lijkt het me handiger om het via een output parameter te doen.

[akakiwi]

Mag ik heel kinderachtig zijn??
Dat met die output variabele wil ik niet.
Ik vind dat het gewoon moet kunnen met statements in je SP.

Ik heb trouwens nog niets zinnigs gevonden, dus misschien kan het wel niet en moet ik idd met die OUTPUT parameter aan de slag.

[Brothar]

Je wilt, begrijp ik uit je TS, slechts 1 select laten doorlopen. De reden daarachter (zou ik ook willen) : tijdsbesparing.
Maar, logisch redenerend, kun je slechts weten óf er gebruikers met dat id bestaan, ná een query, of door een aanroep van je stored procedure met een id, die al op bestaan is gechecked met een query.
Conclusie: je gebruikt altijd 2 Select-statements.

[P_de_B]

Ik heb trouwens nog niets zinnigs gevonden, dus misschien kan het wel niet en moet ik idd met die OUTPUT parameter aan de slag.

Mag ik vragen waarom mijn reply niet zinnig was? Volgens mij precies wat je zoekt

[gorgi_19]

En in aanvulling op P_de_B: Wat is er verkeerd aan mijn SP? En ja het kan wel.

Mag ik vragen waarom je vind dat deze slimmigheid niet in de SP's moet zitten?? Ik vind het een beetje onzinnig om binnen de SP al te weten waarom data niet gevonden is (3 mogelijke redenen zijn: geen rechten, data verwijderd (DatumVerwijderd = GETDATE()), geen data aanwezig) en daarvoor in de code dan nog eens een reden te zoeken.

Waarom geen slimmigheid? Omdat daar in principe een database niet voor is gemaakt? Stel je wilt de data in een andere taal neerzetten? Je moet gebruik maken van een andere database?
Waarom denk je uberhaupt dat ze iets als N-tier hebben uitgevonden?
De enige reden dat ik me kan bedenken is dat het soms sneller is om gegevens te bewerken in een SP; dit gaat echter imho wel ten koste van de flexibiliteit.

En met die rechten; ik neem aan dat je maar met 1, misschien 2, users connect met je databank? Of geef je iedere gebruiker van je applicatie een eigen inlognaam voor SQL Server?

[ Voor 113% gewijzigd door gorgi_19 op 24-11-2003 15:18 ]

[akakiwi]

P_de_B schreef op 24 november 2003 @ 15:11:
[...]


Mag ik vragen waarom mijn reply niet zinnig was? Volgens mij precies wat je zoekt

Sorry, misschien begreep je me verkeerd of was mijn formulering niet helemaal correct.
Jou oplossing is zeker zinnig en ook wel een goede mogelijke oplossing, maar aangezien ik op dit moment niet met OUTPUT variabelen werk voorzie ik veel extra werk wanneer ik wel met OUTPUT variabelen ga werken en alle 184 SP's moet aanpassen.

Ik ben, voor zover dat nog niet duidelijk was, op zoek naar een standaard manier, zodat ik elke willekeurige recordset op dezelfde manier kan behandelen.

[P_de_B]

akakiwi schreef op 24 november 2003 @ 15:23:
[...]


Sorry, misschien begreep je me verkeerd of was mijn formulering niet helemaal correct.
Jou oplossing is zeker zinnig en ook wel een goede mogelijke oplossing, maar aangezien ik op dit moment niet met OUTPUT variabelen werk voorzie ik veel extra werk wanneer ik wel met OUTPUT variabelen ga werken en alle 184 SP's moet aanpassen.

Ik ben, voor zover dat nog niet duidelijk was, op zoek naar een standaard manier, zodat ik elke willekeurige recordset op dezelfde manier kan behandelen.

Misschien zou je de thread eens moeten lezen?

Ik gebruik nergens OUTPUT variabelen.

[akakiwi]

gorgi_19 schreef op 24 november 2003 @ 15:12:
En in aanvulling op P_de_B: Wat is er verkeerd aan mijn SP? En ja het kan wel.


[...]

Waarom geen slimmigheid? Omdat daar in principe een database niet voor is gemaakt? Stel je wilt de data in een andere taal neerzetten? Je moet gebruik maken van een andere database?
Waarom denk je uberhaupt dat ze iets als N-tier hebben uitgevonden?
De enige reden dat ik me kan bedenken is dat het soms sneller is om gegevens te bewerken in een SP; dit gaat echter imho wel ten koste van de flexibiliteit.

En met die rechten; ik neem aan dat je maar met 1, misschien 2, users connect met je databank? Of geef je iedere gebruiker van je applicatie een eigen inlognaam voor SQL Server?

Er komen tot 1000 gebruikers die van de database gebruik moeten maken, maar, let wel, het gaat om een webapplicatie. Binnen deze applicatie krijgen gebruikers rechten die IN de database zijn geregistreerd (TBL_Rechten, gekoppeld met TBL_Gebruikers).
Verder bestaat er maar 1 DATABASE GEBRUIKER, waar alle webgebruikers gebruik van maken.

[Crazy D]

akakiwi schreef op 24 november 2003 @ 11:55:
@SuperRembo.
Wanneer ik elke SP op dezelfde manier de melding terug laat geven, kan het component daar gewoon keihard op checken en hoeft het component niet zelf nog eens te gaan kijken of de teruggegeven resultatenset wel klopt.

Dan kun je ook simpelweg de EOF property bekijken.
if rs.eof then "geen gegevens gevonden"

[raptorix]

akakiwi schreef op 24 november 2003 @ 15:23:
[...]


Sorry, misschien begreep je me verkeerd of was mijn formulering niet helemaal correct.
Jou oplossing is zeker zinnig en ook wel een goede mogelijke oplossing, maar aangezien ik op dit moment niet met OUTPUT variabelen werk voorzie ik veel extra werk wanneer ik wel met OUTPUT variabelen ga werken en alle 184 SP's moet aanpassen.

Ik ben, voor zover dat nog niet duidelijk was, op zoek naar een standaard manier, zodat ik elke willekeurige recordset op dezelfde manier kan behandelen.

Goh, dus dat zou betekenen dat je in alle 184 sprocs een result moet krijgen
Sorry dat ik het zeg, maar dit is echt bad practice en ik adviseer je ten stelligste een structurele aanpak voor je probleem te vinden. Imo is Raise Error nog het minst ranzige maar eigenlijk niet te prefereren bij lege recordsets