Prev: Pear::Soap PHP 4 and header madness
Next: Pear install error: Undefined class name 'pear' in c:\PHP\PEAR\go-pear.phpon line 747
From: "Justin Patrin" on 23 Sep 2006 02:53 On 9/22/06, James Stewart <lists(a)jystewart.net> wrote: > On Sep 22, 2006, at 9:10 PM, Ian Warner wrote: > > James Stewart wrote: > >> On Sep 22, 2006, at 7:48 PM, Justin Patrin wrote: > >>> On 9/22/06, James Stewart <lists(a)jystewart.net> wrote: > >> <snip> > >>>> That generates a form with checkboxes for each time slot, and a > >>>> select list of venues for each time slot. When I add a session to a > >>>> new time slot everything works fine, with an entry being created > >>>> for > >>>> the appropriate time slot and location, but when I try to alter a > >>>> location for an already selected time slot the update isn't > >>>> completed > >>>> and DB_DO_FB attempts to insert a new value in the database for > >>>> just > >>>> the location. eg. > >>>> > >>>> > >>>> DataObjects_Conference_session_time_slot: QUERY: INSERT INTO > >>>> conference_session_time_slot (location ) VALUES ( 6 ) > >>>> > >>>> where 6 is the value of the location I want to change to, but I > >>>> expect something like: > >>>> > >>>> UPDATE conference_session_time_slot SET location = 6 WHERE id = X > >>>> > >>>> > >>>> Looking through the code I can't see where DB_DO_FB actually works > >>>> out which updates it's supposed to make for extra fields, so I'm > >>>> not > >>>> sure where to go next. Anyone got any ideas? > >>>> > >>> > >>> Almost certainly you didn't set up your primary key on the > >>> conference_session_time_slot correctly. > >> > >> It's definitely declared as a primary key in the schema and the DO > >> seems to have picked it up. Is there somewhere else I should be > >> declaring it? > >> > >> The table definition is (I'm using MySQL): > >> > >> ------ > >> CREATE TABLE `conference_session_time_slot` ( > >> `id` int(11) NOT NULL auto_increment, > >> `session_id` int(11) default NULL, > >> `time_slot` int(11) NOT NULL default '0', > >> `location` int(11) default NULL, > >> PRIMARY KEY (`id`) > >> ) TYPE=MyISAM; > >> ------ > >> > >> The do's .ini file holds: > >> > >> ------ > >> [conference_session_time_slot] > >> id = 129 > >> session_id = 129 > >> time_slot = 129 > >> location = 1 > >> ------ > > Should also be underneath this : > > > > [conference_session_time_slot__keys] > > id = N > > > > Also check for spelling mistakes in keys and fields if hand done - > > this has got me a a few times. > > It was auto-generated, and the keys entry is as shown. > Well, line 3006 of FormBuilder.php calls processForm on a sub-FB instance for the crossLink-ed record so the normal FB algorithm is used for insert vs. update. Try creating a DO manually for a record in that table then calling $pk = DB_DataObject_FormBuilder::_getPrimaryKey($do) and seeing what's in $pk. If this shows the expected output ("id") then try manually creating an FB and setting it up to edit the record (note: pearified/DB_DataObject_FormBuilder_Frontend can be used to browse/edit all data in any DOs :-). -- Justin Patrin
From: James Stewart on 23 Sep 2006 10:24 On Sep 23, 2006, at 2:53 AM, Justin Patrin wrote: > On 9/22/06, James Stewart <lists(a)jystewart.net> wrote: >> It was auto-generated, and the keys entry is as shown. > > Well, line 3006 of FormBuilder.php calls processForm on a sub-FB > instance for the crossLink-ed record so the normal FB algorithm is > used for insert vs. update. > > Try creating a DO manually for a record in that table then calling $pk > = DB_DataObject_FormBuilder::_getPrimaryKey($do) and seeing what's in > $pk. If this shows the expected output ("id") then try manually > creating an FB and setting it up to edit the record (note: > pearified/DB_DataObject_FormBuilder_Frontend can be used to > browse/edit all data in any DOs :-). Creating a DO for just the conference_session_time_slot table and then calling print DB_DataObject_FormBuilder::_getPrimaryKey($do); returns 'id' as expected, and generating and using a form for just that table works too. It seems to be just when it's used as a crossLink/extraField that I run into problems. James.
From: "Justin Patrin" on 23 Sep 2006 20:00
On 9/23/06, James Stewart <lists(a)jystewart.net> wrote: > On Sep 23, 2006, at 2:53 AM, Justin Patrin wrote: > > On 9/22/06, James Stewart <lists(a)jystewart.net> wrote: > >> It was auto-generated, and the keys entry is as shown. > > > > Well, line 3006 of FormBuilder.php calls processForm on a sub-FB > > instance for the crossLink-ed record so the normal FB algorithm is > > used for insert vs. update. > > > > Try creating a DO manually for a record in that table then calling $pk > > = DB_DataObject_FormBuilder::_getPrimaryKey($do) and seeing what's in > > $pk. If this shows the expected output ("id") then try manually > > creating an FB and setting it up to edit the record (note: > > pearified/DB_DataObject_FormBuilder_Frontend can be used to > > browse/edit all data in any DOs :-). > > Creating a DO for just the conference_session_time_slot table and > then calling > > print DB_DataObject_FormBuilder::_getPrimaryKey($do); > > returns 'id' as expected, and generating and using a form for just > that table works too. It seems to be just when it's used as a > crossLink/extraField that I run into problems. > Sorry, I'm not sure what it could be. Are you using the newest version of FormBuilder? If you are, I suggest going into the FormBuilder code and trying to figure out what happens. Try looking around line 2824 of FormBuilder.php and see what is in $this->_do, what $this->_queryType is set to, and what $action gets set to. -- Justin Patrin |