Windows Registry
Andrei Thorp
Peter, could you please tell me how your windows registry is set up for
testing? (As in, what does Star Query need in order to be able to get
set up.)
Thanks,
-AT
Peter McCurdy
These are the instructions Avery sent me when I had the same issue.
We didn't have the foresight to either send them to the mailing list
or put them on the wiki at the time; at least I'm fixing the first one
now :)
The registry entries you need to set are:
HKLM\Software\ODBC\ODBCINST.INI
ODBC Drivers
Versaplex REG_SZ installed
Versaplex
APILevel REG_SZ 1
ConnectFunctions REG_SZ YYN
Driver REG_SZ l:\vxodbc.dll
DriverODBCVer REG_SZ 03.51
FileUsage REG_SZ 0
Setup REG_SZ l:\vxodbc.dll
SQLLevel REG_SZ 1
This should make it possible to create a new vxodbc connection from
the ODBC control panel or directly from inside StarQuery.
Note that I actually have the ConnectFunctions value set to "YNN", but
it doesn't much matter. In theory, that key tells ODBC applications
what connection functions they can use: the three characters stand for
SQLConnect, SQLDriverConnect, and SQLBrowseConnect, respectively. In
practice, even when you try and tell clients not to use
SQLDriverConnect (like, say, before you'd bothered implementing it),
StarQuery goes and calls it anyway. It's probably worth making sure
that the third character is N, since I don't think we even pretend to
support SQLBrowseConnect, but then, nobody else supports it either so
I don't think any clients will ever try.
Peter.
Avery Pennarun
> HKLM\Software\ODBC\ODBCINST.INI
> ODBC Drivers
> Versaplex REG_SZ installed
> Versaplex
> APILevel REG_SZ 1
> ConnectFunctions REG_SZ YYN
> Driver REG_SZ l:\vxodbc.dll
> DriverODBCVer REG_SZ 03.51
> FileUsage REG_SZ 0
> Setup REG_SZ l:\vxodbc.dll
> SQLLevel REG_SZ 1
But how do we create the entries in the ODBC.INI section? Have they
changed from the way they were before? Does the dialog actually set
all the right values still?
Thanks,
Avery
Andrei Thorp
I'll put this stuff on the
http://code.google.com/p/versaplex/wiki/BuildVersaplex page after I get
it up and running.
Thanks again.
-AT
Peter McCurdy
Er, I'm confused.
1. I didn't set any entries in the ODBC.INI section. They seem to be
set by the system's DSN creation dialog (Control Panel->Administrative
Tools->Data Sources (ODBC)) when it feels the need, i.e. when you
create a new DSN, turn on tracing, etc.
2. I didn't have to change any registry settings after I'd set them
the first time. I fiddled with the ConnectFunctions string a bit, but
as I mentioned, it doesn't seem to be very well respected.
3. Does what dialog set what values?
Peter.
Avery Pennarun
The DSN creation dialog. Setting the values needed to connect to DBus.
I'm guessing it must do so if you haven't set them yourself. But that
would imply that any new values we needed (the dbus moniker?) would
have to have been added to the dialog submit code. Right?
Have fun,
Avery
Peter McCurdy
Ah. Well, there's a few different things on the go here. Hopefully
they all make sense.
First of all, if you've got a simple DBus daemon listening to TCP,
then SQLDriverConnect in vxodbc just takes the server= and port=
parameters passed in the connection string and points a WvDBusConn at
them. So in short, for now you can just set the server and port in
the DSN creation dialog, and everything will work in StarQuery (since
we only support TCP right now anyway, as we were discussing in the
other thread, and StarQuery insists on calling SQLDriverConnect even
when you tell it not to). The username and password and any other
settings in that dialog are basically ignored; I was thinking they'd
be sent through to versaplex at some point, but apparently not.
If you don't like that (and you're writing a client), you can also
specify a DBus parameter in the connection string; this is a dbus
moniker, that again is interpreted by WvDBusConn. WvDBusConn passes
it to WvTCPConn, so it needs to look like "tcp:192.168.207.1:5555",
not the FreeDesktop-style "tcp:host=192.168.207.1,port=5555". The
unit tests use this parameter when they call SQLDriverConnect, but I
suppose they could just as easily use just the server and port
parameters. For the record, note that I deeply hate almost all the
unit testing code in t/common.cc, including the stuff that creates
connections. I stole it from FreeTDS to get me started faster; it
just barely works well enough that I never quite got around to
rewriting it completely, but it's far from spectacular. I've been
slowly trimming it down as I found excuses to. Anyway, I don't think
you can get StarQuery to send this parameter, owing to the
aforementioned insistence on using SQLDriverConnect. I might be wrong
on that though.
I just had a look, and it seems that I wasn't quite so elaborate with
SQLConnect. If you call SQLConnect, it looks for the DBus= value in
the DSN; if that doesn't exist, then it defaults to "dbus:session".
If you don't have DBUS_SESSION_BUS_ADDRESS environment variable
defined, then you're boned. But since you're not at the mercy of
annoying closed-source third-party programs, you should be able to set
the parameter easily enough.
I think that's all there is to it. Any other questions? Was anything
unclear and/or stupid? It's not the prettiest setup in the world, but
it works.
Peter.
Avery Pennarun
> First of all, if you've got a simple DBus daemon listening to TCP,
> then SQLDriverConnect in vxodbc just takes the server= and port=
> parameters passed in the connection string and points a WvDBusConn at
I guess the parts that I'm confused about here are:
1. What's the difference between SQLConnect and SQLDriverConnect, exactly?
2. How does parsing options differ between the two?
3. What part makes use have to use the environment variable, exactly?
That should always be unnecessary if we set up the DSN or connection
string correctly, right?
4. Does the "dbus=" setting work when it's used in odbc.ini?
#4 is a bit of a trick question, as Andrei has spent a fair bit of
time finding out that it doesn't :)
Have fun,
Avery
Andrei Thorp
into trouble. Thank you very much for your aid.
-AT
Peter McCurdy
>
> On 16/01/2008, Peter McCurdy <peterm...@alumni.uwaterloo.ca> wrote:
> > First of all, if you've got a simple DBus daemon listening to TCP,
> > then SQLDriverConnect in vxodbc just takes the server= and port=
> > parameters passed in the connection string and points a WvDBusConn at
> > them. [...]
>
> I guess the parts that I'm confused about here are:
>
> 1. What's the difference between SQLConnect and SQLDriverConnect, exactly?
That's pretty simple. SQLConnect gives vxodbc a DSN, a username, and
a password. Vxodbc then grabs information from that DSN, filling
stuff in from defaults if it's not provided by the DSN, and connects.
Importantly, the DSN specifies which driver to use, so the ODBC driver
manager loads the right DLL and calls the right connection function.
If you were curious, this is why the format of the DRIVER= value in
odbc.ini changes depending on which driver manager you're using.
SQLDriverConnect is what you use when you don't have a driver manager,
or don't have a DSN (or if you're StarQuery). Instead of providing a
DSN, instead you make a connection string that contains all the bits
of information that would have been in the DSN, including the driver,
as a string of key=value pairs. Actually, if you're really so
inclined, you can specify a DSN= value as well; I don't really know
why you'd do that instead of calling SQLConnect (or, contrariwise, I
don't know why you also need SQLConnect, except that it's minorly
easier to implement). Basically all vxodbc gets is the connection
string, which it has to split out and parse itself.
> 2. How does parsing options differ between the two?
They're two independent chunks of code. Right now, SQLConnect looks
for the DBus= DSN setting, defaulting to "dbus:session".
SQLDriverConnect takes the DBus= setting if it's provided in the
connection string; if not, it uses the server/port settings.
SQLDriverConnect returns an error if neither the DBus nor the
server/port parameters are set, and ignores the value of dbus:session.
Looking at it now, it would be nice to support the same semantics.
It's a bit tricky though, as SQLDriverConnect also supports popping up
dialog boxes to prompt for missing information, so it's a bit harder
to share code (at least, the original versions didn't, and I didn't
make them). I don't know if vxodbc still has the popups; generally,
this is never supported on Linux by any ODBC drivers, and the code on
Windows may have been disabled.
> 3. What part makes use have to use the environment variable, exactly?
> That should always be unnecessary if we set up the DSN or connection
> string correctly, right?
The environment variable is only used if you call SQLConnect without
setting the DBus= value, or if you call either SQLConnect or
SQLDriverConnect with "dbus:session" as the value for the "DBus" key.
So yes, if you set up the DSN or connection string correctly, the
environment variable is unused.
> 4. Does the "dbus=" setting work when it's used in odbc.ini?
>
> #4 is a bit of a trick question, as Andrei has spent a fair bit of
> time finding out that it doesn't :)
That's odd, it used to work. In particular, that was how the unit
tests connected for the longest while, until I got fed up with how
ugly that code was and ended up changing it to use SQLDriverConnect
(in part because that was what I was testing at the time).
To back up a bit: the "dbus=" setting should work if it's set in
odbc.ini and that DSN is referenced by SQLConnect or SQLDriverConnect.
However, if you're using StarQuery, it doesn't directly reference the
DSN in its SQLDriverConnect connection string, nor does it have any
clue about this "dbus=" parameter in odbc.ini, so the "dbus=" setting
doesn't work. That was why I added the code that made a DBus
connection on the specified server/port settings.
Any other questions? It's been a little while, sorry I didn't cough
all this up at the start.
Peter.