But, you can create function based indexes, which will avoid full table
scans.
Cheers
Martin
On 04/05/2010 17:01, Martin Gainty wrote:
Martin is correct
in oracle using functions on a where clause will automatically trigger FTS
(full table scans) which will slow your query down to a crawl as it has to read
EVERY record
good call on using parameters then bind_param
thanks,
martin
______________________________________________
Jogi és Bizalmassági kinyilatkoztatás/Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Ez az
üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy
jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának
készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és
semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek
könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet
ezen üzenet tartalma miatt.
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung.
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est
interdite. Ce message sert à l'information seulement et n'aura pas n'importe
quel effet légalement obligatoire. Étant donné que les email peuvent facilement
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
Date: Tue, 4 May 2010 16:22:19 +0100
From: martin.ev...@easysoft.com
To: lvir...@gmail.com
CC: dbi-users@perl.org
Subject: Re: Trying to safely compare user input name against database
Larry W. Virden wrote:
I've a case where a function is called with a string provided by a
user, and some legacy code then puts that string into a select
statement for dbi. The code currently reads:
my ($query) = $dbconn->prepare(
"Select * from my_table where last_name LIKE
'$SearchName'");
$query->execute() or return \...@retval; #problem return empty array
Now, one of the issues that comes up is the situation where the user's
string doesn't match the case of the name in the table.
For instance, if they pass a "McDonnel" as the string, but in the
table, it is "Mcdonnel", of course there is no match.
So, I was thinking of modifying this to read
my ($query) = $dbconn->prepare(
"Select * from my_table where UPPER(last_name) LIKE
UPPER('$SearchName')");
Are there any gotchas in going this route? Is there a better way of
doing this?
I'd really avoid concatenating user supplied strings into your SQL. Use
parameters instead:
select * from my_table where last_name like ?
then use bind_param or exeute(my_parameter_list).
If you don't know why search for SQL Injection or see Taint mode in Perl
and DBI (TaintIn).
You don't say what database this is. It is not always UPPER especially
when the strings might be unicode (Oracle uses nls_upper). Other than
that upper(column) = upper(?) is ok.
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
_________________________________________________________________
Hotmail is redefining busy with tools for the New Busy. Get more from your
inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2
