Description: ------------ Hey, i'm sorry i don't have a lot of time to describe in detail what's wrong... Just in a few words: As far as I know, in the form procession, formbuilder decides whether to use an insert or update statement by determining if the primary key is set or not. In my application i just run over this problem: when editing a record with primary key set to 0, there happens an insert into the database, although it should actually be an update. Hope that helps... Christof

Hmmmm, sure enough this happens because we're checking to see if the primary key is empty or null. Normal sequences and auto_increment PKs start at 1. I'd suggest for now making your PK not allowed to be anything which empty() returns as true. Markus: Why exactly are we using empty() here? Perhaps we should change this if to this instead: if (!isset($this->_do->$pk) || strlen($this->_do->$pk) == 0) { I've never found empty() to be all that useful...it's basically the same as if (!$var).

Markus? AFAIK this is a negligible BC break and shouldn't break anything.

empty($var) and if (!$var) definitely are *not* the same, as empty also checks for the existence of a variable or array key prior to evaluating it, thus avoiding warnings thrown by PHP if it hasn't been defined yet. On the other hand, I never encountered primary keys starting at 0, so the problem never occured to me. I guess it's safe to switch to the proposed combination of isset() and strlen().

This bug has been fixed in CVS. In case this was a documentation problem, the fix will show up at the end of next Sunday (CET) on pear.php.net. In case this was a pear.php.net website problem, the change will show up on the website in short time. Thank you for the report, and for helping us make PEAR better. I've switched to isset() and strlen() the various pieces of code which were using empty(), including the one that sets the insert.