On Wed, 3 Feb 2010, Chris wrote:
It should be an integer string that is the date without the / in
them so feb 1 , 2007 stored as 20070201. In the case where I
can import data into gretl I'm not even selecting that column
though.
The particular bit of data I'm pulling is stored as numeric(7,3)
in an mssql server 2008. I believe we can read that as numeric
precision 7, numeric scale 3
For the small and simple test query I was using the data is stored as
numeric(16,3) in the same sql server.
Thanks for persevering! We're making some progress -- you've
given me some ideas for making the manual more explicit. As to the
specifics:
First, on the "obs-format" business: the point of that is if you
want to screen the values coming in via ODBC and add only some of
them to the dataset. But if your identifiers look like "20070201"
and you use "%d" to grab the whole integer value, then _all_ the
ODBC values will be screened out (leaving nothing but missing
values or NAs in the input series). That's because a string like
"20070201" will not match any gretl observation identifier. Note
that the gretl obs identifiers are what you see in the leftmost
column if you do "print index --byobs" after doing "nulldata" and
"setobs".
So in this case it looks as if you want a straight one-column
import. And I need to research "numeric(7,3)" in mssql and see
what I can find. My first thought is that since gretl is asking
for SQL_C_DOUBLE, it's the server's fault that it's _not_ giving
gretl the values in the C double-precision format. But I'm not an
SQL expert and maybe it's not that simple.
Jack, any thoughts?
Allin Cottrell