[PHP-DB] Re: [PHP-DEV] RFC: ODBC and PHP
Dan Kalowsky wrote: On Tue, 10 Sep 2002, Shane Caraveo wrote: Hmm, is there no way to make the functions work with both odbc versions? Have an odbc_set_version(int) function that can set the version of odbc to use. The default can be version 3. This way, with the addition of a single function call, scripts can provide BC. This is a tricky question really. Theoretically, yes it should be possible to allow this. You may run into issues with some of the result sets, but the connections should still be the same. You couldn't really do it with a function like odbc_set_version, as my understanding of ODBC states you must declare which version type you are using at compile time. If you have some documentation stating otherwise, I'd be interested in reading it. It depends on if a driver manager is involved, if it is, you can select the behavour you want before allocating the connect handle. But I wouldn't expect that many of the changes would be that important, IF you use a driver manager, if not, then you have to choose which set of ODBC API's you are compiling to. The reality is, I don't know. All ODBC3 drivers should be able to utilize the deprecated functionality just fine, but the mapping is an unknown and dependent upon vendor implementation. Going the other way, of course, is not going to work. Not allways the case, again if a DM is there then yes agreed, but without the DM, there are ODBC 3 drivers that don't implement the older API, they assume that the DM will tidy this up for them. But I don't see a reason to keep such BC at this point. The problem with the current system can be seen with bugs in the result sets. The one area specifically mentioned above. Users are still going to ask Why doesn't my select work? while using NTEXT or something non-compliant. The CURSOR type cannot be changed with the current system. This in itself leads to a slower implementation, a (unnecessarily) larger memory footprint, and in DB2 systems a memory leak. Having a real way of changing the cursor type would IMHO fix a lot of the current php_odbc problems. Hey at least I haven't gone as drastic as I originally thought, and asked to drop support specific for things like DB2, Solid, Empress, etc, and only support multi-driver systems (unixODBC, i-ODBC, and Windows ODBC). :) Although I still think that would make the most sense and be the easiest to support on our end of things. Well I am of course biased :-) but I still can't see the real downside of that... Perls DBD:ODBC for example has come to the conclusion that DM's do more good than harm. --- Nick Gorham -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [Fwd: Re: [PHP-DB] how to update a text BLOB in ODBC?]
Jeff Stern wrote: it turns out it is probably a bug -- firebird does not have this behavior, but interbase does. they do not think it is an easysoft issue. they think if we juse use firebird here we will be fine. but we cannot risk switching to firebird, here. my IP dept would never go for it. maybe an upgrade to ib 7 would fix it, i don't know.. i am still looking further into it. anyone have any contacts at interbase? I don't know anything about BLOBs under ODBC, but I could help you with direct Interbase connectivity, which I use extensively (but not for text fields - it makes it difficult and slow to search). Let me know if you need help with direct connection BLOB handling under Interbase. I am using Firebird, not that it should make any difference. Just to sum up the problem, Interbase 6 and 6.5 (not sure about 7, I will check) does not allow you to do a literal insert into a blob, ie insert into blob_table ( blob_column ) values( 'hello' ); The only way it can be done, is via a bound parameter, that allows the ODBC driver, to catch the fact its a blob, and to use the correct methods to create and insert the blob. I only discovered that firebird supported this, when I was about to demonstrate to someone here, how the problem happened, and to my suprise, it didn't. The only other way I could suggest would involve adding support in php_odbc for binding parameters, that wouldn't be that difficult, but as the last few changes I did to php_odbc have either been backed out or altered to fit different drivers, I don't know what the developers want to do. --- Nick Gorham Easysoft Limited -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DB] Re: Problem with dsn
Gian Michele wrote:
I have installed on my computer :
Apache 1.3
Php 4.1.2
Postgresql
the rpm of odbc and the unixODBC.
I tried to connect to my database after done all configurations; I used
the function odbc_pconnect('name_of_my_database','','') and the system
gives me this error
Warning: SQL error: [unixODBC][Driver Manager]Data source name not
found, and no default driver specified, SQL state IM002 in SQLConnect in
/var/www/html/check_avviso2.php on line 5
Does any body knows as set the DSN and the driver?
Have a look in the docs on the unixODBC web site, there are details there.
You need to create a system DSN, and use the name of that DSN in your
connect. Check that you can connect with isql before moving on to PHP.
--
Nick Gorham
Easysoft Limited
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DB] Re: problem with php and unixODBC
Marten Lehmann wrote: Hello, my unixODBC-2.2.2 installation works fine. I tested the configuration with a local and a remote ressource to a Sybase Adaptive Server Anywhere database with isql (a testing tool of unixODBC). Thus the settings in the odbc.ini and odbcinst.ini should be correct. But when I'm using PHP-4.2.1 with unixODBC-support, I can connect to the local ressource only, not to the remote-ressource, although it worked with isql. Do you have any general ideas, why it doesn't work? Are there known issues about the unixODBC-implementation in php? PHP always says unable to connect to server: database not found. But as I told before, the odbc.ini settings are correct. It seems that php tries to connect to a local server although in odbc.ini CommLinks-settings are defined. Does maybe php don't receive the odbc.ini data correct? I thought that it might be a permission problem, but I ran apache 1.3.26 (with php as module) with the same user to whom all the files and databases belong and I got no positive result. Hi, I know its a little late, but I have only just been pointed to your posting, I would guess the error you are getting database not found is coming from the sybase driver, not the driver manager. PHP doesn't get involved with the odbc.ini data, just the driver manager, but the sybase driver also needs to find its ini files, it doesn't get them from the driver manager ini file, but its own. Can you first try using apache in single user mode, ie httpd -X, as the same user that can connect (say using isql) to the sybase driver, if one can connect, but the other not, I would then try strace -o /tmp/stlog httpd -X then try and connect and have a look (send me a copy if you want) of the log, it should show what files and drivers its trying to load. --- Nick Gorham Easysoft. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
