> 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
