6:47 p.m.
I am very new to GRETL so all help is greatly appreciated.
Previously I have asked about making an ODBC connection to MS Access to
bring in my own data. With the help of users in this community I have
been successful in that end ever.
Below is the code that I used:
nulldata 250
setobs 12 1990:1
open dsn=FCST_INPUTS --odbc
string sqlstr="SELECT Emplopy FROM Data_Table_to_GRETL WHERE
census_division="East North Central"
data Employ @sqlstr --odbc
setinfo MWh -n "in MWh"
Now I have a simple string concatenation question to be used in a SQL
statement.
I need to bring in two (2) data series from the same MS Access table
named Data_Table_to_GRETL. The two series are: (1) Employ; and (2) Pop
Both of data series need to be from the same census_division (in the
Acess database I have data by year month for each of the 9 US census
divisions). In this example the census division is "East North
Central".
I though that I could define a string named census_divicsion early in
the code and then concatenate the sqlstr for each "ODBC read" as
follows:
string census_division="East North Central"
nulldata 250
setobs 12 1990:1
# bring in Employment data
open dsn=FCST_INPUTS --odbc
string sqlstr="SELECT Employ FROM Data_Table_to_GRETL WHERE
census_division=" ~ census_division
data Employ @sqlstr --odbc
# bring in Population data
open dsn=FCST_INPUTS -odbc
string sqlstr2="SELECT Pop FROM Data_Table_to_GRETL WHERE
census_division="~ census_division
data Pop sqlstr2 --odbc
However, for some reason even thought the string appears to be correct,
it errors out:
Error executing script: halting
data Employ @sqlstr -odbc
Any assistance providing the correct logic for concatenating the sqlstr
that would make it able to be read in SQL would be greatly appreciated.
Sincerely,
Mike
8:07 p.m.
On Mon, 31 Aug 2009, Mike Pfeiff wrote:
Previously I have asked about making an ODBC connection to MS Access
to
bring in my own data. With the help of users in this community I have
been successful in that end ever.
Below is the code that I used:
nulldata 250
setobs 12 1990:1
open dsn=FCST_INPUTS --odbc
string sqlstr="SELECT Emplopy FROM Data_Table_to_GRETL WHERE
census_division="East North Central"
data Employ @sqlstr --odbc
setinfo MWh -n "in MWh"
Now I have a simple string concatenation question to be used in a SQL
statement.
I need to bring in two (2) data series from the same MS Access table
named Data_Table_to_GRETL. The two series are: (1) Employ; and (2) Pop
Both of data series need to be from the same census_division (in the
Acess database I have data by year month for each of the 9 US census
divisions). In this example the census division is "East North
Central".
I though that I could define a string named census_divicsion early in
the code and then concatenate the sqlstr for each "ODBC read" as
follows:
string census_division="East North Central"
nulldata 250
setobs 12 1990:1
# bring in Employment data
open dsn=FCST_INPUTS --odbc
string sqlstr="SELECT Employ FROM Data_Table_to_GRETL WHERE
census_division=" ~ census_division
data Employ @sqlstr --odbc
# bring in Population data
open dsn=FCST_INPUTS -odbc
string sqlstr2="SELECT Pop FROM Data_Table_to_GRETL WHERE
census_division="~ census_division
data Pop sqlstr2 --odbc
However, for some reason even thought the string appears to be
correct, it errors out:
Error executing script: halting
>data Employ @sqlstr -odbc
Any assistance providing the correct logic for concatenating the
sqlstr that would make it able to be read in SQL would be
greatly appreciated.
I don't have access to an ODBC connection on the machine where I'm
writing this, but I suspect that the problem arises from the
embedded spaces in the value of the "census_division" variable in
your "WHERE" clause (that is, the value "East North Central").
You can ensure that the value with spaces is correctly wrapped in
quotes by using gretl's sprintf command with backslash-escaped
quotes, as in:
<script>
string cendiv = "East North Central"
sprintf s "SELECT X FROM Tbl WHERE Cond=\"%s\"", cendiv
printf "s = %s\n", s
</script>
However, I'm not sure offhand whether gretl's ODBC routines will
handle this sort of input correctly. I'll have to test.
Allin Cottrell
6:05 a.m.
New subject: GRETL string concatenation for use in SQL statement
Allin Cottrell wrote:
However, I'm not sure offhand whether gretl's ODBC routines will
handle this sort of input correctly. I'll have to test.
Did you change the string parsing code? Because with current windows
snapshot the follwing snippet no longer works:
<script>
string a="\"
</script>
chris
5:32 p.m.
On Wed, 2 Sep 2009, chris wrote:
Allin Cottrell wrote:
>
> However, I'm not sure offhand whether gretl's ODBC routines will
> handle this sort of input correctly. I'll have to test.
>
Did you change the string parsing code? Because with current windows
snapshot the follwing snippet no longer works:
<script>
string a="\"
</script>
Yes, I considered that I had found a bug, in that you couldn't set
a string to contain literal quotes by doing, e.g.
string quotefoo = "\"foo\""
That's now fixed, but it has broken the idiom you mentioned. But
I think that would be better done as
string a = "\\"
This doesn't yet work right, but it will soon.
Allin.
9:11 p.m.
On Wed, 2 Sep 2009, Allin Cottrell wrote:
On Wed, 2 Sep 2009, chris wrote:
> Allin Cottrell wrote:
> >
> > However, I'm not sure offhand whether gretl's ODBC routines will
> > handle this sort of input correctly. I'll have to test.
> >
>
> Did you change the string parsing code? Because with current windows
> snapshot the follwing snippet no longer works:
>
> <script>
> string a="\"
> </script>
Yes, I considered that I had found a bug, in that you couldn't set
a string to contain literal quotes by doing, e.g.
string quotefoo = "\"foo\""
That's now fixed, but it has broken the idiom you mentioned. But
I think that would be better done as
string a = "\\"
This doesn't yet work right, but it will soon.
Sorry, let me not prejudge the issue. One option is to proceed in
the direction I indicated, allowing backslash-escaped quotes (and
so, therefore, other escapes, including backslash-escaped
backslashes) in the definition of string literals using
string s = "..."
But another option is simply to revert the change I made, to which
Chris has drawn attention.
To clarify: before my recent change, when you defined a string
literal using
string s = "..."
gretl followed the simple procedure of making the string start
at the first '"' and end at the next '"'. So Chris's
string a = "\"
would produce a string containing a single, literal backslash.
This means that if you did
string quotefoo = "\"foo\""
(in the hope of getting a quote-wrapped string) you'd get an
error, since gretl would see a string comprising a single
backslash followed by the bare identifier 'foo', and most likely
you'd get a complaint about the symbol 'foo' being undefined.
It seemed to me that this was a bug, but maybe it's OK: it
doesn't agree with C usage, but it was consistent. And if you
wanted to get fancier with escapes you could use sprintf.
Any thoughts? Should we just go back to the status quo ante?
(And perhaps add a note to the manual.)
Allin.
1:33 a.m.
New subject: GRETL string concatenation for use in SQL statement
I'm fine with allowing escape sequences in string definitions. This means we should
allow:
string a="\"c" to get "c
and
string b="\\" to get \
although this is backward incompatible. Using sprintf for such simple tasks is not
convenient.
chris
________________________________________
Von: gretl-users-bounces(a)lists.wfu.edu [gretl-users-bounces(a)lists.wfu.edu] im Auftrag von
Allin Cottrell [cottrell(a)wfu.edu]
Gesendet: Donnerstag, 3. September 2009 03:11
An: Gretl list
Betreff: Re: [Gretl-users] GRETL string concatenation for use in SQL statement
On Wed, 2 Sep 2009, Allin Cottrell wrote:
On Wed, 2 Sep 2009, chris wrote:
> Allin Cottrell wrote:
> >
> > However, I'm not sure offhand whether gretl's ODBC routines will
> > handle this sort of input correctly. I'll have to test.
> >
>
> Did you change the string parsing code? Because with current windows
> snapshot the follwing snippet no longer works:
>
> <script>
> string a="\"
> </script>
Yes, I considered that I had found a bug, in that you couldn't set
a string to contain literal quotes by doing, e.g.
string quotefoo = "\"foo\""
That's now fixed, but it has broken the idiom you mentioned. But
I think that would be better done as
string a = "\\"
This doesn't yet work right, but it will soon.
Sorry, let me not prejudge the issue. One option is to proceed in
the direction I indicated, allowing backslash-escaped quotes (and
so, therefore, other escapes, including backslash-escaped
backslashes) in the definition of string literals using
string s = "..."
But another option is simply to revert the change I made, to which
Chris has drawn attention.
To clarify: before my recent change, when you defined a string
literal using
string s = "..."
gretl followed the simple procedure of making the string start
at the first '"' and end at the next '"'. So Chris's
string a = "\"
would produce a string containing a single, literal backslash.
This means that if you did
string quotefoo = "\"foo\""
(in the hope of getting a quote-wrapped string) you'd get an
error, since gretl would see a string comprising a single
backslash followed by the bare identifier 'foo', and most likely
you'd get a complaint about the symbol 'foo' being undefined.
It seemed to me that this was a bug, but maybe it's OK: it
doesn't agree with C usage, but it was consistent. And if you
wanted to get fancier with escapes you could use sprintf.
Any thoughts? Should we just go back to the status quo ante?
(And perhaps add a note to the manual.)
Allin.
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
5:36 a.m.
On Jueves, 3 de Septiembre de 2009 03:11:34 Allin Cottrell escribió:
On Wed, 2 Sep 2009, Allin Cottrell wrote:
> On Wed, 2 Sep 2009, chris wrote:
> > Allin Cottrell wrote:
> > > However, I'm not sure offhand whether gretl's ODBC routines will
> > > handle this sort of input correctly. I'll have to test.
> >
> > Did you change the string parsing code? Because with current windows
> > snapshot the follwing snippet no longer works:
> >
> > <script>
> > string a="\"
> > </script>
>
> Yes, I considered that I had found a bug, in that you couldn't set
> a string to contain literal quotes by doing, e.g.
>
> string quotefoo = "\"foo\""
>
> That's now fixed, but it has broken the idiom you mentioned. But
> I think that would be better done as
>
> string a = "\\"
>
> This doesn't yet work right, but it will soon.
Sorry, let me not prejudge the issue. One option is to proceed in
the direction I indicated, allowing backslash-escaped quotes (and
so, therefore, other escapes, including backslash-escaped
backslashes) in the definition of string literals using
string s = "..."
But another option is simply to revert the change I made, to which
Chris has drawn attention.
To clarify: before my recent change, when you defined a string
literal using
string s = "..."
gretl followed the simple procedure of making the string start
at the first '"' and end at the next '"'. So Chris's
string a = "\"
would produce a string containing a single, literal backslash.
This means that if you did
string quotefoo = "\"foo\""
(in the hope of getting a quote-wrapped string) you'd get an
error, since gretl would see a string comprising a single
backslash followed by the bare identifier 'foo', and most likely
you'd get a complaint about the symbol 'foo' being undefined.
It seemed to me that this was a bug, but maybe it's OK: it
doesn't agree with C usage, but it was consistent. And if you
wanted to get fancier with escapes you could use sprintf.
Any thoughts? Should we just go back to the status quo ante?
(And perhaps add a note to the manual.)
Allin.
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
In general, I don`t have any strong preference for any of the two
alternatives, if the subject is well documented in the manual.
But I have many script files in which I use the backslash in a string, so it is
probably that if the behavior of the "string" command is changed I will have
to correct them.
Apart from that, I see the "string" command as something more simple to use
for a not very experimented user, and "sprintf" as a command more flexible and
so more difflcult. With the old status of the "string" command, when this user
has an error with a command similar to
string quotefoo = "\"foo\""
I think it is time he/she learn how to use "sprintf".
I mean: please go back to the state before.
--
Ignacio Diaz-Emparanza
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
T.: +34 946013732 | F.: +34 946013754
www.et.bs.ehu.es
9:26 a.m.
On Thu, 3 Sep 2009, Ignacio Diaz-Emparanza wrote:
I have many script files in which I use the backslash in a
string, so it is probably that if the behavior of the "string"
command is changed I will have to correct them.
Yes, the change I made has a larger effect of backward
incompatibility than I first thought. If we were to allow
any backslash escapes in
string s = "..."
then we would really have to allow all the standard ones, and that
would break existing scripts that define Windows paths containing
backslashes: all of these would have to be doubled.
We can revisit this later, but for now I'll revert my change and
put a note in the manual explaining that backslashes are not
treated specially in that context.
Allin.
5514
days inactive
5517
days old
7 comments
5 participants
participants (5)
-
Allin Cottrell -
chris -
Ignacio Diaz-Emparanza -
Klein, Christoph
-
Mike Pfeiff