0004687: After update Openbravo to a version higher than 2.35mp5 the languages are deleted

Issue History
Date Modified	Username	Field	Change
2008-08-22 18:15	networkb	New Issue
2008-08-22 18:15	networkb	Assigned To	=> cromero
2008-08-22 18:15	networkb	sf_bug_id	0 => 2067778
2008-08-22 18:15	networkb	OBNetwork customer	=> Yes
2008-08-22 18:15	networkb	Regression testing	=> No
2008-08-22 18:45	psarobe	Project	Openbravo ERP => @4@
2008-08-25 12:31	pjuvara	Assigned To	cromero => marvintm
2008-08-29 09:42	pjuvara	Priority	high => immediate
2008-08-29 09:42	pjuvara	Severity	major => critical
2008-08-29 09:42	pjuvara	Status	new => acknowledged
2008-08-29 09:42	pjuvara	version	2.35MP7 =>
2008-09-16 09:05	marvintm	Status	acknowledged => scheduled
2008-09-16 09:05	marvintm	fix_in_branch	=> trunk
2008-09-16 09:08	marvintm	Status	scheduled => resolved
2008-09-16 09:08	marvintm	Resolution	open => fixed
2008-09-16 09:08	marvintm	Note Added: 0009025
2008-09-24 18:42	cromero	Relationship added	related to 0005246
2008-11-25 23:02	psarobe	Status	resolved => closed
2008-12-18 12:38	jpabloae	Sticky Issue	No => Yes
2008-12-18 12:39	jpabloae	Sticky Issue	Yes => No
2008-12-18 12:39	jpabloae	Tag Attached: dbsm_migrate
2008-12-18 12:41	jpabloae	Project	@4@ => Openbravo ERP
2008-12-18 12:42	jpabloae	Category	F. Localization => Y. DBSourceManager

Notes
(0009025) marvintm (viewer) 2008-09-16 09:08	This should have never happened in the first place (the cause of this was a modification in the filters done after exporting the database, something that should never be done). Now the update mechanism will not, in any case, delete the translations, except in the case that a translation doesn't correspond to an entry in the database (i.e., the entry has been deleted in the new version). Still, foreign keys have to be changed to "ON DELETE CASCADE" in the Openbravo ERP for this mechanism to work. If they are not changed, the update might fail, as constraints could not be activated. However, even in that case, the translations wouldn't be deleted.