Jack (on ODBC connection):
> > You're halfway through. The "open" command establishes the
connection.
> > The actual data retrieval is a job for the "data" command, which
stores
> > the output of an SQL query. Example:
> >
> > <script>
> > qry = "select foo from bar"
> > data myseries query=qry --odbc
> > </script>
>
> Hmm, no chance. There is no message after the open command. So i'm not
> shure if everything work fine.
Apparently it's not fine. If it is, you should get a message from
gretl:
Connected to ODBC data source <source>
If the connection can't be made you're supposed to get an
informative error message back from the SQL server. I just tried
provoking a couple of errors on my system: issuing an --odbc
"open" command with no SQL daemon running, and then, with MySQL
running, issuing the open command with an invalid dsn name. In
these cases I got reasonably informative error messages, e.g.
[unixODBC][Driver Manager]Data source name not found
I'm not sure why you're getting no message, but I'll take a look
at the code and see if there are error modes that might explain
that.
Thanks for your support. I just tried to give the linux commandline
client "gretlcli" a shot. Here i got this errormessage:
/usr/lib/gretl-gtk2/odbc_import.so: cannot open shared object file: No
such file or directory
Maybe this could help?
To make that clear: The odbc in works systemwide.
isql -v 'Postgresql eix' postgres password
gives me a connected message.
Best regards
Stefan