×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 27-Sep-2016 16:07 -0500, James H. H. Lampert wrote:
[…] so far as I can determine, the only thing that usage of a
prepared statement even buys them is protection from SQL injection,
and I'm not even convinced that the situation has enough exposure to
where SQL injection is even a realistic possibility).
I suspect from what has been shown in this discussion, that the other
[the non-prepared] statement has zero chance for malicious injection; of
course, /malicious/ does not include things like a user having provided
a joke-name for a value for the $name nor any bogus value specified for
the $emailAddress, for which that data would be inserted, and done so,
irrespective the choice between prepared or fully dynamic.
The potential benefit from the prepared statement is that the
statement "INSERT INTO anyOneLibName.NOTEFILE ( NRECID, NNOTES ) VALUES
( ?, ? )" could be made available by the DB2 for IBM i SQL for re-use;
i.e. there is the potential for a performance improvement from being
able to repeatedly use an existing statement, as a duplicate of one that
was already prepared and remains valid. Likely the application does the
prepare and then multiple execute, but each time with different data.
I am unsure of what will be done with the purely dynamic string [having
been composed with the string values replacing those parameter markers];
i.e. might the statement be /parameterized/ by the DB, per the literal
/values/ being converted into parameter markers such that the DB2
implicitly generates the same /prepared/ statement, and then that
identical prepared statement is stored in the same way as occurs with
the statement having been issued with the explicit PREPARE.? If the
fully dynamic statement is implicitly able to be reused, then perhaps
only after a couple of requests [with the same library name and library
list] have been made, before that since-parameterized request is stored
and can be reused; i.e. there would be a delay in any potential for
improved performance, but since, each statement should perform
effectively identical per use of a stored copy and thus run the same way.
At any rate, I've asked to have hex '8E' passed on to the customer.
I am hopeful that will suffice; despite my reservations in having
offered that kludge.
midrange.com
