Radicore Forum
Fast Uncompromising Discussions. FUDforum will get your users talking.

Home » RADICORE development » Bug Reports » multi2
multi2 [message #752] Mon, 09 April 2007 16:36 Go to next message
interop is currently offline  interop
Messages: 45
Registered: October 2006
Member
I've created a multi2 task and it is failing in updateRecord() at line 3176 because _dml_ReadBeforeUpdate() is passed the updated where clause not the original where clause.

e.g. I have an employee with a number of phones in a table emp_phone. I want to change the number for a phone from 555-1234 to 555-5678 and the _dml_ReadBeforeUpdate() is passed $where='employee_id='10' AND phone_number='555-5678' and returns the error Could not locate original EMP_PHONE record for updating (employee_id='10' AND phone_number='555-5678')

edit: radicore 1.23.0

[Updated on: Mon, 09 April 2007 16:36]

Report message to a moderator

Re: multi2 [message #754 is a reply to message #752] Mon, 09 April 2007 17:50 Go to previous messageGo to next message
AJM is currently offline  AJM
Messages: 2368
Registered: April 2006
Location: Surrey, UK
Senior Member
When _dml_ReadBeforeUpdate() is called in the updateRecord() method the $where string is constructed using ONLY the primary key of the current record, and the radicore framework does not allow the updating of primary keys in its default behaviour. If you wish to update a primary key then you can only do so with custom code, in which case you should use the updateSelection() method.

There is a function built into the framework which updates primary keys - take a look at the Task Rename function.


Re: multi2 [message #762 is a reply to message #754] Tue, 10 April 2007 10:27 Go to previous messageGo to next message
interop is currently offline  interop
Messages: 45
Registered: October 2006
Member
Ok, I've added a separate primary key to the child table (emp_phone) and all is working fine. Is this an appropriate solution?

Thanks
Re: multi2 [message #763 is a reply to message #762] Tue, 10 April 2007 10:37 Go to previous messageGo to next message
AJM is currently offline  AJM
Messages: 2368
Registered: April 2006
Location: Surrey, UK
Senior Member
I assume you mean a candidate or unique key as a database table can have only one primary key.

If your design says that a single phone number can only be used by a single employee, then specifying this is a candidate key would work. Because it is separate from the primary key the framework will allow it to be updated at any time, and will automatically check any new value for uniqueness.


Re: multi2 [message #764 is a reply to message #763] Wed, 11 April 2007 11:04 Go to previous messageGo to next message
interop is currently offline  interop
Messages: 45
Registered: October 2006
Member
In my original design emp_phone did not have a primary key. My design was Employee(one) --> emp_phone(many). Employees could have more than one phone (cell, home, work,...). What I did was add a new column "emp_phone_id" to emp_phone (an auto_increment, primary key) and that seemed to fix my problem.

[Updated on: Wed, 11 April 2007 11:05]

Report message to a moderator

Re: multi2 [message #765 is a reply to message #764] Wed, 11 April 2007 11:59 Go to previous message
AJM is currently offline  AJM
Messages: 2368
Registered: April 2006
Location: Surrey, UK
Senior Member
Every table in a relational database is supposed to have a primary key. EMP_PHONE should therefore have a primary key of EMPLOYEE_ID + PHONE_ID which will prevent the same PHONE_ID from being added to the same EMPLOYEE_ID more than once. This will also allow an EMPLOYEE_ID to have more than one PHONE_ID, and allow a PHONE_ID to be shared by more than one EMPLOYEE_ID.

When you want to change an employee's phone number using this design what you have to do is DELETE the old one before INSERTING the new one. Some DBMS engines do not allow primary keys to be updated (which is why technical primary keys were invented in the first place), so this is the way to do it. The Radicore framework follows this traditional convention by not allowing any part of a primary key to be updated in its default processing. However, it is possible to update a primary key with custom code as I mentioned in a previous post.


Previous Topic: std.datevalidation.class.inc
Next Topic: Fatal Error: MySQL error: 1271
Goto Forum:
  


Current Time: Sun Nov 24 18:31:11 EST 2024

Total time taken to generate the page: 0.01392 seconds