[ASP/SQL] Dynamische variabelen in functie

[Mephix]

Ik wil een functie maken waarbij ik een string (SQL Query) op kan geven en een string wat de naam moet worden van het recordset waar het resultaat in komt.

Ik dacht aan het volgende, maar krijg een foutmelding Cannot use parentheses when calling a Sub.

code:

Dim dbConn
Set dbConn = Server.CreateObject("ADODB.Connection")
dbConn.ConnectionString = "deHeleZooi"
dbConn.Provider = "SQLOLEDB"
dbConn.Open

Public Function queryDB(strQuery, strRecordSet)
  Execute("Dim " & strRecordSet)
  Execute("Set " & strRecordSet & " = Server.CreateObject(""ADODB.RecordSet"")")
  dbConn.Execute strQuery
  Execute(strRecordSet & ".Open strQuery, dbConn")
End Function

strQuery = "SELECT * FROM pageorder ORDER BY positionRow, positionColumn"
queryDB(strQuery, "rsResult")

Ik zou hierna dus over moeten houden een RecordSet genaamd 'rsResult' met als inhoud het resultaat van de query zoals die in strQuery staat.

Iemand een helder idee ?

[gorgi_19]

Als je echt met deze methodiek door wilt gaan, zul je eens moeten kijken naar eval.

[Mephix]

Mja dat gebruikte ik eerst. Maar volgens mij is Eval hier niet op zijn plaats. Wanneer ik Dim Eval(strRecordSet) gebruik, krijg ik gezeur over het gebruik van integers enso. Volgens mij werkt Eval hier ff anders dan in bijv. javascript.

Hoewel ik op sommige sites ook wel lees dan Eval(varNaam) gewoon de waarde van de variabele naam terug geeft. Het zou dus daarmee wel moeten kunnen. Andere sites heb ik gezien met Execute om dit soort gingen voor elkaar te krijgen.

[Verwijderd]

Vervang regel 15 door

ASP:

Call queryDB(strQuery, "rsResult")

of

ASP:

queryDB strQuery, "rsResult"

en deze foutmelding als sneeuw voor de zon moeten laten verdwijnen.

Helaas krijg je dan volgens mij nog niet het gewenste resultaat. Ik vermoed namelijk dat de variabele die het RecordSet object zal bevatten alleen binnen de scope van de functie queryDB zal bestaan.

Al een stuk netter en met vrijwel vergelijkbare functionaliteit:

ASP:

Dim dbConn
Set dbConn = Server.CreateObject("ADODB.Connection")
dbConn.ConnectionString = "deHeleZooi"
dbConn.Provider = "SQLOLEDB"
dbConn.Open

Public Function queryDB(strQuery)
  Dim rsLocal
  Set rsLocal = Server.CreateObject("ADODB.RecordSet")
  rsLocal.Open strQuery, dbConn
  Set queryDB = rsLocal
End Function

strQuery = _
  "SELECT * FROM pageorder " & _
  "ORDER BY positionRow, positionColumn"
rsResult = queryDB(strQuery)

[ Voor 6% gewijzigd door Verwijderd op 14-12-2003 19:24 ]

[Mephix]

Verwijderd schreef op 14 december 2003 @ 19:23:
Helaas krijg je dan volgens mij nog niet het gewenste resultaat. Ik vermoed namelijk dat de variabele die het RecordSet object zal bevatten alleen binnen de scope van de functie queryDB zal bestaan.

Inderdaad.. ik kan natuurlijk buiten de functie nog wel een recordset declareren, maar dan komen er weer 2 regels bij en dat is nou niet echt de bedoeling van de functie.

Maar kun je binnen een functie niet gewoon een variabele declareren die daarbuiten ook te gebruiken is? Sorry, ben een php-er maar moet het dit keer ff met asp doen.

Hoe doen jullie zoiets normaal dan ? Ik neem toch aan dat je functies gebruikt voor het halen van gegevens uit een database.

[ Voor 10% gewijzigd door Mephix op 14-12-2003 21:36 ]

[Jaspertje]

Waarom zorg je er niet voor dat je functie een array teruggeeft met de goede waardes erin?

Zodat je hetvolgende krijgt:

ASP:

Dim dbConn
Set dbConn = Server.CreateObject("ADODB.Connection")
dbConn.ConnectionString = "deHeleZooi"
dbConn.Provider = "SQLOLEDB"
dbConn.Open

sub SQL(SQLStatement)

Set rs = DBConn.execute(SQLStatement)
SQL = rs.getrows
Set rs = Nothing

end sub

dim q
q = GetSQL(SQL)

Ik weet niet of het werkt maar dit moet lijkt mij kunnen.. paar opmerkingen:
- Sub van gemaakt, dan kan je de DBConn gebruiken en maak je die per pagina een keer aan
- Ik weet niet of "q" ook een Set moet hebben, lijkt mij dat dat een array wordt.

[majornono]

mijn voorkeur zou toch uitgaan van de manier die Mr. X al toonde.
In onze webapplicatie hebben we 1 globale stringvariabele die we gebruiken om sql in te zetten.
Daarnaast gebruiken we 2 globale recordset variabelen waarin het resultaat in wordt opgeslagen, maken we meerdere aan als we er meer nodig hebben. Maar in principe is 2 genoeg, ander moet de sp die we aanroepen maar betere resultaten opleveren.

De Exec zou ik eigenlijk ook nooit gebruiken in ASP. Moeilijk debuggen en performance-technisch schijnt dit ook niet al te best zijn, al heb ik dit nog niet merkbaar gehad.

[Jaspertje]

