Adodb.command parameter fejl

Du kan starte med at give et hint om hvilken fejl du oplever. Men mon dog at en email består af til og så vil adInteger i hver fald fejle - adVarChar lyder lidt mere korrekt og så har du bare 2 kommaer efter hinanden så der kunne du mangle en værdi, fx 100.

Personligt er jeg mere til navngivne parametre, se fx http://www.web-dev.dk/post/2008/07/14/SQL-injections-mere-end-bare-et-pling.aspx

Jeg har netop rettet det du har skrevet. den melder fejl ved linje 32 og skriver "Arguments are of the wrong type, are out of acceptable range, or are in conflict with one another."


   
mail = "test@test.dk"

Set chEmail = Server.CreateObject("ADODB.Command")
chEmail.ActiveConnection=conn
chEmail.Prepared = true
chEmail.commandtext="SELECT * FROM users WHERE email = @strEmail"
<-- ! linje 32 --->chEmail.Parameters.Append chEmail.CreateParameter("@strEmail", adVarChar, adParamInput, 20, mail) <-- ! -->
set rschEmail = chEmail.execute

response.write rschEmail("email") & rschEmail("password")

Jeg vil tro du kan slippe for denne fejl, hvis du bruger den korte form (som omtales i artiklen jeg henviste til i det andet spørgsmål du stillede):


NB: Jeg antager conn er et objekt, så derfor har jeg anvendt set til at tildele denne til ActiveConnection på command-objektet...

Min umiddelbare tanke er dog, at du mangler at referere til ADO-typelib (via METADATA i selve siden eller i global.asa), som beskrevet i starten af artiklen. Hvis dette er tilfældet, vil adVarChar og de andre konstanter ikke være kendt og værdien af disse derfor være empty (hvilket CreateParameter givetvis vil brokke sig over).

Er det dig eller eksperten der har ændret i antallet af parenteser?

Du havde ret at jeg ikke havde angivet typelib. Efter angivelsen af dette og dine tilrettelser fejlede den stadigvæk..

Så prøvede jeg din korte skrivning og pludselig virkede det? - er der en forklaring på det? - Den korte er trodsalt lettere men er den mere usikker, langsommere eller?

Fejlen opstår givetvis, fordi du har navngivet parameteren i din SQL-sætning (i det mindste i det indlæg, hvor du viser i hvilken linje fejlen opstår). Du skal, som i det første indlæg, anvende spørgsmålstegn som parameter-pladsholder.

Hvad angår den korte version, så er det usikkert hvad der sker, da jeg aldrig har undersøgt det. Jeg ser nogle forskellige muligheder. Umiddelbart kræver den korte version, at ADO laver noget arbejde for mig. Dette kunne være en eller flere af følgende:

* ADO foretager et opslag i databasen, for at hente skemaoplysninger om de data den skal arbejde med, inden det egentlige opslag foretages.

* ADO kalder blot med en generisk type og håber på det bedste.

* ADO foretager en typekonvertering af værdien og udleder en type, som den så bruger til parameteren.

Hvis du har en SQL Profiler, kan du evt. prøve at koble den til din database og udføre siden med forspørgslen for at se, hvad der sker på SQL Server...

Om der er langsommere eller ej, har jeg heller ikke testet på, men min intuition siger mig, at da mere arbejde er overladt til ADO, mon så ikke det koster lidt på performancesiden. Som altid er det jo en afvejning af behov og typisk er jeg villig til at betale den, formegentlig, ubetydelige ekstra omkostning det nok er, at lade ADO finde ud af parametertypen for mig, så jeg kan slippe for at skrive så meget (med mindre det er den første af mine forslag ovenfor - så vil jeg nok overveje, at bide i det sure æble og skrive lidt mere).

Det er naturligvis en helt anden snak, hvis vi taler sites med rigtig meget trafik, hvor hver eneste CPU-cycle er vigtig... men i sådanne tilfælde bruger man nok ikke længere ASP Classic og ADO, såeeeh... :-)