By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,282 Members | 1,617 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,282 IT Pros & Developers. It's quick & easy.

Transaction effect PHP+DB2 v 8.1.12 Linux

P: n/a
If I'm in a transaction started with 'odbc_autocommit($dbConn, FALSE);'
and I UPDATE a row in tablex, then later SELECT FROM tablex, will I see
the updated row or the original row? If it will help with suggestions, I
would prefer to see the updated row.
Oct 2 '06 #1
Share this Question
Share on Google+
6 Replies


P: n/a
Bob Stearns wrote:
If I'm in a transaction started with 'odbc_autocommit($dbConn, FALSE);'
Just a friendly advice: use the DB2 PHP driver and not the ODBC one. The
old ODBC driver has quite a lot of problems.
and I UPDATE a row in tablex, then later SELECT FROM tablex, will I see
the updated row or the original row? If it will help with suggestions, I
would prefer to see the updated row.
Depends:
(1) If the SELECT is in the same transaction as the UPDATE, you will see the
changed row.
(2) If there was a COMMIT after the UPDATE, the SELECT will see the changed
row as well.
(3) If there was no end-of-transaction after the UPDATE, and if you don't
use UNCOMMITTED READ isolation level for the transaction running the
SELECT, then the SELECT won't see the changes.

--
Knut Stolze
DB2 Information Integration Development
IBM Germany
Oct 2 '06 #2

P: n/a
Knut Stolze wrote:
Bob Stearns wrote:

>>If I'm in a transaction started with 'odbc_autocommit($dbConn, FALSE);'


Just a friendly advice: use the DB2 PHP driver and not the ODBC one. The
old ODBC driver has quite a lot of problems.

>>and I UPDATE a row in tablex, then later SELECT FROM tablex, will I see
the updated row or the original row? If it will help with suggestions, I
would prefer to see the updated row.


Depends:
(1) If the SELECT is in the same transaction as the UPDATE, you will see the
changed row.
(2) If there was a COMMIT after the UPDATE, the SELECT will see the changed
row as well.
(3) If there was no end-of-transaction after the UPDATE, and if you don't
use UNCOMMITTED READ isolation level for the transaction running the
SELECT, then the SELECT won't see the changes.
Thank you. I am in case 1, so all is well. For my future information is
the isolation level (case 3) settable in the odbc or db2 environments? How?

Is there a simple 1-1 mapping between the odbc calls and the db2 calls
(the db2 stuff is documented where, please) so that I could use sed on
my source tree to change over? Is the use of odbc in some modules
compatible with using db2 in others or will someone get upset? BTW, I've
had no real show stopper problems with the PHP 4.4 odbc drivers, but PHP
was compiled / installed with the db2 stuff enabled, which, as I
understand it, affects how the odbc calls work.
Oct 2 '06 #3

P: n/a
Bob,

If there is no connection attribute for teh isolation level you can
always execute a SET SQL statement after connecting to set the misc
registers.

Cheers
Serge

--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

IOD Conference
http://www.ibm.com/software/data/ond...ness/conf2006/
Oct 2 '06 #4

P: n/a
Serge Rielau wrote:
Bob,

If there is no connection attribute for teh isolation level you can
always execute a SET SQL statement after connecting to set the misc
registers.

Cheers
Serge
Thanks for the info. Either you are up very early, or on the other side
of the pond. I am up very late, but going to bed.
Oct 2 '06 #5

P: n/a
Bob Stearns wrote:
Knut Stolze wrote:
>Bob Stearns wrote:

>>>If I'm in a transaction started with 'odbc_autocommit($dbConn, FALSE);'


Just a friendly advice: use the DB2 PHP driver and not the ODBC one. The
old ODBC driver has quite a lot of problems.

>>>and I UPDATE a row in tablex, then later SELECT FROM tablex, will I see
the updated row or the original row? If it will help with suggestions, I
would prefer to see the updated row.


Depends:
(1) If the SELECT is in the same transaction as the UPDATE, you will see
the changed row.
(2) If there was a COMMIT after the UPDATE, the SELECT will see the
changed row as well.
(3) If there was no end-of-transaction after the UPDATE, and if you don't
use UNCOMMITTED READ isolation level for the transaction running the
SELECT, then the SELECT won't see the changes.
Thank you. I am in case 1, so all is well. For my future information is
the isolation level (case 3) settable in the odbc or db2 environments?
How?
I believe that DB2-PHP has a function with which you can set the isolation
level. Additionally, PHP uses CLI to communicate with DB2.
The "db2cli.ini" (which is the same as the CLI CFG) allows you to specify
the default isolation level.
Is there a simple 1-1 mapping between the odbc calls and the db2 calls
(the db2 stuff is documented where, please) so that I could use sed on
my source tree to change over?
Yes, there is. Basically, change the "odbc_" prefix to "db2_". Docs can be
found here: http://de.php.net/ibm_db2
Is the use of odbc in some modules
compatible with using db2 in others or will someone get upset?
As long as you don't try to mix and match objects, you shouldn't have a
problem.
BTW, I've
had no real show stopper problems with the PHP 4.4 odbc drivers, but PHP
was compiled / installed with the db2 stuff enabled, which, as I
understand it, affects how the odbc calls work.
I wasn't saying that it does not work at all. But I know that BLOBs/CLOBs
don't work in the regular ODBC driver. You may get results that look good,
but effectively there is no support for these data types. So you can
easily run into trouble (I did) and you will have to dig through the
PHP/ODBC code to figure out what went wrong. Additionally, the DB2-PHP
driver is better performing, fixes a bunch of other problems (that I
haven't hit myself yet with ODBC), and it is actively maintained by IBM.
The same cannot be said about the ODBC stuff. If you can, I'd recommend
that you switch to the newer implementation.

--
Knut Stolze
DB2 Information Integration Development
IBM Germany
Oct 2 '06 #6

P: n/a
Bob Stearns wrote:
Thanks for the info. Either you are up very early, or on the other side
of the pond. I am up very late, but going to bed.
IDUG Vienna

--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

IOD Conference
http://www.ibm.com/software/data/ond...ness/conf2006/
Oct 2 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.