...@evergreeninfo.net
>
>
> -Original Message-
> From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On
> Behalf Of Peter Haworth
> Sent: Thursday, July 30, 2015 2:47 PM
> To: How to use LiveCode
> Subject: Re: parameterized query with wildcard
&g
> Of Peter Haworth
> Sent: Thursday, July 30, 2015 2:47 PM
> To: How to use LiveCode
> Subject: Re: parameterized query with wildcard
>
> I feel I should point out that you are leaving yourself wide open to SQL
> injection attacks by not using the placeholder method of
vergreen Information Services
rdim...@evergreeninfo.net
-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of
Peter Haworth
Sent: Thursday, July 30, 2015 2:47 PM
To: How to use LiveCode
Subject: Re: parameterized query with wildcard
I feel I shoul
I feel I should point out that you are leaving yourself wide open to SQL
injection attacks by not using the placeholder method of passing data to
SQL statements. Not enough space to detail how that works here but just
Google "SQL injection" on the web to see a sample of the really bad things
that
If you use the placeholder method, there is no need to sanitize the
strings, that's the point of using it. Although I guess it depends on what
you mean by "sanitize".
On Thu, Jul 30, 2015 at 8:11 AM Bob Sneidar
wrote:
> Yes it does. If you use the placeholder method (I am not really sure what
>
Yes it does. If you use the placeholder method (I am not really sure what to
call it at this point) then sqlYoga sanitizes the strings for you. I've
inserted records with any number of characters using this method without any
problems reading in or out of the database.
I'm not sure if a direct
Turns out it is done in the system settings under keyboard in case anyone else
needs to do the same.
Bob S
On Jul 29, 2015, at 15:06 , Bob Sneidar
mailto:bobsnei...@iotecdigital.com>> wrote:
I should also mention that my mail program *DOES* substitute plain quotes for
smart ones. I am disabl
Okay I see my confusion. I can use a statement like:
select * from customers where customername LIKE '%int%’
This works. It seems however that when using parameter substitution it does
not. In sqlYoga I can use:
put sqlquery_createObject(“customers”) into qCustomerObject
put “customer name LIK
How odd. I am thinking now, that because I am passing these query arguements to
sqlYoga it is doing the macro replacement instead of SQL. Now that I think of
it, I have never used this in a direct SQL query. I am not even sure how to
construct it. Is this a web server convention? I cannot see h
When I get that value from the user it is scrubbed and then put into the SQL
with the merge.
> On Jul 29, 2015, at 12:18 PM, Peter Haworth wrote:
>
> But why bother? You're already putting the value into a variable so all
> that's required is use :1 and append the variable name to the revxx
But why bother? You're already putting the value into a variable so all
that's required is use :1 and append the variable name to the revxxx call.
On Wed, Jul 29, 2015 at 8:29 AM PystCat wrote:
> Not a problem... Scrub the variable before the merge... It's what I do as
> well. I have a function
If you are specifying a literal value with LIKE, then you need the single
quotes or you will get an error. If you are using a parameter variable
containing the literal, then no single quotes needed. Including the :1 in
quotes makes the query look for a string containing :1, not the contents of
th
Not a problem... Scrub the variable before the merge... It's what I do as well.
I have a function that takes the input and scrubs it... I'm away for another
week but if you're interested, when I get back I can post the handler.
> On Jul 29, 2015, at 10:35 AM, Mike Kerner wrote:
>
> The reas
If you copied and pasted it may be that the small quotes are not the right
characters. I have used this query successfully myself so I may have mistyped
something.
Bob S
> On Jul 29, 2015, at 06:31 , Mike Kerner wrote:
>
> Nope. That doesn't work, Bob. That returns nothing.
>
> On Tue, J
The reason for using parameterized queries instead of either merging or
appending is because of SQL injection.
On Wed, Jul 29, 2015 at 10:18 AM, PystCat wrote:
> Why not just use merge...?
>
> Put "John" into tVal
> Put merge("SELECT * FROM foo WHERE(bar LIKE %[[tVal]])") into pSQL
> OR
> put me
Why not just use merge...?
Put "John" into tVal
Put merge("SELECT * FROM foo WHERE(bar LIKE %[[tVal]])") into pSQL
OR
put merge("SELECT * FROM foo WHERE(bar LIKE %[[tVal]]%)") into pSQL
I do this for all of my queries and it works fine.
Paul
> On Jul 29, 2015, at 9:45 AM, Mike Kerner wrote:
If I was guessing, my hunch would be that including the single-quotes is
going to make the db look for strings containing %:1%, instead of using the
wildcards and the parameter.
On Wed, Jul 29, 2015 at 9:31 AM, Mike Kerner
wrote:
> Nope. That doesn't work, Bob. That returns nothing.
>
> On Tue
Nope. That doesn't work, Bob. That returns nothing.
On Tue, Jul 28, 2015 at 7:23 PM, Bob Sneidar
wrote:
> Should be LIKE ‘:1’ or for wild cards LIKE ‘%:1%’.
>
> If you are searching for a value at the beginning, LIKE ‘:1%’ or at the
> end, LIKE ‘%:1’
>
> If searching for all, column LIKE ‘%:1%
Should be LIKE ‘:1’ or for wild cards LIKE ‘%:1%’.
If you are searching for a value at the beginning, LIKE ‘:1%’ or at the end,
LIKE ‘%:1’
If searching for all, column LIKE ‘%:1%’ OR column LIKE ‘:1%’ OR column LIKE
‘%:1’
HTH
Bob S
> On Jul 28, 2015, at 08:16 , Mike Kerner wrote:
>
> Has
Dave,
I take that back - I must have had a typo the first time I tried it.
Appending the wildcards to the search parameter does work.
On Tue, Jul 28, 2015 at 12:28 PM, Mike Kerner
wrote:
> Dave, sorry, I thought I mentioned trying that. It does not work.
>
> Andrew, yes, if you use a parameteri
Dave, sorry, I thought I mentioned trying that. It does not work.
Andrew, yes, if you use a parameterized query, you do not have to
escape/sanitize your parameters. If you append them to build a query, you
do.
On Tue, Jul 28, 2015 at 12:18 PM, Andrew Kluthe wrote:
> Should have read, *proper
Should have read, *proper escaping*.
On Tue, Jul 28, 2015 at 11:17 AM Andrew Kluthe wrote:
> Does revDataFromQuery do any sanitizing/proper to prevent me from sneaking
> extra SQL into your search box like an injection style attack, or does it
> just plop whatever you give in there no questions
Does revDataFromQuery do any sanitizing/proper to prevent me from sneaking
extra SQL into your search box like an injection style attack, or does it
just plop whatever you give in there no questions asked? Just curious. I
have always been spoiled by SQLYoga or rolled my DB interfaces up into API
se
Mike, assuming you are searching the db with parameter pSearchTerm, try
something like this:
put "%" & pSearchTerm & "%" into tSearchTerm
put "SELECT * FROM foo WHERE bar LIKE :1" into tQuery
get revDataFromQuery(tab, return, sDBID, tQuery, "tSearchTerm")
-
"The difference between geniu
24 matches
Mail list logo
