Hi,
Andrey Hristov wrote:
> echo get_class($this).'::'.__FUNCTION__ (when there is an instance of the
> class) but AFAIK in your case with static calls there is no solution.
Is there some way to add a function (or some other magic thing) that works
with static calls and call it a bug fix, so it c
works.
At 22:28 21.05.2004, Timm Friebe wrote:
On Fri, 2004-05-21 at 21:59, Timm Friebe wrote:
> On Fri, 2004-05-21 at 21:19, Daniel Convissor wrote:
[...]
> > It would be appreciated if we can get Sybase working. Right now it
causes
> > PHP to crash. http://bugs.php.net/bug.php?id=28354
>
> I'm
The following code triggers a segfault with the attached stacktrace:
print ReflectionClass::export('UML_Class');
?>
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
php5t
On Sat, 2004-05-22 at 13:48, Sebastian Bergmann wrote:
> The following code triggers a segfault with the attached stacktrace:
>
>class UML_Class extends ReflectionClass {
>}
>
>print ReflectionClass::export('UML_Class');
>?>
Works fine here.
- Timm
--
PHP Internals - PHP
Basically i am interested in maintaining documentation and in maintaining php.net
site.I am working on PHP from past 2 years as a Server Side Programming Language.I
have good skills of web programming in other languages too.I am also interested in
development of PHP runtime(especially for window
Hey Ard,
When you say database, do you mean separate database connection, or separate
named databases on the same connection?
PDO::beginTransaction() initiates a transaction for a given connection ($dbh)
in a more or less portable way. You're not always guaranteed to be able to do
that; extending
Guys,
I saw the alpha of PDO on pecl. I was wondering if we could discuss the
design of it a bit more before putting too much work into it.
In particular, the way transactions are represented is not very
practical. Generally, databases that support transactions will support
multiple concurrent
On May 22, 2004, at 11:50 AM, Wez Furlong wrote:
Hey Ard,
When you say database, do you mean separate database connection, or
separate
named databases on the same connection?
PDO::beginTransaction() initiates a transaction for a given connection
($dbh)
in a more or less portable way. You're not
Wez Furlong wrote:
When you say database, do you mean separate database connection, or separate
named databases on the same connection?
Well, first of all, Firebird does not distinguish between databases and
database connections. So connecting to several databases on the same
host is basically th
foo!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> Yeah I know, but the current code doesn't even allow multiple
> transactions against a single database on the same
> connection, does it ?
> Adding PDO_Transaction::start($db1[, $db2 ...]) for multiple
> databases
> would be nice too, but it's not as important. It's just that I think
> thi
Wez Furlong wrote:
PDO tries (a bit) to keep things portable: if it's a method of the PDO or
PDOStatement classes, then you can be reasonably sure it's supported for a
given driver. That doesn't mean that I want to exclude all non-portable
behaviour, I just want to make sure that we don't overload
debug_backtrace();
Not the prettiest solution, but a reliable one nonetheless.
-Sara
"Johannes Schlueter" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi,
>
> Andrey Hristov wrote:
> > echo get_class($this).'::'.__FUNCTION__ (when there is an instance of
the
> > class) but AFAIK
Hi,
Not really, too.
Array
(
[0] => Array
(
[file] => -
[line] => 8
[function] => foo
[class] => a
[type] => ::
[args] => Array
(
)
)
)
Array
(
[0] => Array
(
Currently, re-assignment of $this is handled in compile time but that won't
stop anyone from creating a referenc of $this and changing its value. Of
course, any indirect changes to $this won't permanently change the object in
the way that changing $this in PHP4 would have since the value of this i
> Currently, PHP/Interbase uses one implicit transaction for the entire
> request. I think that, by the nature of PHP, if transactions can be
> supported, they should span all the statements executed during a
> request. [which should still be committed if something goes
> wrong, but
> would
Ard Biesheuvel wrote:
Wez Furlong wrote:
You might turn commit() into a NOP and raise the error on rollback()
only, as it's the responsibility of the user to choose a DB that fits
his needs. This would enhance portability IMO
Doesnt sound like a good idea to me. Since the default is auto commit
We are conducting a standard process investigation on
behalf of Diamond Bank PLC. This investigation
involves a client who shares the same surname with you
and also the circumstances surrounding investments
made by this client at Diamond Bank Republic, the
Private Banking arm of Diamond Bank PLC.
Just a thought - feel free to ignore...
In dataobjects rather than implement extra methods for transactions, I
just hooked into query
..
eg. $do->query('BEGIN') - turned off autocommit, and ran begin.
$do->query('ROLLBACK') or $do->('COMMIT'); - ranit , then turned
autocommit back on
It seemed f
On May 22, 2004, at 9:12 PM, Alan Knowles wrote:
Just a thought - feel free to ignore...
In dataobjects rather than implement extra methods for transactions, I
just hooked into query
..
eg. $do->query('BEGIN') - turned off autocommit, and ran begin.
$do->query('ROLLBACK') or $do->('COMMIT'); - ran
George Schlossnagle wrote:
On May 22, 2004, at 9:12 PM, Alan Knowles wrote:
Just a thought - feel free to ignore...
In dataobjects rather than implement extra methods for transactions,
I just hooked into query
..
eg. $do->query('BEGIN') - turned off autocommit, and ran begin.
$do->query('ROLLBACK'
21 matches
Mail list logo
