Record Set Variables used in PHP and MYSQL model

Question

PHP MYSQL server model.
I'e been using dreamweaver for ages and have allways admired
how well they have kept compatibility between versions. The recent
8.02 release was a little bit of a shock when I had to start
rewriting all my PHP MYSQL recordset queries!
In the bulk of my SQL queries I detect on of two states for a
query parameter and in some queries the parameters are used more
then once. By creating a single variable in for the recordset I've
allways been able to check and recheck the single variable in the
query using the standard recordset. Now in version 8.02 I am
getting the error: Missing type for variable:colname
So where:
SELECT *
FROM links
WHERE LinkID = colname or colname=-1
ORDER BY `Level` DESC
used to work it does not work any more!
I'm being forced to rewrite the query:
SELECT *
FROM links
WHERE colname in (-1,LinkID)
ORDER BY `Level` DESC
Simple enough but where the queries get more complex the more
variables I have to define!
This is not Cool! Can we get a bug fix for this so that I
dont have to rewrite all my queries!
P.S. Since when did anyone say that the Dreamweaver was SQL
injection safe! This issue should have been resolved back in the
Ultradev days! I guess Kudos goes to Adobe for finally trying to
address one of the biggest glaring issues dreamweaver has had since
it's inception. I was allways kinda upset that I was forced to pass
variables as text to sprintf when I knew they where numbers!
If I Look at the resultant code now I'm sure the result
sprintf will still be using %s instead of optionally specifying one
of the many diferent types (
% - a literal percent character. No argument is required.
b - the argument is treated as an integer, and presented as a
binary number.
c - the argument is treated as an integer, and presented as
the character with that ASCII value.
d - the argument is treated as an integer, and presented as a
(signed) decimal number.
e - the argument is treated as scientific notation (e.g.
1.2e+2).
u - the argument is treated as an integer, and presented as
an unsigned decimal number.
f - the argument is treated as a float, and presented as a
floating-point number (locale aware).
F - the argument is treated as a float, and presented as a
floating-point number (non-locale aware). Available since PHP
4.3.10 and PHP 5.0.3.
o - the argument is treated as an integer, and presented as
an octal number.
s - the argument is treated as and presented as a string.
x - the argument is treated as an integer and presented as a
hexadecimal number (with lowercase letters).
X - the argument is treated as an integer and presented as a
hexadecimal number (with uppercase letters).
This would further protect a query from being SQL Injected!
I'd hope that Adobe would enable a Site specfic setting or
something that would change the behaviour to match the passed
parameter to sprintf with the specified variable type (I'd guess
best practice to be Numeric be type f Text be type s and Date as
type s as well)

Answer 1

Start by saying bump.
I've still no word from Adobe if they are doing anything with
this problem. Any one had any replys from Adobe on it? Any one
found a work around with recoding queries?