Re: Mutiple ODBC APIs?
drewhead wrote: Well, if you have DBD-ODBC working I would expect the same ini settings could be used to get it working under a driver manager. Just what made you think it wouldn't work ? -- Nick Gorham Easysoft Ltd You mean initially the way I set it up incorrectly? I didn't know enough about what I was doing to make the distinction between a manager and a driver. You and others in the thread have given me that education, thanks. Moving forward I do not have DBD-ODBC working correctly with a manager... yet. Given that I have DBD-ODBC using a driver in use, how do I compile/intsall/test DBD-ODBC with a manager plugging in my driver which no one yet has confirmed will work without showing my users any noticiable downtime. I'm not a particularly fast typer. :) I guess it's fair to say I have a healty fear of putting unknowns into production. This also really gets beyond the scope of the list (sorry folks). I think I'll just build another perl install for testing. -- Drew Sure, if its working don't break it, but if you do need other connections it will probably work out simpler to use a driver manager in the long run. -- Nick Gorham Easysoft Ltd
Re: Mutiple ODBC APIs?
Jeff, perhaps I have misunderstood what is going on here but it is my impression that DBD-ODBC is being built against propriety interfaces that look like an ODBC API library but in fact will only communicate with a specific DBMS. One such example is SAP-DB. If this propriety build of DBD-ODBC will only work with a propriety DBMS it is my opinion that it should not be called DBD-ODBC, instead the module should be renamed to reflect its specific purpose, in order to properly describe the DBD's function and allow the loading of the real DBD-ODBC at the same time. -- Simon Oliver Jeff Urlwin wrote: Simon, You should be able to build DBD::ODBC against a driver manager such as unixODBC or iODBC (the assumed way to do it from my perspective, in fact). The driver manager will then talk to SAP DB, etc. Jeff -Original Message- From: Simon Oliver [mailto:[EMAIL PROTECTED]] Sent: Friday, February 01, 2002 11:11 AM To: drewhead Cc: [EMAIL PROTECTED] Subject: Re: Mutiple ODBC APIs? I raised this issue with the SAP DB driver (it does a simillar thing apparently). I've had no response from the SAP DB people as yet. IMHO, compiling DBD::ODBC against a proprietry interface should not be allowed without a name change to the module. -- Simon Oliver drewhead wrote: I have a properiterary ODBC API that I've compiled DBD::ODBC for with a bit of hair pulling and hand holding from someone who had done it before. :) Works just fine. Now I find that I have a need to connect to a MsSql server from the same box... in the same perl program no less! I didn't really think it would, but when trying to connect to the MsSql server uing the properitary API I get a Protocol error. Can I compile mutiple APIs into DBD::ODBC (and how)? Can I build and use a seperate DBD::ODBC module with an MS compatible ODBC API? Am I barking up the wrong tree and should look at another method? -- [EMAIL PROTECTED]
Re: Mutiple ODBC APIs?
Yes Oliver, this is my understanding of the issue. As long as we're talking specfics, this is a ODBC API for RedBrick, an IBM product formerly Informix (no DBD-Infomix isn't for the DBMS). I actually did try iODBC first, but was unsuccessful. Upon asking on the RedBrick list I was contacted by a helpful user who showed me how it could be done linking some of the libs (that have an extra 'rb' in their name). Alas, I've now coded myself into a corner needing access to other drivers that this 'interface' can't handle. If the solution here is to compile what I currently have working with RB to a diffrent name, perhaps RBODBC, I'll certianly give that a shot. I don't think I've ever changed a module's name. Is there anything to be aware of besides wholesale %s/ODBC/RBODBC/g? -- Drew Jeff, perhaps I have misunderstood what is going on here but it is my impression that DBD-ODBC is being built against propriety interfaces that look like an ODBC API library but in fact will only communicate with a specific DBMS. One such example is SAP-DB. If this propriety build of DBD-ODBC will only work with a propriety DBMS it is my opinion that it should not be called DBD-ODBC, instead the module should be renamed to reflect its specific purpose, in order to properly describe the DBD's function and allow the loading of the real DBD-ODBC at the same time. -- Simon Oliver Jeff Urlwin wrote: Simon, You should be able to build DBD::ODBC against a driver manager such as unixODBC or iODBC (the assumed way to do it from my perspective, in fact). The driver manager will then talk to SAP DB, etc. Jeff
RE: Mutiple ODBC APIs?
Simon, Yes, I understand what you are saying. I hope this will clear it up a bit. DBD::ODBC *allows* you to build against the proprietary databases. I can see why some like it, because it's easier to be setup. Yes, it should probably change it's name to DBD::SAPDB, etc. I'll have to think about that one. However, DBD::ODBC prefers to be build against a driver manager and have the driver manager talk to the specific driver. That's how it is by default on Win32 and that's why, originally, we included a release of iODBC within the tarball. To *encourage* people to use a driver manager. I'll look into the work involved to rename itself (but that may be difficult or painful) during the Makefile.PL stage. I can honestly say it's a lower priority for me as I think the situation should be handled by utilizing a driver manager. If you build against the driver itself, then caveat emptor... Jeff -Original Message- From: Simon Oliver [mailto:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 4:35 AM To: Jeff Urlwin Cc: drewhead; [EMAIL PROTECTED] Subject: Re: Mutiple ODBC APIs? Jeff, perhaps I have misunderstood what is going on here but it is my impression that DBD-ODBC is being built against propriety interfaces that look like an ODBC API library but in fact will only communicate with a specific DBMS. One such example is SAP-DB. If this propriety build of DBD-ODBC will only work with a propriety DBMS it is my opinion that it should not be called DBD-ODBC, instead the module should be renamed to reflect its specific purpose, in order to properly describe the DBD's function and allow the loading of the real DBD-ODBC at the same time. -- Simon Oliver Jeff Urlwin wrote: Simon, You should be able to build DBD::ODBC against a driver manager such as unixODBC or iODBC (the assumed way to do it from my perspective, in fact). The driver manager will then talk to SAP DB, etc. Jeff -Original Message- From: Simon Oliver [mailto:[EMAIL PROTECTED]] Sent: Friday, February 01, 2002 11:11 AM To: drewhead Cc: [EMAIL PROTECTED] Subject: Re: Mutiple ODBC APIs? I raised this issue with the SAP DB driver (it does a simillar thing apparently). I've had no response from the SAP DB people as yet. IMHO, compiling DBD::ODBC against a proprietry interface should not be allowed without a name change to the module. -- Simon Oliver drewhead wrote: I have a properiterary ODBC API that I've compiled DBD::ODBC for with a bit of hair pulling and hand holding from someone who had done it before. :) Works just fine. Now I find that I have a need to connect to a MsSql server from the same box... in the same perl program no less! I didn't really think it would, but when trying to connect to the MsSql server uing the properitary API I get a Protocol error. Can I compile mutiple APIs into DBD::ODBC (and how)? Can I build and use a seperate DBD::ODBC module with an MS compatible ODBC API? Am I barking up the wrong tree and should look at another method? -- [EMAIL PROTECTED]
RE: Mutiple ODBC APIs?
Drew, I think you'd be better off with unixODBC or iODBC and getting the driver manager to work. It will be better in the long run to get that straight, then finding out you need to upgrade and having to do the work over again. Jeff -Original Message- From: drewhead [mailto:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 8:11 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Mutiple ODBC APIs? Yes Oliver, this is my understanding of the issue. As long as we're talking specfics, this is a ODBC API for RedBrick, an IBM product formerly Informix (no DBD-Infomix isn't for the DBMS). I actually did try iODBC first, but was unsuccessful. Upon asking on the RedBrick list I was contacted by a helpful user who showed me how it could be done linking some of the libs (that have an extra 'rb' in their name). Alas, I've now coded myself into a corner needing access to other drivers that this 'interface' can't handle. If the solution here is to compile what I currently have working with RB to a diffrent name, perhaps RBODBC, I'll certianly give that a shot. I don't think I've ever changed a module's name. Is there anything to be aware of besides wholesale %s/ODBC/RBODBC/g? -- Drew Jeff, perhaps I have misunderstood what is going on here but it is my impression that DBD-ODBC is being built against propriety interfaces that look like an ODBC API library but in fact will only communicate with a specific DBMS. One such example is SAP-DB. If this propriety build of DBD-ODBC will only work with a propriety DBMS it is my opinion that it should not be called DBD-ODBC, instead the module should be renamed to reflect its specific purpose, in order to properly describe the DBD's function and allow the loading of the real DBD-ODBC at the same time. -- Simon Oliver Jeff Urlwin wrote: Simon, You should be able to build DBD::ODBC against a driver manager such as unixODBC or iODBC (the assumed way to do it from my perspective, in fact). The driver manager will then talk to SAP DB, etc. Jeff
Re: Mutiple ODBC APIs?
Nick Gorham wrote: drewhead wrote: Yes Oliver, this is my understanding of the issue. As long as we're talking specfics, this is a ODBC API for RedBrick, an IBM product formerly Informix (no DBD-Infomix isn't for the DBMS). I actually did try iODBC first, but was unsuccessful. Upon asking on the RedBrick list I was contacted by a helpful user who showed me how it could be done linking some of the libs (that have an extra 'rb' in their name). Alas, I've now coded myself into a corner needing access to other drivers that this 'interface' can't handle. If the solution here is to compile what I currently have working with RB to a diffrent name, perhaps RBODBC, I'll certianly give that a shot. I don't think I've ever changed a module's name. Is there anything to be aware of besides wholesale %s/ODBC/RBODBC/g? -- Can someone point me to where I can get a copy of this driver and a database to connect to and I will see why there are problems with driver managers. -- Nick Gorham Easysoft Ltd Ok, I downloaded a copy of informix-se and the client libs, it was a bit of a hack, but it seems to work under unixODBC ok. The driver does its own thing about ini files, so what I did was link the user dsn (/root/.odbc.ini in this case) which is what the driver was looking in to the system dsn one. However you could just use a user dsn. The odbcinst.ini entry is [INFORMIX] Driver = /opt/informix/lib/cli/libifcli.so FileUsage = 1 the odbc.ini entry [Infdrv33] Driver=Informix Description=INFORMIX 3.3 32-BIT Database=/opt/informix/bin/stores7 Servername=demo_se CursorBehavior=0 CLIENT_LOCALE=en_us.8859-1 DB_LOCALE=en_us.8859-1 TRANSLATIONDLL=/opt/informix/lib/esql/igo4a304.so It connects with the DBD:ODBC make test, but fails as it doesn't seem to support any long types (well looking at the output from SQLGetTypeInfo it doesn't) -- Nick Gorham Easysoft Ltd
Re: Mutiple ODBC APIs?
On Mon, Feb 04, 2002 at 11:05:32AM -0500, Jeff Urlwin wrote: Simon, Yes, I understand what you are saying. I hope this will clear it up a bit. DBD::ODBC *allows* you to build against the proprietary databases. I can see why some like it, because it's easier to be setup. Yes, it should probably change it's name to DBD::SAPDB, etc. I'll have to think about that one. It's at this point that I'd usually say something like patches welcome :) Tim.
Mutiple ODBC APIs?
I have a properiterary ODBC API that I've compiled DBD::ODBC for with a bit of hair pulling and hand holding from someone who had done it before. :) Works just fine. Now I find that I have a need to connect to a MsSql server from the same box... in the same perl program no less! I didn't really think it would, but when trying to connect to the MsSql server uing the properitary API I get a Protocol error. Can I compile mutiple APIs into DBD::ODBC (and how)? Can I build and use a seperate DBD::ODBC module with an MS compatible ODBC API? Am I barking up the wrong tree and should look at another method? -- [EMAIL PROTECTED]
Re: Mutiple ODBC APIs?
I raised this issue with the SAP DB driver (it does a simillar thing apparently). I've had no response from the SAP DB people as yet. IMHO, compiling DBD::ODBC against a proprietry interface should not be allowed without a name change to the module. -- Simon Oliver drewhead wrote: I have a properiterary ODBC API that I've compiled DBD::ODBC for with a bit of hair pulling and hand holding from someone who had done it before. :) Works just fine. Now I find that I have a need to connect to a MsSql server from the same box... in the same perl program no less! I didn't really think it would, but when trying to connect to the MsSql server uing the properitary API I get a Protocol error. Can I compile mutiple APIs into DBD::ODBC (and how)? Can I build and use a seperate DBD::ODBC module with an MS compatible ODBC API? Am I barking up the wrong tree and should look at another method? -- [EMAIL PROTECTED]
RE: Mutiple ODBC APIs?
The easiest way to do that is to compile DBD::ODBC to use a driver manager such as unixODBC or iODBC, depending upon your platform, etc. The driver manager, through odbc.ini or other config files, will talk directly to the drivers. It soulds like you have built DBD::ODBC to connect directly to a driver. I presume you are not running under Windows/Win32... I presume you have the correct driver to talk to MS SQL Server from your platform (i.e. www.easysoft.com or www.Openlinksw.com from unix). Jeff -Original Message- From: drewhead [mailto:[EMAIL PROTECTED]] Sent: Friday, February 01, 2002 9:24 AM To: [EMAIL PROTECTED] Subject: Mutiple ODBC APIs? I have a properiterary ODBC API that I've compiled DBD::ODBC for with a bit of hair pulling and hand holding from someone who had done it before. :) Works just fine. Now I find that I have a need to connect to a MsSql server from the same box... in the same perl program no less! I didn't really think it would, but when trying to connect to the MsSql server uing the properitary API I get a Protocol error. Can I compile mutiple APIs into DBD::ODBC (and how)? Can I build and use a seperate DBD::ODBC module with an MS compatible ODBC API? Am I barking up the wrong tree and should look at another method? -- [EMAIL PROTECTED]
RE: Mutiple ODBC APIs?
Simon, You should be able to build DBD::ODBC against a driver manager such as unixODBC or iODBC (the assumed way to do it from my perspective, in fact). The driver manager will then talk to SAP DB, etc. Jeff -Original Message- From: Simon Oliver [mailto:[EMAIL PROTECTED]] Sent: Friday, February 01, 2002 11:11 AM To: drewhead Cc: [EMAIL PROTECTED] Subject: Re: Mutiple ODBC APIs? I raised this issue with the SAP DB driver (it does a simillar thing apparently). I've had no response from the SAP DB people as yet. IMHO, compiling DBD::ODBC against a proprietry interface should not be allowed without a name change to the module. -- Simon Oliver drewhead wrote: I have a properiterary ODBC API that I've compiled DBD::ODBC for with a bit of hair pulling and hand holding from someone who had done it before. :) Works just fine. Now I find that I have a need to connect to a MsSql server from the same box... in the same perl program no less! I didn't really think it would, but when trying to connect to the MsSql server uing the properitary API I get a Protocol error. Can I compile mutiple APIs into DBD::ODBC (and how)? Can I build and use a seperate DBD::ODBC module with an MS compatible ODBC API? Am I barking up the wrong tree and should look at another method? -- [EMAIL PROTECTED]
Re: Mutiple ODBC APIs?
Simon Oliver wrote: I raised this issue with the SAP DB driver (it does a simillar thing apparently). I've had no response from the SAP DB people as yet. IMHO, compiling DBD::ODBC against a proprietry interface should not be allowed without a name change to the module. This may sound a bit harsh, but isn't a proprietary ODBC interface a contradiction ? Wouldn't it be better to get the interface working behind a driver manager (Ok I am biased on that one), the DM could well help make it more of a standard ODBC interface then. Nick Gorham
