Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip

Can you also try PDO_ODBC to see if it has a similar issue?

The latest snapshot is installed along with PDO and pdo_odbc. pdo_odbc was compile with 
./configure --with-unixODBC
Php (php5-200511072130) was compiled the same as before.

Using pdo_mysql connects fine to a mysql database. However, using odbc with the third party provided driver(Thoroughbred Proprietary DBMS), I'm getting segfaults again. However, still no problems using isql. The backtrace of using pdo is as follows. Please let me know if you would like another backtrace of just the vanilla odbc without pdo using the latest snapshot. I also have odbc trace files if needed.

#0  0x00000000 in ?? ()
#1  0xb6f66f05 in extract_sql_error (henv=0x0, hdbc=0x8434a78, hstmt=0x0,
    connection=0x8431480, head=0x84319f0, return_code=1) at __info.c:4365
#2  0xb6f67976 in function_return_ex (level=2, handle=0x8431480, ret_code=1,
    save_to_diag=138613888) at __info.c:4998
#3  0xb6f3ef17 in SQLDriverConnect (hdbc=0x8431480, hwnd=0x0,
    conn_str_in=0x8436bcc "DSN=CUSTOMER;UID=tsi", len_conn_str_in=-27102,
    conn_str_out=0xbfff95e0 "DSN=CUSTOMER;DBQ=.;HOST=192.168.1.102;UID=tsi;SERVER=NotTheServer", conn_str_out_max=1023, ptr_conn_str_out=0xbfff95de,
    driver_completion=0) at SQLDriverConnect.c:1463
#4  0xb6ef1716 in pdo_odbc_handle_factory (dbh=0x84273fc, driver_options=0x0)
    at /home/rberquist/PDO_ODBC-1.0RC2/odbc_driver.c:395
#5  0x080d1182 in zif_PDO_dbh_constructor (ht=1, return_value=0x8435f3c,
    return_value_ptr=0x0, this_ptr=0x84273bc, return_value_used=0)
    at /home/rberquist/php5-200511072130/ext/pdo/pdo_dbh.c:374
#6  0x0826b846 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfff9ed0)
#7  0x0826bd92 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfff9ed0)
    at zend_vm_execute.h:310
#8  0x0826b4f6 in execute (op_array=0x8431304) at zend_vm_execute.h:88
#9  0x08243a0c in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at /home/rberquist/php5-200511072130/Zend/zend.c:1087
#10 0x082025b2 in php_execute_script (primary_file=0xbfffc2f0)
    at /home/rberquist/php5-200511072130/main/main.c:1677
#11 0x082b17c6 in main (argc=2, argv=0xbfffc3d4)
    at /home/rberquist/php5-200511072130/sapi/cli/php_cli.c:1041

Are you absolutely sure this isn't a bug in unixODBC? As the backtrace would suggest it's crashing in there, not in PHP.

Well, using the isql command, the odbc works. With PHP, it does not. This is what has led me to believe that it's not a unixODBC issue. Also, setting up a mysql DSN entry in odbc.ini has proven successful. It connects fine and allows query execution.

I've recently found out that it could possibly be the driver and am currently working with the third party developers at the moment. The driver is /usr/local/lib/libtfodbccl.so, which is referenced in the bt. However, they contend that if it works with isql, then the problem is not with the driver.

If you have any other ideas for troubleshooting and pinpointing the issue, I'd be happy to comply.

Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip

Nope, still segfaults. BT is below.

I've also attempted to switch to iodbc. I reformatted the odbc.ini files. Using iodbctest, I can connect and query fine. However, after a recompile of php and accessed with php cli, the script executes everything up to the odbc_connect statement. It then stops with no further output as if frozen. No errors are generated or segfaults.
If accessed with a browser, the browser simply waits. I have made the phpinfo temporarily available at the following URL.
http://ecom.sbdrepro.com/ASP/phpinfo.php

(gdb) bt
#0  0xb6ec2370 in ?? ()
#1  0xb6f027b1 in ISAMOpen () from /usr/local/lib/libtfodbccl.so
#2  0xb6ef5ace in SQLConnect () from /usr/local/lib/libtfodbccl.so
#3  0xb6f5526e in SQLConnect (connection_handle=0x843a468,
    server_name=0x843047c "CUSTOMER", name_length1=-3,
    user_name=0x843ea44 "tsi", name_length2=-3, authentication=0x843eabc "",
    name_length3=-3) at SQLConnect.c:3819
#4  0xb6fa87dc in odbc_sqlconnect (conn=0xbfff7600, db=0x843047c "CUSTOMER",
    uid=0x843ea44 "tsi", pwd=0x843eabc "", cur_opt=2, persistent=0)
    at /home/rberquist/php5-200511211530/ext/odbc/php_odbc.c:2174
#5  0xb6fa90c4 in odbc_do_connect (ht=3, return_value=0x843eaf4,
    return_value_ptr=0x0, this_ptr=0x0, return_value_used=1, persistent=0)
    at /home/rberquist/php5-200511211530/ext/odbc/php_odbc.c:2373
#6  0xb6fa84d7 in zif_odbc_connect (ht=3, return_value=0x843eaf4,
    return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
    at /home/rberquist/php5-200511211530/ext/odbc/php_odbc.c:2060
#7  0x082751ab in zend_do_fcall_common_helper_SPEC (execute_data=0xbfff7760)
    at zend_vm_execute.h:188
#8  0x08277e74 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0xbfff7760)
    at zend_vm_execute.h:1578
#9  0x08274e5b in execute (op_array=0x843a36c) at zend_vm_execute.h:88
#10 0x0824d2c0 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at /home/rberquist/php5-200511211530/Zend/zend.c:1090
---Type <return> to continue, or q <return> to quit---
#11 0x0820bd51 in php_execute_script (primary_file=0xbfff9b80)
    at /home/rberquist/php5-200511211530/main/main.c:1704
#12 0x082bb12a in main (argc=2, argv=0xbfff9c64)
    at /home/rberquist/php5-200511211530/sapi/cli/php_cli.c:1039

So it doesn't crash, just hangs?

It crashes with unixODBC but hangs with iodbc.

In what will probably make sniper choke on his kossu, I took a look into this.  From what I can tell PHP's still doing the right thing via the odbc_connect call, and the error is in the ISAM driver.  I'd mark this not a PHP bug, but I'll leave that to the more active developers to confirm/deny.

I think we can safely say this is not a PHP bug. I apologize for wasting any time, but you all ahve been great.

I've written a python script using the pyodb.py module. It also segfaults at 
0xb73a97b1 in ISAMOpen () from /usr/local/lib/libtfodbccl.so

The company providing the driver swears the driver is fine because "It works fine on our system!". However, it spits a segfault in unixODBC using any application and hangs in iodbc with any application. But they are still hanging onto the "If isql and iodbctest work fine, then it's not a driver issue" philosophy.

Again, thank you for your time and you may close this bug if/when you deem necessary.

Didn't I suggest earlier that this isn't PHP bug? :)