Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [PATCH] --with-ODBCRouter (database networking) »

[PATCH] --with-ODBCRouter (database networking)

php.internals

AugSoft

21 years ago
Hi, + This patch enables PHP's ODBC extension on certain non-Windows platforms (Linux, Mac OS X, etc.) to transparently interact with any of the data sources listed in the SystemDSN property-tab of the "Data Sources (ODBC) Control Panel" on a networked Windows NT4/2K/XP box running our ODBC Router. Once installed, the PHP scripts will appear to be fully-supported Windows applications to virtually any data source while the data sources themselves, which may be on mainframe, mini, *NIX, Mac or Windows, will appear to be local to the PHP script. All database communication takes place transparently, via high-performance binary TCP/IP connections (not XML, TELNET, etc.) This technology was introduced in 1995 and the product system is in use by FORTUNE 500 companies and at sites across Asia, Canada, Europe, Oceania and the US. + Once applied, support for ODBCRouter may be compiled into PHP 4.3 by simply adding "--with-ODBCRouter" to the configure command. The only pre-compile-time configuration required is to install our free runtime library. The only post-compile configuration required is to specify the IP address of the PC running ODBC Router in /etc/odbcrouter.conf (at which point, all DSNs on that PC may be referenced from within local PHP scripts). + Currently, ODBC Router users with PHP 4.3.10 on Linux-X86 follow these procedures: # rpm -ivh http://odbcrouter.com/m/linux-x86 # rpm -qi iodbc.net (instructions) + However, attached to this message are two patch files, one for the current 4.3.10 release (also distributed in the above RPM) and one for the current cvs release (as of the date of this message) for incorporation into the main-line code base. + ODBC Router client components, such as the iodbc.net runtime library for Linux, are freely distributable. Interested parties may also download evaluation ODBC Router servers from http://odbcrouter.com/downloadns.shtml + Official PHP developers and the first 100 significant code contributors may receive a complimentary (no charge) ODBC Router server for their NT4/2K/XP box by e-mailing us with enough info for us to confirm their actual project participation. Very Kind Regards, August Software

Andi Gutmans

21 years ago
Just out of curiosity, how does ODBC Router differ from the other ODBC bridge solutions out there? Also, you should probably also provide PHP 5 diffs. Andi At 09:02 AM 1/7/2005 -0800, AugSoft wrote:

Michael Sims

21 years ago
Andi Gutmans wrote:
> At 09:02 AM 1/7/2005 -0800, AugSoft wrote: >> + This patch enables PHP's ODBC extension on >> certain non-Windows platforms (Linux, Mac OS X, > > Just out of curiosity, how does ODBC Router differ from the other ODBC > bridge solutions out there?
Sorry for the arguably off-topic nature of this, but I just want to point out for those here who haven't seen it that there's some pretty shameful (and possibly libelous) FUD about FreeTDS at the ODBC Router site here: http://odbcrouter.com/FAQfreetds.shtml Example: <quote> Third-party "wire-level" products depend upon a third-party reverse-engineering of the database server's network protocols, meaning they can crash your database server. Customers may lose data and experience downtime trying to recover when so-called "wire-level" drivers are used either intentionally, or as Internet viruses like "SQLSlammer". Actually paying someone for a "wire-level" driver may even encourage the spread of such viruses since quite often, they are releasing their reverse-engineering work out into the "open source" world. ... Moreover, using an "unauthorized" client like FreeTDS with your proprietary database server may be a violation of the Digital Millenium Copyright Act, a new federal law prohibiting financial benefit from the unauthorized reverse engineering of licensed materials, such as the TDS protocol owned by the shareholders of NYSE:SY. </quote> There's more on the page if you care to read it. I'll refrain from adding any additional commentary to this; I believe it speaks volumes for itself... Disclaimer: The opinion expressed above is my own, and does not necessarily reflect that of my employer.

AugSoft

21 years ago
Michael Sims:
>Sorry for the arguably off-topic nature of this, >but I just want to point out..
Please do not quote our website in the PHP internals list. The quotations that you have already made here carefully omitted the second of three paragraphs that present case evidence to support the assertions that you have challenged. Note that ODBC Router was developed by former DEC, NASA and JPL people with at least 20 years of experience each.

