>>>>>>>>I don't understand why my code isn't working as I use the identical technique in another SP and it works wonderfully
>>>>>>>
>>>>>>>But this works:
>>>>>>>

>>>>>>>DECLARE @Test TABLE (Fld1 NVARCHAR(50))
>>>>>>>INSERT INTO @Test VALUES ('WLIF20120047')
>>>>>>>DECLARE @LikePerc nvarchar(50)
>>>>>>>DECLARE @LikeWoPerc nvarchar(50)
>>>>>>>SET @LikePerc = 'WLIF20120047%'
>>>>>>>SET @LikeWoPerc = 'WLIF20120047'
>>>>>>>SELECT * FROM @Test WHERE Fld1 LIKE @LikePerc
>>>>>>>SELECT * FROM @Test WHERE Fld1 LIKE @LikeWoPerc
>>>>>>>

>>>>>>
>>>>>>So Boris,
>>>>>>
>>>>>>are you telling me to always add the % on at the end of the string I pass?
>>>>>
>>>>>Yes (of course when you use LIKE operator :-)).
>>>>
>>>>But when I run your sample code I get results for both SELECTs, so I don't need the % to get the correct result.
>>>>
>>>>Somebody has indicated that my type of code is susceptible to SQL Injection. I thought the use of Parameters made that impossible. What do you say?
>>>
>>>Hi Frank
>>>
>>>There are many misconceptions about SQLIA. You should explain to that person that your code specifically is passing user entries as parameters to sp_executesql which makes this safe.
>>
>>Thanks Mike. How do you know my code is doing this?
>
> EXEC sp_executesql @sSql, @ParmDefinition,
> @PolicyNumber=@PolicyNumber,
> @ClientName=@ClientName,
> @ReceiptNumber=@ReceiptNumber
>

Doh!! LOL

>sSQL contains a where clause with a reference to @ReceiptNumber. Suppose you pass "Yearwood" as ReceiptNumber. Output sSQL and show me where "Yearwood" is in sSQL. It is not there. In other words, "Yearwood" was not injected.
>
>The first parameter of sp_executesql takes the command to execute. Since sSql does not contain "Yearwood", there is no way that if I entered a ReceiptNumber as SQL "1=1; DROP TABLE Receipts" that it would get injected and executed. No SQL can be Injected and so no Attack.
>
>There are gurus and then there are gurus. Is your guru a SQL Injection guru? Some gurus think any kind of concatenation is prone to SQL Injection attacks. Few people are using science. Most of this industry uses anecdotal evidence. There is no way to compare your code with Sony's code to see if indeed they were doing what you are doing. However far too many "programmers" build stuff that is prone to sql injection and don't know any better. It is possible that Sony was prone. http://www.sqlservercentral.com/articles/Editorial/77168/
>
>However, your code in this particular example is not prone to SQL Injection.

I really don't know this guy besides from having seen his name on one of the VFP mailing lists. Thanks for the reassurance.