om>>
> To: 4D iNug Technical <4d_tech@lists.4d.com <mailto:4d_tech@lists.4d.com>>
> Cc: Aaron <aaro...@nams-inc.com <mailto:aaro...@nams-inc.com>>
> Subject: RE: 4D SQL Implementation
> Message-ID:
>
> <dm5pr15mb16413d7cd4bed3ff59490d93a7.
Message-
From: 4D_Tech [mailto:4d_tech-boun...@lists.4d.com] On Behalf Of Timothy Penner
via 4D_Tech
Sent: Monday, April 17, 2017 9:01 AM
To: 4D iNug Technical <4d_tech@lists.4d.com>
Cc: Timothy Penner <tpen...@4d.com>
Subject: RE: 4D SQL Implementation
> Using strings bui
> Using strings built into queries is prone to sql injection if the query has
> any input from the users and is considered a deadly sin in most cases.
Here is a good example describing why you should never concatenate data into a
SQL statement; you should always use parameterized queries
Aaron,
> alternatively you can use SQL EXECUTE to still be able to use local
> variables, and build your query dynamically
Using strings built into queries is prone to sql injection if the query has any
input from the users and is considered a deadly sin in most cases.
Justin
> You still can't use local variables in a EXECUTE IMMEDIATE SQL statement in a
> compiled application? Is it really that difficult to implement?
alternatively you can use SQL EXECUTE to still be able to use local variables,
and build your query dynamically
sample:
C_TEXT($sqlStmt)
Totally agree with all of that. I was hopeful that since Wakanda uses the same
engine that we'd see a lot of improvement in the SQL engine of 4D, but not so
much. Another example: a SELECT on an indexed field using a nested SELECT works
great until you reach a certain number of rows returned.
Bart,
I have to agree with everything you stated. At one point in time I had a
number of SQL calls in a web app that had some heavy use. The day I rolled out
the SQL code I had to roll it back to 4D Query code because performance was so
bad the site became unusable. At this point in time I
7 matches
Mail list logo
