Hi Dan Below, I have addressed each of your comments. Keep in mind that ODBTP is not a replacement for ODBC. The motivation for ODBTP was to devise a scheme that would make it easy to keep up with Microsoft's perpetual changes in the TDS protocol. Which from my research appears to be the biggest headache for FreeTDS and ODBC driver developers. ODBTP is less susceptible to this because it is an interface to ODBC drivers installed on a Windows NT / 2000 server. And, so far, Microsoft is still providing full support for its ODBC drivers on Windows Platforms. Also, if they stop supporting ODBC in the future, the ODBTP service can be changed to interface with the new methodology without changing the ODBTP protocol.
> On Saturday, November 2, 2002, at 12:38 PM, Robert Twitty wrote: > > its capabilities and useless in certain situations. Another > > alternative > > was to use a commercial ODBC driver management system on UNIX. Sadly, > > it > > was not in the budget for this endeavor, and the PHP odbc extensions > > could > > use some work in terms of ease of use. > > I tend to disagree with this bit. The ODBC system is no more > complicated than any of the other database interfaces you find on PHP. > There is the needed introduction of a odbc.ini file, but thats no more > confusing than the need for a TNS Names with Oracle. If you have a > problem with the way ODBC is implemented, please feel free to request > new features via the bug system, submit patches, or emailing me > directly. I have in the past asked numerous times for input on the > extension only to receive silence. > Upon further review, you are probably correct. However, working directly with ODBC can be a daunting task for some people. > More importantly, what commercial ODBC system are you looking at? > unixODBC, and iODBC work wonderfully for UNIX, and both are free and > integrated completely with PHP. > The problem with the free versions was that they did not appear to provide support SQL Server 7.0 / 2000 new features. In fact, Microsoft's DB-Library and early ODBC driver versions do not support all of them either. > > Because I was determined to use PHP (I really dislike using JSP / JDBC > > on > > UNIX, and IIS / ASP is out of the question), I decided to create my > > own > > solution. Since I have a substantial amount of experience in > > programming > > directly with the Win32 ODBC API and TCP/IP, I decided to create a > > service > > that runs on a Win32 platform that can communicate with any platform > > via > > TCP/IP. The service uses a "home grown" protocol that allows a client > > to > > access any database that the service can see via the ODBC drivers that > > are > > installed on the computer which it resides. In other words, it allows > > a PHP > > client on UNIX to access a database using the ODBC drivers installed > > on a > > Windows NT / 2000 server. It is nothing more than a middle man > > service for > > Win32 ODBC. The name of the service is called ODBTP (Open Database > > Transport Protocol), and no there is not a RFC for this protocol. > > Thus > > far, I have successfully accessed MS-SQL, Oracle and Sybase databases > > via > > ODBTP. > > This sounds like a lot of work to re-implement the ODBC system. > On the contrary, ODBC was not re-implemented. ODBTP requires it, but on a Windows NT / 2000 Server platform. ODBTP is a client / server wrapper around the Win32 ODBC API. > > * Supports all data types, including nvarchar, ntext, varchar(>255), > > char(>255), datetime, and bigint. > > I'd like to know how you got around this. It's proven to be a bigger > headache in supporting for ODBC than I would have imagined. > The ODBTP protocol was designed to handle these new data types. It retrieves data from Microsoft ODBC drivers that fully support these data types, and then sends it to the client via the ODBTP protocol which was designed to accomadate them. The problem you are probably faced with is that the UNIX ODBC drivers do not use or have not fully implemented the new (and supposedly not publically documented) TDS protocol used by SQL Server 7.0 / 2000. > > * Stored procedure execution, parameter passing (including NULL's) and > > output retrieval. > > Nice. I haven't worked on this yet at all for PHP ODBC. > Again, the ODBTP protocol has facilities that make this possible. > > * UNICODE data is processed using UTF-8 encoding (important since PHP > > strings are not UNICODE) > > This is being worked upon. Hopefully I'll have free time again soon. > No problem, UTF-8 works quite well in PHP. > > * No discovered memory leaks or buffer overflow possibilities. > > If you know of any in the current PHP ODBC, let us know. > This was not meant to be a point of contention with PHP, but rather with Win32 based services that tend to suffer more from these problems. -- bob > > >---------------------------------------------------------------< > Dan Kalowsky "I'll walk a thousand miles just > http://www.deadmime.org/~dank to slip this skin." > [EMAIL PROTECTED] - "Streets of Philadelphia", > [EMAIL PROTECTED] Bruce Springsteen > > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
