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.

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.

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.

* 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.

* Stored procedure execution, parameter passing (including NULL's) and
output retrieval.
Nice.    I haven't worked on this yet at all for PHP ODBC.

* 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 discovered memory leaks or buffer overflow possibilities.
If you know of any in the current PHP ODBC, let us know.


>---------------------------------------------------------------<
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

Reply via email to