Generelt set bør du erklære dine variable i den kontekst du skal bruge dem, dvs. helt konkret bør du erklære cmd i commandCreateText for at undgå evt. konflikter med globale cmd-variable. Dette er ikke en decideret fejl, men det er en potentiel fejlkilde (som er svær at finde når den opstår!) og det kan man ligeså godt undgå, når nu det er så let :-)
Overvej f.eks. dette eksempel (med udgangspunkt i din nuværende implementering af commandCreateText):
set cmd = commandCreateText("select * from tabel where id=?")
set cmd2 = commandCreateText("select * from tabel2")
for i = 1 to 100
cmd.Execute(, array(i))
next
Hvilken tabel tror du cmd slår op i når cmd.Execute kaldes (hvis altså den ikke ligefrem fejler fordi den command der rent faktisk udføres jo ikke tager nogle parametre... HINT! ;-)???
Dette er et fuldstændig legalt scenarium, hvis du skal arbejde med batchoperationer hvor der kaldes til databasen i en løkke, da det sparer nogle resurser, fordi der ikke skal oprettes nye command-objekter for hvert kald...
Umiddelbart er der ikke lige noget der springer i øjnene som fejl, men jeg vil dog gerne vide hvor userTable-variablen kommer fra? Hvis det er en konstant du har defineret i koden, så fair nok... hvis det er en værdi som genereres på grundlag af udefrakommende input, så er det et potentielt sikkerhedshul.
At du kan kalde cmd.Execute med en parameterliste uden at angive parametertyper osv. skyldes givetvis (jeg er ikke helt sikker på hvad der rent faktisk sker), at ADO selv tolker på, hvilke felttyper der arbejdes med i SQL-sætningen. Dvs. er feltet, som parameteren sammenlignes med i SQL-sætningen, en varchar, så forventer ADO en streng (eller en værdi der kan konverteres til en streng med de, i VBScript, gængse typekonverteringsregler).
Grunden til at du skal kalde Execute med et komma først (hvis du ikke angiver nogen første parameter) er, at execute rent faktisk tager 3 (valgfrie) parametre. Dette betyder i VBScript, at du kan undlade at angive nogen værdi for paremeteren i kaldet. Så hvis du kun vil angive en værdi til anden parameter, skal du indikere dette overfor VBScript og det gøres ved at angive et komma...
Jf. dokumentationen af Command.Execute (
http://msdn.microsoft.com/en-us/library/ms681559(v=VS.85).aspx) forventes der et array af værdier i parameterlisten (anden parameter til Execute), så om det rent faktisk fungerer at sende en konkret værdi må være et spørgsmål om at teste det. Jeg plejer at sende arrays...
Grunden til at du får fejlen med paranteser ved kald af sub er, at VBScript ikke tillader dette, når du kalder subs og funktioner... med mindre du kun sender én parameter (det vil jeg dog ikke anbefale med mindre du 100% ved hvad du gør), f.eks.
testFunc(vaerdi)
eller at du foranstiller kaldet med kommandoen call, f.eks.
call cmd.Execute(, array(session("id")))
Personligt foretrækker jeg at benytte call, da det giver et mere konsistent (og normalt) udseende funktionskald - i det mindste når man er vant til at kode i andre sprog end VBScript...