Attempt to configure default driver for unixODBC #16
Conversation
|
Sadly none of those options work, either. I don't get it. When I specify |
|
Oh, and |
I'm not sure what you mean by the above. When you specify or omit the You may find it helpful to review some of the ODBC Specification docs on That may help you confirm whether you've actually hit a bug in UnixODBC. (You might also try a different ODBC driver manager, like iODBC [maintained and supported by my employer].) |
|
I think this might be an issue with DBD::ODBC; this issue seems particularly strange. Like somehow |
|
Ah, I hadn't realized you were using DBD::ODBC. I thought you were developing your own ODBC-compliant tool. Yes, this might indeed be that issue -- which should properly be considered and treated as a bug in DBD::ODBC; I don't know why the UnixODBC wouldn't have reported and helped resolve it as such. As important as the configuration files would be how you're asking DBD::ODBC to connect -- what command are you issuing, with what arguments, exactly what ODBC connect string? Every detail counts, here. The next phase in analysis and troubleshooting would be ODBC Tracing, to see just what calls are being issued by DBD::ODBC to the driver manager (UnixODBC), and what the driver manager is returning for them. Driver tracing can also be helpful, as it shows what calls the driver manager (UnixODBC) is issuing to the driver (Snowflake), and what the driver is returning for them. These logs would confirm whether DBD::ODBC is indeed issuing |
|
Doesn't look like that error-swelling issue the problem: It only calls |
|
The DBD::ODBC docs where you found the error discussion say that it will use This line of your trace -- which appears to be from DBD::ODBC, not from UnixODBC -- shows a redundancy in the
|
|
Note that the Descriptions of the DSNs go in their individual stanzas, as values of the |
|
The DSN I'm passing is I've opened a DBD::ODBC bug report to see if @mjegh has any ideas. |
|
Here's the trace: |
|
Contrast when I add Not seeing much of a hint in these traces as to why it's not finding the default. :-( |
|
I haven't had a chance to look at this properly but you need to bear a few things in mind. (1) there are 2 ways to connect, SQLConnect (the old way which only accepts a DSN, username, password) and SQLDriverConnect (which takes a full connection string). In SQLDriverConnect you have to give it either DRIVER=something or DSN=something or something else I've forgotten. (2) DBI doesn't allow any specification of what method DBD::ODBC should use, so D::O has to guess want is best. (3) D:O tries hard not to break old code and so when it added SQLDriverConnect (for more flexibility) there had to be some way of it deciding whether to use SQLConnect or SQLDriverConnect (I believe it looks for DRIVER= or DSN= but I'd have to check again). (4) SQLDriverConnect returns a string which is supposed to be what is required to pass back into another SQLDriverConnect to connect to the same database/system (people rely on this) there are IIFC, some complications if the UID/PWD are omitted. D:O supports passing the connection string back to Perl for this purpose. (5) UID/PWD are only defined for SQLDriverConnect, they are meaningless in SQLConnect e.g., if you pass UID=xxx as the username to SQLConnect it won't work. Hence, if your connection string includes UID/PWD D:O assumes you want to use SQLDriverConnect. (6) ODBC drivers are funny things (I know, I've written a few). All you NEED to pass to SQLDriverConnect as far as the ODBC driver manager is concerned is ENOUGH for it to identify the driver and then everything in the connection string is passed to the driver. There is probably loads I've forgotten about this as I haven't had much reason to change D:O significantly in a lot of years and I have to admit I've not yet read all of the above comments properly. This is more of a head up that I've briefly seen this issue, here are pointers and I'll try and come back to it. I believe there are sections in the FAQ about this. I'll try and come back to this over the weekend if I can. As for the password issue being visible (the original issue you reported in D:O, I will look again at that as well. Hope this helps a little for now. |
|
You might find https://www.easysoft.com/developer/interfaces/odbc/linux.html and the internal links to Perl useful (written a long time ago but problably mostly still holds true). I have worked on unixODBC and my colleague still looks after it so I'm sure we can get to the bottom of the problem. As this issue is not in DBD::ODBC (it is in sqitchers) if this is a different issue to the password appearing in the trace, e.g., a connection problem, either post as example of what you pass to DBI->connect, contents of odbc.ini and odbcinst.ini files and post it on github in DBD::ODBC or mail it to me and I'll take a look. I'm having a hard time following this issue because it is an attempt to fix something not clearly enough defined for me. |
|
@theory - Given all of the above... It seems worth asking why you want to do this (rely on the |
|
ah, your problem is you want to use the unixODBC defined default driver in the odbcinst.ini? via DBD::ODBC? |
|
I thought I'd written something about this in https://www.easysoft.com/developer/languages/perl/dbd_odbc_tutorial_part_1.html but it doesn't mention default driver so that isn't going to help you. I'll come back to you on that. |
|
Here is a quick (and I mean quick, summary based on a quick look at DBD::ODBC code).
After that, it is up to unixODBC or MS driver manager or iODBC what happens and after |
|
I just checked with Nick Gorham (of unixODBC) and he says a driver = /path/to/my/driver in the odbcinst.ini (not in a driver section) will be used as the DEFAULT driver. e.g., Driver=/usr/local/easysoft/sqlserver/lib/libessqlsrv.so [anotherdriver] |
Yes, because I’m making a Docker image that’s solely for using Sqitch with Snowflake. There is no other driver in the image (aside from whatever unixODBC includes), and users will use the image only for Snowflake deployments. So it seems silly for all of the URLs to include I’ll give that non-sectional Driver spec a try. |
|
I changed Sadly that did not work. |
|
Ok, can you past odbcinst.ini (if different from above), what you passed to DBI->connect and what the error was please. |
|
Error: |
|
ok, can you change either the connection string to include DRIVER=Default OR simply add to the top of the odbcinst.ini file: Driver=/usr/lib/snowflake/odbc/lib/libSnowflake.so |
|
if one doesn't work, try the other - sorry should have mentioned this. |
|
@mjegh --
That makes no sense, and violates the ODBC spec. (Lest there be confusion, when they refer to the "Default subkey" in the Windows Registry, that equates to the The structure of this The only way Nick's suggestion might work is if the first line of the |
|
@theory --
This is a lot of work to try to save a few dozens or even hundreds of characters in some strings/config-files. As "silly" as it may be to specify |
Sorry, one of the other what? |
|
Change the connection string to add DRIVER=Default (based on your current odbcinst.ini config) and IF that doesn't work (and I don't see why not) ADD Driver=/usr/local/easysoft/sqlserver/lib/libessqlsrv.so to your odbcinst.ini file and do not specify DRIVER=Default in the connection string. |
Perhaps so, and if this can't be made to work, that's fine. I'm just surprised to find that when it complains about no default driver there is no way to specify one that I can find. Seems like a bug. |
|
I feel your frustration and understand it - I've had similar issues myself in the past. I'm happy to perservere if you are for now. |
|
Yes, it works if I specify It fails because it can't load the library |
|
ah, ok, that is the first time you've mentioned that scenario (that I have seen). I'm happy to pass that over to Nick and get a comment from him but when I asked him before he said the default driver is Driver=/path/to/my/driver without a driver section and I believe that is not HIS choice, but what Microsoft decided in the first place (bear in mind their settings are in the registry not a config file). I'll ask him now before he goes home. |
|
@mjegh -
As I said above... Microsoft uses a Registry subkey of "Default" which maps/equates to a |
|
@TallTed You could be right, I'm not completely sure right now but one thing I know for sure is what works and given the purpose of the change in question there isn't going to be another solution in the near future given it is a docker image and reliant on packaged packages. I was working on the basis of helping someone out and solving an issue and I think we got there, whether it is on "specification" is a whole new ball park. If you or David wants to persue the "this isn't to specification" then by means go ahead. |
|
Bare driver not under a key does not work: |
|
@theory, you have to put DRIVER=Default in I belive. Whether that is technically correct or not. |
|
|
Appologies: [DEFAULT] Driver=/path/to/driver.so and then I think you need DRIVER=DEFAULT in the dbi connection string to force DBD::ODBC to use SQLDriverConnect but that may not be necessary. |
I spoke with Nick (of unixODBC) and his basic comment was "thats a hangover from the windows 3.1 and Openlink implementation. unixODBC doesnt need that list of the drivers in the file, it just looks at the drivers in the file. May not be perfect for some value of perfect but there you go." He also said "Generally, I would suggest never using default anything, its opening a world of confusion and pain, especially when you have user and system odbcinst.ini and odbc.ini on some platforms and 32 and 64 bit versions and possibly shared ini files to add to the mix." I hope that clears something up. Of course, unixODBC is OS so if you don't like it.... |
|
Yes, I have tried that, and it works, but that's not setting a default. That's just another driver that happens to be named "default". I don't get that that's what unixODBC means when it says "no default driver specified." |
a/k/a the standard-compliant implementations. Microsoft wrote and maintains the ODBC standard, with which iODBC (which I guess would be what Nick meant by the "OpenLink implementation") complies. Non-compliant |
|
Well maybe I should try iODBC. I agree about the world of pain for the general case, but this is essentially shipping a database app, not a driver management system. |
|
@theory - You may not find much difference with iODBC in the mix, because of the ODBC API calls being issued by DBD::ODBC, and the arguments it's applying. I would strongly recommend that you just use the |
|
@TallTed I wish there were standard driver names, then I could just make a default in my app. But no, someone could change the name to "SNWFLK" or something and it wouldn't work. I could maybe patch Sqitch in this Docker image to assign a Driver to the DSN if it doesn't have one, since inside the image there is only one, anyway. |
|
@theory - Are you not putting the driver in the image, along with your app, and the driver manager? And building these config files? The name in the |
|
Yes, but the URLs are used outside the image, passed to it. |
All the more reason to include the driver name you specify in what should be include in the URLs used with your tool. The more pieces you add about how this thing (which I've never used) is meant to work, the more I think you're currently working to solve the wrong problems -- including at least some problems which are likely to never exist -- by trying to make the |
|
I think I've been confused. I've been assuming it was possible to set up a default driver in the ODBC configuration. The docs @TallTed linked to in his SO answer seem to suggest as much. But through all this discussion, I'm suspecting that I may have been misunderstanding the error: I had been assuming that this meant that no default driver was configured on the host. But I think now perhaps, what it actually means is "Cannot find the DSN in the URL, and there was no |
|
@mjegh Can you confirm the above interpretation with Nick Gorham? Thanks! |
|
I'll try when I see him next week. |
theory
changed the title
Make the default DSN the same as the Snowflake account name, and make Snowflake the default driver (though it does not currently work; see #16 for details). Also update the versions of SnowSQL and the Snowflake ODBC driver and ensure that only master or version branch builds get pushed to Docker hub.
based on discussion at https://stackoverflow.com/questions/57084677/how-do-i-configure-a-default-driver-for-unixodbc/57102585