Sorry, but the bug system is not the appropriate forum for asking
support questions. Your problem does not imply a bug in PHP itself.
For a list of more appropriate places to ask for help using PHP,
please visit http://www.php.net/support.php

Thank you for your interest in PHP.

I beg to differ.  This is actually a bug.  If you read the bug, it states that I cannot use dba_open().  it intermittently fails.  This is a bug in php, that prevents me from opening a db file.

Please try using this CVS snapshot:

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

I'm unable to reproduce this with PHP 4.3.0-dev.

This seems to happen more frequently depending on the size of the DB, and when multiple calls to dba_open() happen. 
I even have all my dba_* calls wrapped with flock() calls to make sure only 1 script @ a time can access the db.  I also have added a check to see if the DB file exists, to change the mode to 'w' instead of 'c'.  Unfortunatly
trying a dev version of php is not an option, since this is a production environment.

I just did a diff on ext/dba_gdbm.c between php 4.2.2 and php 4.2.3 and php in cvs, and there is no difference.

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

If PHP really is bailing out when dba_open fails, we 
need a backtrace to be able to determine the cause.
However, from what you describe, I don't think that this
crash is actually the cause of your problem - it's a
side-effect...

dba works by passing the calls through to your dbm style
library.  Since the default for gdbm is to open the db in
locking mode (and that's what we're using), it sounds like
this is either an issue with gdbm itself or perhaps even
with your kernel.

It's doesn't say anywhere in the docs for gdbm that
multiple writers will block when accessing the database,
so I would expect to get those intermittent errors you
reported. (not a bug).

So it seems that you need to manually ensure that writers
will block - rather than use flock to protect your db, try
using a semaphore from the sysvsem extension (much more
reliable).

Other things to try are upgrading (or perhaps downgrading)
your gdbm installation and see if that makes a difference.
(See if there are any known issues with gdbm too).

--Wez.

Ok So I modified the dba_gdbm.c's dba_open call to output a little debugging information

        if(dbf) {
                info->dbf = malloc(sizeof(dba_gdbm_data));
                memset(info->dbf, 0, sizeof(dba_gdbm_data));
                ((dba_gdbm_data *) info->dbf)->dbf = dbf;
                php_error(E_WARNING, "gdbm_open worked, %s\n", gdbm_strerror(gdbm_errno));
                return SUCCESS;
        } else {
                php_error(E_WARNING, "gdbm_open failed %s\n", gdbm_strerror(gdbm_errno));
                return FAILURE;
        }


The error I am always getting is
PHP Warning:  gdbm_open failed Can't be writer
from the gdbm_open call.

There can only be one writer at the time. This really isn't bug in PHP..just do what Wez proposed. (use the semaphores)

If its not a bug in php, someone should not this anomaly in the php docs, so other don't make the same mistake.  There is no info on any of the docs that say you need to "manually" semaphore access to the db file.  
  I guess this means that only 1 script can access the db at 1 time, which means slow.  *sigh* I wish I could use a real DB.

Yes, that's true..reclassified as documentation problem.

Documentation was updated some time ago...