On Thu, 31 Mar 2005 12:13:22 -0500, Chris Shiflett <[EMAIL PROTECTED]> wrote:
> The behavior of the session extension has everything to do with
> internals. I'm not sure why everyone is sending him to php-general. No
> one there is going to be able to change this behavior. They can only
> suggest u
HOWEVER, it is not possible to get a result resource from a failed
pg_query! pg_query() returns FALSE on failure, not a result.
You could call pg_last_error(), or pg_last_notice(). Although the last one
is currently somehow broken: http://bugs.php.net/bug.php?id=32223
Those functions are basicall
The PHP Development Team would like to announce the immediate release of
PHP 4.3.11 and 5.0.4. These are maintenance releases that in addition
to fixing over 70 non-critical bugs, address several security issues.
The addressed security issues include fixes to the exif and fbsql
extensions, as
I have modified the Birdstep section of the config.m4 in the /ext/odbc
directory,
but it does not appear to have any effect. What I am trying to do is call the
AC_DEFINE macro with the define value to be based on the operating system. I am
very new to autoconf, so I based my changes on the AC_FI
> >> "why is it this way" should also be posted to the general
> newsgroup,
> >> it barely has anything to do with internals
> >
> >
> > The behavior of the session extension has everything to do with
> > internals. I'm not sure why everyone is sending him to
> php-general. No
> > one there
Hi Hans,
common case of session use, though. I wonder if this could be a
behavior controlled by a php.ini setting in the future? I guess what I
well there actually is a way to switch off this behaviour. You can
disable any kind of session fixation attack by adding the line
php_admin_flag engi
Hi Chris,
Chris Shiflett wrote:
M. Sokolewicz wrote:
"why is it this way" should also be posted to the general newsgroup, it
barely has anything to do with internals
The behavior of the session extension has everything to do with
internals. I'm not sure why everyone is sending him to php-general.
Hi Zeev,
Zeev Suraski wrote:
At 19:47 29/03/2005, Hans L wrote:
Hi,
This may not be the right place for this question, but what I'm
looking to understand is the reasoning behind what seems to be the
standard session behavior in PHP. And, if it's possible, how to
change this behavior (via INI se
At 19:47 29/03/2005, Hans L wrote:
Hi,
This may not be the right place for this question, but what I'm looking to
understand is the reasoning behind what seems to be the standard session
behavior in PHP. And, if it's possible, how to change this behavior (via
INI settings, etc.).
As I understa
M. Sokolewicz wrote:
"why is it this way" should also be posted to the general newsgroup, it
barely has anything to do with internals
The behavior of the session extension has everything to do with
internals. I'm not sure why everyone is sending him to php-general. No
one there is going to be abl
Hello Thies,
Friday, March 25, 2005, 1:55:30 PM, you wrote:
> hi,
> pdo hat it's own query-parser, named variables are prefixed with a
> colon... so far - so nice...
> i have a function called insert which is called like this:
> $db->insert('some_table', array('name' => $name, 'age' => $age))
> HOWEVER, it is not possible to get a result resource from a failed
> pg_query! pg_query() returns FALSE on failure, not a result.
You could call pg_last_error(), or pg_last_notice(). Although the last one
is currently somehow broken: http://bugs.php.net/bug.php?id=32223
Kouber
--
PHP Interna
Hello everyone,
Reached almost the end of a successful php5 win build.. Getting these
errors though. Any pointers gentlemen?
-- Build started: Project: php5dllts, Configuration: Release_TS
Win32 --
Linking...
phpts.def : error LNK2001: unresolved external symbol
xmlTextWriterEndComment
13 matches
Mail list logo
