On 14/12/10 16:49, Markus Neteler wrote:
On Tue, Dec 14, 2010 at 4:43 PM, Moritz Lennert
<[email protected]> wrote:
On 14/12/10 16:11, Markus Neteler wrote:
Hi,
I have some troubles with the SQLite driver with a SELECT statement:
GRASS 6.4.1svn (patGB1):~> echo 'SELECT cat FROM
MRR1_09_marked_csv_lines_id ' | db.execute
I wonder what the problem could be...
s/db.execute/db.select
Cool.
But I thought that both did essentially the same job? Apparently not...
No, db.select is only for selection and db.execute is for any other db
manipulations (update, delete, insert, create table, etc). They use
different functions to interact with the DB. Don't know what Radim's
reasoning was behind this, but I guess he had a good one :-).
I wonder
if we could trap "SELECT" in db.execute and point the user to db.select.
?
That's not as easy as it sounds, since you might have SELECT clauses in
UPDATE and other db.execute clauses (e.g. INSERT INTO mytable SELECT x,
y, z FROM othertable). So the trapping would have to be a bit more
sophisticated, at least looking out for a SELECT at the beginning of the
statement. But definitely possible. Probably best done right before the
ret = db_execute_immediate(driver, &stmt);
at
line 74 of db/base/execute.c (grass6)
or
line 75 of /db/db.execute/main.c (grass_trunk)
Moritz
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
