Hi there, in terms of importing data via odbc I encountered*strange behavior *of GRETL if using string labels instead of number labels.
Here an example:
labels have three layers with L1 [1;10], L2 [1;3] and L3 [1;2]
e.g. 1:1:1
1:1:2
1:2:1
My dummy Access database contains 5 observations which should be read in.
Opening dsn and data --odbc gives: "Retrieved 5 observations on 1 series
via ODBC":
da2
1:1:1 10,24
1:1:2 123,20
1:2:1 3,20
1:2:2 232,40
4:2:2 1000,00
Now I merely change the third layer to 1= "aa" and 2= "ab" in GRETL and
Access
e.g. 1:1:aa
1:1:ab
1:2:aa
Opening dsn and data --odbc again gives: "Retrieved 5 observations on 1
series via ODBC "
*BUT first,* smpl --no-missing reveals that *only 3* observations are
really there:
da
1:1:aa 123,2
1:1:ab 232,4
4:1:ab 1000,0
*And second, the values are at the wrong postion! *
In a second mail I send a zip archive with the access database and the
gretl scripts.
Cheers
Pindar
Am 05.02.2011 17:22, schrieb Allin Cottrell:
> On Wed, 2 Feb 2011, [iso-8859-1] RENIER M�lanie wrote:
>
>> I found that in fact if GRETL says it connect to the data source
>> inf1 in Oracle, it does not stay connected to it! Does somebody
>> already encounter this problem?
> Here is what gretl actually does when you issue the commands
>
> open ... --odbc
>
> to open an ODBC connection, and
>
> data ... --odbc
>
> to retrieve data from such a connection.
>
> 1) In response to the "open" command we record the information you
> provide (DSN, username and password) and try an SQLConnect. If the
> connection fails, we issue an error message and delete the DSN
> information. If the connection succeeds, we close the connection
> with SQLDisconnect but retain the good DSN information for use
> with the "data" command.
>
> 2) In response to the "data" command we see if there is a set of
> good, stored DSN information (from a successful "open"), and if
> so we use SQLConnect, grab the requested data, then do
> SQLDisconnect.
>
> That is, we don't keep the DB connection open indefinitely, rather
> we open it on demand based on verified DSN information. And that
> information will stay in place for the duration of a gretl
> session, unless it is replaced by a further invocation of
> "open ... --odbc".
>
> On the SQLConnect there is a login timeout of 5 seconds, which
> seems to be fairly standard. If you have a particularly cranky
> DBMS that won't authenticate you within 5 seconds, the "open"
> and/or "data" commands will fail.
>
> Allin Cottrell
>
>
>
>
>
> _______________________________________________
> Gretl-users mailing list
> Gretl-users(a)lists.wfu.edu
> http://lists.wfu.edu/mailman/listinfo/gretl-users
|
Hi there, in terms of importing data via odbc I encountered strange behavior of GRETL if using string labels instead of number labels. Here an example: labels have three layers with L1 [1;10], L2 [1;3] and L3 [1;2] e.g.       1:1:1             1:1:2             1:2:1 My dummy Access database contains 5 observations which should be read in. Opening dsn and data --odbc gives: "Retrieved 5 observations on 1 series via ODBC":               da2 1:1:1       10,24 1:1:2      123,20 1:2:1        3,20 1:2:2      232,40 4:2:2     1000,00 Now I merely change the third layer to 1= "aa" and 2= "ab" in GRETL and Access  e.g.       1:1:aa             1:1:ab             1:2:aa Opening dsn and data --odbc again gives: "Retrieved 5 observations on 1 series via ODBC " BUT first, smpl --no-missing reveals that only 3 observations are really there:                 da 1:1:aa       123,2 1:1:ab       232,4 4:1:ab      1000,0 And second, the values are at the wrong postion! In a second mail I send a zip archive with the access database and the gretl scripts. Cheers Pindar Am 05.02.2011 17:22, schrieb Allin Cottrell: On Wed, 2 Feb 2011, [iso-8859-1] RENIER M�lanie wrote:I found that in fact if GRETL says it connect to the data source inf1 in Oracle, it does not stay connected to it! Does somebody already encounter this problem?Here is what gretl actually does when you issue the commands open ... --odbc to open an ODBC connection, and data ... --odbc to retrieve data from such a connection. 1) In response to the "open" command we record the information you provide (DSN, username and password) and try an SQLConnect. If the connection fails, we issue an error message and delete the DSN information. If the connection succeeds, we close the connection with SQLDisconnect but retain the good DSN information for use with the "data" command. 2) In response to the "data" command we see if there is a set of good, stored DSN information (from a successful "open"), and if so we use SQLConnect, grab the requested data, then do SQLDisconnect. That is, we don't keep the DB connection open indefinitely, rather we open it on demand based on verified DSN information. And that information will stay in place for the duration of a gretl session, unless it is replaced by a further invocation of "open ... --odbc". On the SQLConnect there is a login timeout of 5 seconds, which seems to be fairly standard. If you have a particularly cranky DBMS that won't authenticate you within 5 seconds, the "open" and/or "data" commands will fail. Allin Cottrell_______________________________________________ Gretl-users mailing list gretl-us...@lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-users |
