Closed GoogleCodeExporter closed 8 years ago
One of the important constraints I've put on pyodbc is that it *never* modifies
your
SQL. The SQL is passed directly to the ODBC driver. There are a number of
reasons
for this, but two of the most important are (1) security and (2) some drivers
allow
non-standard SQL, so pyodbc could never know what to expect.
In the case of parameter substitution like
insert into foo(a, b, c) values (?, ?, ?)
The parameters are not insert into the SQL statement. Instead, the SQL is
sent,
question marks and all, directly to the driver. Usually the driver sends it
directly
to the database. Second, the three parameters are sent *separately*.
One of the very important benefits is eliminating potential SQL Injection
attacks:
http://en.wikipedia.org/wiki/SQL_injection
Therefore, I'm going to have to close this one with no changes.
Now, if you are inserting multiple rows, do build the SQL statement with the
actual
row names, but leave the question marks for the parameters. If you execute the
same
statement but with different parameter values, you often get a performance
boost.
The SQL is not sent to the database over and over - instead it is sent the
first time
and we reuse it.
Sorry about that.
Original comment by mkleehammer
on 28 May 2010 at 7:39
Yes, I understand that the SQL is not being modified, but the parameters are
supplied
for the question marks as needed. Since I do not know the order the columns
will be
in the file I am using to build insert statements, I am unable to pass them on
the
insert statement. The file itself is CSV and the field names are in the first
line.
That is why I would like to be able to pass the column names as parameters
using the
question-mark substitution scheme. I am also worried about injection attacks,
which
is just the reason I would like to do things this way. Currently I am building
the
insert statement dynamically using the field names read from the file, hence
the
risk.
Original comment by gerald.b...@gmail.com
on 28 May 2010 at 8:02
Original issue reported on code.google.com by
gerald.b...@gmail.com
on 28 May 2010 at 7:32