AugSoft

21 years ago
On Mon, 10 Jan 2005, Andi Gutmans wrote: Hi,
> ...you should probably also provide PHP 5 diffs.
Ok, we will queue this up.
> Just out of curiosity, how does ODBC Router > differ from the other ODBC bridge solutions out > there?
This could be off-topic, so we can only respond in summary and ask for any follow-ups to be directed only to info@augsoft.com + Early support of Macintosh meant that we had to be multi-network (TCP/IP, Appletalk, etc..), easy to use and, most importantly, able to support hundreds of high-end Motorola or IBM chips demanding data through a single Wintel box. We accomplish this with technology that keeps all of the inter-architecture data conversions (endian flipping, floating-point conversions, etc.) on the client-side, as opposed to allowing per-client conversions on the shared Wintel box. Our server architecture also makes use of system-level technologies like async I/O, multi-buffering, memory-mapped sections, multi-processing and multi-threading. To the Macs, PCs and Linux boxes it "just works" --to the database servers, the world continues to look Wintel. This enables Macs, PCs and Linux to always have access to the latest and greatest database drivers and support for the thousands of versions of hundreds of database systems on the market. + As far as the "other ODBC bridge solutions out there" go, one must realize that many of them have typically gone with all-ASCII/XML database sessions. This means they built their shared server components in a way that requires them to perform one-half of all of the data transformations for every client in the customer's network. ASCII/XML is perhaps the most expensive data transformation possible --and they have 1/2 of that occuring in shared server space. Because they have no optimizations for any specific architecture, it was also easy for their server components to run on a whole host of non-Windows platforms. This buys them a lot of political clout with customers who choose not to run Wintel boxes (even $299 DELLs bolted into a telco rack), nevermind the fact that database vendors do not consistently support non-Windows platforms (hence the very need for these kinds of solutions).

Dan Kalowsky

21 years ago
I'm not sure I'm sold on this whole concept yet. I don't see how this differs from the use of an ODBC Driver or an ODBC Driver Manager. Admittedly I haven't investigated it very throughly yet, but the Macintosh already has unixODBC and iODBC working with it (your example not mine). Both allow connections to cross platform databases regardless of datasets. Both read data sets regardless of endian nature. The very definition of ODBC is for open connectivity, regardless of client platform, as a long as the client conforms to a version of the spec. Much of what you've just quoted as being reasons to use ODBCRouter are the reason ODBC itself exists. I haven't looked at the patches yet, so is this just another drive manager?
>---------------------------------------------------------------<
Dan Kalowsky "I thought you died alone, http://www.deadmime.org/~dank a long long time ago." dank-nom@aps-deadmime.org - "The Man Who Sold the World" kalowsky@php.net David Bowie

Andi Gutmans

21 years ago
I have no idea about ODBCRouter but for what it's worth unixODBC and iODBC aren't the best and most performant solutions (at least as far as I know). So if this is an equivalent, I see no reason not to support it. Andi At 11:20 AM 1/11/2005 -0800, Dan Kalowsky wrote:

Wez Furlong