majornono schreef op 14 december 2003 @ 22:45:
mijn voorkeur zou toch uitgaan van de manier die Mr. X al toonde.
In onze webapplicatie hebben we 1 globale stringvariabele die we gebruiken om sql in te zetten.
Daarnaast gebruiken we 2 globale recordset variabelen waarin het resultaat in wordt opgeslagen, maken we meerdere aan als we er meer nodig hebben. Maar in principe is 2 genoeg, ander moet de sp die we aanroepen maar betere resultaten opleveren.

De Exec zou ik eigenlijk ook nooit gebruiken in ASP. Moeilijk debuggen en performance-technisch schijnt dit ook niet al te best zijn, al heb ik dit nog niet merkbaar gehad.

Moeilijk debuggen? Waarom ik heb er weinig problemen mee? En qua performance? ik zou het niet weten, zou kunnen denk dat het ook heel erg ligt aan de complexiteit van de query, en dan zou je er misschien voor kunnen kiezen om stored procedures te maken?

[Mephix]

majornono schreef op 14 december 2003 @ 22:45:
In onze webapplicatie hebben we 1 globale stringvariabele die we gebruiken om sql in te zetten.
Daarnaast gebruiken we 2 globale recordset variabelen waarin het resultaat in wordt opgeslagen, maken we meerdere aan als we er meer nodig hebben.

Dit is natuurlijk een manier en zo zijn er vele manieren. Maar ik ben gewend mijn recordsets namen te geven die logisch zijn. Ik heb liever geen vooraf gedeclareerde recordsets die rs1 en rs2 heten ofso.

Ik kan het ook gewoon niet hebben dat dit zo moeilijk moet in ASP. Misschien dat ik gewoon moet accepteren dat je voor iedere query die je uit wil voeren gewoon een regel of 5-10 code nodig hebt

Jaspertje schreef op 14 december 2003 @ 22:41:
Waarom zorg je er niet voor dat je functie een array teruggeeft met de goede waardes erin?

Dit ga ik eens nader bekijken. Dit zal dan ook een 2 dimensionale array moeten worden, omdat er meerdere records als resultaat zijn. Hopen dat ik dat dan weer middels een return value uit die functie weet te wurmen

[ Voor 24% gewijzigd door Mephix op 15-12-2003 09:03 ]

[majornono]

Jaspertje schreef op 14 december 2003 @ 23:49:
[...]


Moeilijk debuggen? Waarom ik heb er weinig problemen mee? En qua performance? ik zou het niet weten, zou kunnen denk dat het ook heel erg ligt aan de complexiteit van de query, en dan zou je er misschien voor kunnen kiezen om stored procedures te maken?

Moeilijk debuggen is in dit geval niet helemaal juist. Maar in meer complexere situaties bijv. een exec van een functie uitvoeren die in een include gedefinieerd staat geeft geen foutmelding op de functie maar op de exec regel.

Met de performance doelde ik niet op de complexiteit van de query, dan moet je idd. gewoon een SP gebruiken. Maar het schijnt dat de exec zelf qua performance niet erg fijn is. Ook maar van horen zeggen, ik gebruik het ook en heb het nog niet echt gemerkt...

[majornono]

[quote]Mephix schreef op 15 december 2003 @ 09:01:

Dit is natuurlijk een manier en zo zijn er vele manieren. Maar ik ben gewend mijn recordsets namen te geven die logisch zijn. Ik heb liever geen vooraf gedeclareerde recordsets die rs1 en rs2 heten ofso.

Ik kan het ook gewoon niet hebben dat dit zo moeilijk moet in ASP. Misschien dat ik gewoon moet accepteren dat je voor iedere query die je uit wil voeren gewoon een regel of 5-10 code nodig hebt

[...]

ASP is gewoon niet zo'n geavanceerde taal als PHP. Je komt voortdurend beperkingen tegen waar je gewoon mee moet leren leven/werken.

Als je logische namen voor je recordsets wilt gebruiken dan moet je hem iedere keer opnieuw definieren. Dan kies ik idd liever voor het gebruik van rs1 en rs2, maar nummeren zou ik dan nog niet doen.

[gorgi_19]

ASP is gewoon niet zo'n geavanceerde taal als PHP. Je komt voortdurend beperkingen tegen waar je gewoon mee moet leren leven/werken.

ASP is niet eens een taal. Ik snap alleen niet als mensen zo een probleem hebben met VBSCript, waarom men niet grijpt naar de combinatie van JSCript / ASP of PERL / ASP.

[Jaspertje]

Mephix schreef op 15 december 2003 @ 09:01:


[...]

Dit ga ik eens nader bekijken. Dit zal dan ook een 2 dimensionale array moeten worden, omdat er meerdere records als resultaat zijn. Hopen dat ik dat dan weer middels een return value uit die functie weet te wurmen

Als je Set rs = Conn.execute() doet

en daarna bla = rs.getrows()

dan staat alles erin en niet een record!! (mits je query een record terug geeft natuurlijk )

[gorgi_19]

majornono schreef op 15 december 2003 @ 09:12:
Met de performance doelde ik niet op de complexiteit van de query, dan moet je idd. gewoon een SP gebruiken. Maar het schijnt dat de exec zelf qua performance niet erg fijn is. Ook maar van horen zeggen, ik gebruik het ook en heb het nog niet echt gemerkt...

Een SP is niet per se noodzakelijk; parametrized queries in het algemeen kunnen ook al voor een enorme performanceboost zorgen.

Je hoeft dus niet alle SQL Statements als SP te schrijven alleen vanuit performance-oogpunt.

[majornono]

gorgi_19 schreef op 15 december 2003 @ 09:27:
[...]

Een SP is niet per se noodzakelijk; parametrized queries in het algemeen kunnen ook al voor een enorme performanceboost zorgen.

Je hoeft dus niet alle SQL Statements als SP te schrijven alleen vanuit performance-oogpunt.

klopt.