Details Ticket 4141


Comment | Reply | Resolve


Serial Number 4141
Subject more sql statements for db.execute
Area wish6
Queue grass
Requestors dassau@nature-consult.de
Owner mneteler
Status open
Last User Contact Tue Oct 9 10:59:45 2007 (1 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Tue Oct 9 10:59:45 2007 (1 yr ago)
Created Mon Mar 6 17:36:36 2006 (2 yr ago)

Transaction History Ticket 4141


Mon, Mar 6 2006 17:36:36    Request created by guest  
Subject: more sql statements for db.execute

Platform: GNU/Linux/x86
grass obtained from: CVS
grass binary for platform: Compiled from Sources
GRASS Version: G61 CVS from 20060103

Hi, 

maybe this sql statement support could be added to db.execute as well:

this doesn't work:
echo "SELECT gkz,name,bev0100,bevm0100,bevw0100 FROM stand,testregion WHERE plz
= gkz" | db.execute

this is fine:
echo "SELECT gkz,name,bev0100,bevm0100,bevw0100 FROM stand,testregion WHERE plz
= gkz" | psql -U dassau ifak

thanks
  Otto






Sun, Mar 26 2006 13:36:38    Mail sent by mneteler  
Hi,

in future default DBF will be hopefully changed to
default sqlite. DBF is a table, not a SQL system, so
it is pretty hard to add advanced SQL functionality on
top of DBF.

Markus
Sun, Mar 26 2006 13:37:27    Mail sent by mneteler  
Otto,

forgot to ask if you used the pg driver?
If so, any SQL statement should pass. Otherwise it's a bug.

Markus
Tue, May 2 2006 10:46:17    Mail sent by guest  
Hi Markus,

yes, I used postgreSQL - that's why I was able to use psql command instead of
db.execute.

apart from that, according to the new DBF driver in GRASS page
http://grass.itc.it/grass61/manuals/html61_user/dbf.html

SELECT columns FROM table WHERE condition 

is also supported by DBF - is this correct. If there is further need to test,
I can do this, but I need to create a new set of data? BTW. Is there a
difference when I use ODBC or PG driver?

thanks
  Otto
Tue, May 2 2006 11:07:34    Mail sent by msieczka  
Markus

Otto left a message for you, CCing me only. Forwarding to you now.
http://intevation.de/rt/webrt?serial_num=4141

Maciek
Tue, May 2 2006 12:06:55    Taken by mneteler  
Tue, May 2 2006 12:06:55    Mail sent by mneteler  
Hi,

> apart from that, according to the new DBF driver in GRASS page
> http://grass.itc.it/grass61/manuals/html61_user/dbf.html
>
> SELECT columns FROM table WHERE condition
>
> is also supported by DBF - is this correct. 

not sure what you intend to say? What should be changed where?

> If there is further need to test, I can do this, but I need
> to create a new set of data?

Do you refer to the sqlite driver?

> BTW. Is there a difference when I use ODBC or PG driver?

I assume that ODBC-PG is way slower than direct PG. At least,
for R-stats it is the case (see second half of page):
  http://grass.itc.it/statsgrass/r_and_dbms.html

Markus
Mon, Oct 8 2007 22:44:15    Mail sent by msieczka  
guest wrote (Mon, Mar 6 2006 17:36:36):

> maybe this sql statement support could be added to db.execute as well:
> 
> this doesn't work:
> echo "SELECT gkz,name,bev0100,bevm0100,bevw0100 FROM stand,testregion WHERE
> plz = gkz" | db.execute
> 
> this is fine:
> echo "SELECT gkz,name,bev0100,bevm0100,bevw0100 FROM stand,testregion WHERE
> plz = gkz" | psql -U dassau ifak

By accident I have laerned today that db.execute is not supposed to support
SELECT query. We have db.select for that. In that case, do we call the case
closed?

Maciek
Tue, Oct 9 2007 00:34:14    User changed to dassau@nature-consult.de by mneteler  
Tue, Oct 9 2007 00:34:43    Mail sent by mneteler  
Yes. This was already discussed in

http://www.nabble.com/db.execute%3A-SELECT-STATEMENT-tf3141164.html#a8705855
Tue, Oct 9 2007 01:33:57    Mail sent by rez@touchofmadness.com  
Return-Path <rez@touchofmadness.com>
Delivered-To grass-bugs@lists.intevation.de
Subject Re: [GRASS-dev] [bug #4141] (grass) more sql statements for db.execute
From Brad Douglas <rez@touchofmadness.com>
To Maciek Sieczka via RT <grass-bugs@intevation.de>
Cc dassau@gdf-hannover.de, grass-dev@grass.itc.it
In-Reply-To <20071008204416.0EBE7602A2F@lists.intevation.de>
References <20071008204416.0EBE7602A2F@lists.intevation.de>
Content-Type text/plain
Date Mon, 08 Oct 2007 16:33:35 -0700
Message-Id <1191886415.17343.11.camel@dev64.localdomain>
Mime-Version 1.0
X-Mailer Evolution 2.8.3 (2.8.3-2.fc6)
Content-Transfer-Encoding 7bit
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, score=-5 tagged_above=-999 required=3.5 tests=[BAYES_00=-5]
X-Spam-Score -5
X-Spam-Level
On Mon, 2007-10-08 at 22:44 +0200, Maciek Sieczka via RT wrote:
> guest wrote (Mon, Mar 6 2006 17:36:36):
> 
> > maybe this sql statement support could be added to db.execute as well:
> > 
> > this doesn't work:
> > echo "SELECT gkz,name,bev0100,bevm0100,bevw0100 FROM stand,testregion WHERE
> > plz = gkz" | db.execute
> > 
> > this is fine:
> > echo "SELECT gkz,name,bev0100,bevm0100,bevw0100 FROM stand,testregion WHERE
> > plz = gkz" | psql -U dassau ifak
> 
> By accident I have laerned today that db.execute is not supposed to support
> SELECT query. We have db.select for that. In that case, do we call the case
> closed?
> 
> Maciek

(I didn't follow the entire thread, so my comments may be useless.
YMMV. :-)

Personally, I'd like db.select merged into db.execute.  I don't use the
db.* commands daily and I've fallen into the above case before.
However, I quickly remember the more appropriate usage.

OTOH, db.execute isn't supposed to return and resulting set, which is
why db.select exists (to my knowledge).  I've committed a change in CVS
to db.execute.html noting this and suggests using db.select.

I would consider this closed.


-- 
73, de Brad KB8UYR/6 <rez touchofmadness com>


Tue, Oct 9 2007 03:34:12    Mail sent by hamish_nospam@yahoo.com  
Return-Path <hamish_nospam@yahoo.com>
Delivered-To grass-bugs@lists.intevation.de
Date Tue, 9 Oct 2007 14:33:49 +1300
From Hamish <hamish_nospam@yahoo.com>
To Brad Douglas <rez@touchofmadness.com>
Cc Maciek Sieczka via RT <grass-bugs@intevation.de>, grass-dev@grass.itc.it, dassau@gdf-hannover.de
Subject Re: [GRASS-dev] [bug #4141] (grass) more sql statements for db.execute
Message-Id <20071009143349.072a506b.hamish_nospam@yahoo.com>
In-Reply-To <1191886415.17343.11.camel@dev64.localdomain>
References <20071008204416.0EBE7602A2F@lists.intevation.de> <1191886415.17343.11.camel@dev64.localdomain>
X-Mailer Sylpheed version 2.3.0beta5 (GTK+ 2.8.20; i486-pc-linux-gnu)
X-Face M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
Mime-Version 1.0
Content-Type text/plain; charset=US-ASCII
Content-Transfer-Encoding 7bit
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, score=-3.151 tagged_above=-999 required=3.5 tests=[BAYES_00=-5, FORGED_YAHOO_RCVD=1.849]
X-Spam-Score -3.151
X-Spam-Level
> Maciek wrote:
> > By accident I have laerned today that db.execute is not supposed to
> > support SELECT query. We have db.select for that. In that case, do we
> > call the case closed?

Brad Douglas wrote:
> Personally, I'd like db.select merged into db.execute.  I don't use the
> db.* commands daily and I've fallen into the above case before.
> However, I quickly remember the more appropriate usage.
> 
> OTOH, db.execute isn't supposed to return and resulting set, which is
> why db.select exists (to my knowledge).  I've committed a change in CVS
> to db.execute.html noting this and suggests using db.select.

IIRC in an old post Radim explained why that must be, but can't find it
now.

> I would consider this closed.

still outstanding: db.execute needs to throw an error- not segfault -when
passed SELECT.


Hamish


Tue, Oct 9 2007 04:21:31    Comments added by hbowman  
ah, I see Markus found the thread.

So s/Radim/Wolf/ in prior, although ISTR Radim did mention something about it
once.


Hamish
Tue, Oct 9 2007 10:59:45    Mail sent by mneteler  
Today:

Author: brad

Update of /grassrepository/grass6/db/base
In directory doto:/tmp/cvs-serv1386

Modified Files:
        execute.c
Log Message:
- Exit gracefully on SELECT SQL statement
Comment | Reply | Resolve

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request