21 years ago
I think the question is whether we need a patch, or if ODBCRouter is a compatible ODBC driver that can be loaded via unixODBC or iODBC, requiring no patch and possibly taking advantage of optimizations that might be present in those ODBC managers (can't think of any off the top of my head). Of course, if running via a manager introduces a performance hit, then running direct is good. --Wez. On Tue, 11 Jan 2005 16:36:21 -0800, Andi Gutmans <andi@zend.com> wrote:

Wez Furlong

21 years ago
I've educated myself by reading the odbcsdk.h file; ODBCRouter doesn't implement ODBC 3.0 APIs, so it can't be used directly for the PDO ODBC extension, but it should be loadable via unixODBC or iODBC. Regardless, this patch looks safe to commit to our CVS for ext/odbc; it's a few lines of configure script and a few lines of ODBCRouter specifics (surrounded by ifdefs) when initiating a connection. --Wez. On Tue, 11 Jan 2005 20:24:05 -0500, Wez Furlong <kingwez@gmail.com> wrote:

Dan Kalowsky

21 years ago
Please don't make broad statements that iODBC and unixODBC are not fast. They are plenty fast. They run slow in PHP because we use a dynamic cursor, no other reason can/should be attributed to their performance in PHP. Our continued use of the dynamic cursor is mostly for BC and my unwillingness to deal with the fallout of changing it (again). As far as including the ODBCRouter in the PHP code, I wanted to know more about what it is before it goes further. The website is full of non-useful information regarding what ODBCRouter does. If it's another driver manager, I see no problem including it. If it is another case of "we want our proprietary driver included" I'm voting against it. I would much rather see the uODBC work primarily with driver managers, than becoming a driver manager of our own design. As I said, from the literature found online, I cannot tell which of these it really falls into. On Tue, 11 Jan 2005, Andi Gutmans wrote:
> I have no idea about ODBCRouter but for what it's worth unixODBC and iODBC > aren't the best and most performant solutions (at least as far as I know). So > if this is an equivalent, I see no reason not to support it. > > Andi > > At 11:20 AM 1/11/2005 -0800, Dan Kalowsky wrote: >> I'm not sure I'm sold on this whole concept yet. I don't see how this >> differs from the use of an ODBC Driver or an ODBC Driver Manager. >> >> Admittedly I haven't investigated it very throughly yet, but the Macintosh >> already has unixODBC and iODBC working with it (your example not mine). >> Both allow connections to cross platform databases regardless of datasets. >> Both read data sets regardless of endian nature. >> >> The very definition of ODBC is for open connectivity, regardless of client >> platform, as a long as the client conforms to a version of the spec. Much >> of what you've just quoted as being reasons to use ODBCRouter are the >> reason ODBC itself exists. >> >> I haven't looked at the patches yet, so is this just another drive >> manager? >> >> >>> ---------------------------------------------------------------< >> Dan Kalowsky "I thought you died alone, >> http://www.deadmime.org/~dank a long long time ago." >> dank-nom@aps-deadmime.org - "The Man Who Sold the World" >> kalowsky@php.net David Bowie >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >
>---------------------------------------------------------------<
Dan Kalowsky "I thought you died alone, http://www.deadmime.org/~dank a long long time ago." dank-nom@aps-deadmime.org - "The Man Who Sold the World" kalowsky@php.net David Bowie

Mike Robinson

21 years ago
Dan Kalowsky wrote:
> As far as including the ODBCRouter in the PHP code, I wanted > to know more about what it is before it goes further.
Absolutely.
> The website is full of non-useful information regarding what > ODBCRouter does.
Well, you're too kind. I found the information contained therein misleading and extremely self-aggrandizing. For example, there is an explicit statement that the driver is "recommended by Microsoft worldwide", and then links to page on Microsoft's site that simply states that the driver is required if you wish to pull data from MS Access 98 into Excel 98. Hardly a reason to include it in PHP's core.
> If it is another case of "we want our proprietary driver included" > I'm voting against it.
I believe that is the case. Mike Robinson

Wez Furlong

21 years ago
Regardless of how self important a patch submitter may sound, there is no *technical* reason why this patch should not go into PHP; it's not as though we have a phobia of ODBC drivers. --Wez. On Wed, 12 Jan 2005 19:47:14 -0500, Mike Robinson <mike@fiddy8.com> wrote:

Wez Furlong

21 years ago
I committed the patch to HEAD; I'll leave it to the release masters to decide if they want it in the next 4.3 and 5 releases. --Wez. On Wed, 12 Jan 2005 21:03:41 -0500, Wez Furlong <kingwez@gmail.com> wrote:

Dan Kalowsky

21 years ago
On Jan 12, 2005, at 6:03 PM, Wez Furlong wrote:
> Regardless of how self important a patch submitter may sound, there is > no *technical* reason why this patch should not go into PHP; it's not > as though we have a phobia of ODBC drivers.
There is a technical reason to avoid it if you've listened to any of my past efforts to move uODBC forward in time. If it is not a driver manager, it moves the uODBC further to being a driver manager... something I have been trying to avoid. I am against continuing the process of directly linking into database specific drivers, for various reasons but mostly to cut down on the issues of lack of support. You can cite all the rhetoric you want about slowing down the execution time you want. I don't buy it, nor do I have the time or resources to continue in the "we'll support everything" manner we're running in. The end result you've taken your route with PDO, please allow me to continue my route with uODBC.

Wez Furlong

21 years ago
On Wed, 12 Jan 2005 18:46:24 -0800, Dan Kalowsky <dank@deadmime.org> wrote:
> There is a technical reason to avoid it if you've listened to any of my > past efforts to move uODBC forward in time.
No offense Dan, but ext/odbc has been idle for more than a year; please don't take it personally when I state that this is not really moving forward in time.
> If it is not a driver > manager, it moves the uODBC further to being a driver manager... > something I have been trying to avoid.
OK, but this is a trivial patch.
> I am against continuing the > process of directly linking into database specific drivers, for various > reasons but mostly to cut down on the issues of lack of support.
There is no support issue in this case. (think about it: the vendor supplied the patch in the first place)
> You can cite all the rhetoric you want about slowing down the execution > time you want.
I didn't, and if you cared to notice, I was actually "on your side" when I first joined the thread. I evaluated the patch (have you?) and discovered that it is a couple of lines of configure script and a couple of lines of C code to sort out the DSN.
> I don't buy it, nor do I have the time or resources to > continue in the "we'll support everything" manner we're running in.
Like I said, we're hardly "running" if the code has been idle for a year. I'll bet you've spent (or will spend) more time arguing on this thread than you've spent supporting odbc over this last year--again, nothing personal--but moaning about support costs for a trivial patch is a waste of time. The fact of the matter is that the patch has no negative impact while providing more functionality to PHP. --Wez.

AugSoft

21 years ago
Hi Dan, Wez, Mike, Andi and list: Thank you for graciously debating the merits of our patch, we are honored to receive your attention. As Mac-heads dating back a few decades you can appreciate our pre-occupation with the annual MacWorld events of the past several days, hence the brief delay in responding here. As has been pointed out, there are only a few lines of code contained in the patches submitted for your project community. The net effect of this is to connect PHP into the official Microsoft ODBC Driver Manager hosted on a centrally administered Windows box. We are certain that this is of substantial value to a significant number of your users. In the case of driver vs. driver manager debate, we do not find it useful for clients to have to configure a driver manager on each client, in addition to the central ODBC control panel on the Windows server. The patches we submitted allow for a system whereby all of the data sources are centrally administered in a single control panel on the Windows server and may then simply be referenced by name from any PHP client. If uODBC = unixODBC, please be advised that Apple (with 14 million installed UNIX systems) and many other major vendors have embraced the alternative to unixODBC, called iODBC. We cannot speak for Apple and others, but we do not feel comfortable supporting unixODBC because the principals who apparently control unixODBC also control a domain name called openlink.com which is obviously confusing to clients of OpenLink Software. Besides this credibility issue, there is information on a website at http://www.cinema.com/legal/about.phtml which we find very concerning and so it is unlikely we will ever support unixODBC. As far as some other comments that have been made to these lists about the relative merits of our product, etc.. there are many customers of our competitors products and, well, the above situation clearly spells out what kind of competitors we have and we know they are here as well. Therefore, we don't know what's real in these comments and, in any case, we just don't feel comfortable engaging in that kind of discussion on a PHP internals technical list. We have offered up some 100 no-charge licenses for significant contributors to the PHP effort to put back into the community and so this is not really about money, it is about patches. Thank you again for your consideration and please feel free to present any tech issues to us! Great work PHP team! Tom @ AUGSOFT, 1990->2005->2090 On Wed, 12 Jan 2005, Dan Kalowsky wrote:

Andi Gutmans

21 years ago
I think HEAD is good enough for PHP 5. At 09:08 PM 1/12/2005 -0500, Wez Furlong wrote:

Andi Gutmans

21 years ago
Dan, I don't feel very strong about this so I'll leave it up to you guys but there are almost no code changes so I don't quite understand why it'd be so terrible for the extension. Andi At 06:46 PM 1/12/2005 -0800, Dan Kalowsky wrote: