Radicore Forum - RDF feed
type: channel
description: Fast Uncompromising Discussions. FUDforum will get your users talking.
items: v 1.35 - Inconsistent SQL files
items: Re: v 1.35 - Inconsistent SQL files

v 1.35 - Inconsistent SQL files
type: item
description: Hi, After downloading version 1.35, there is a minor annoyance with the MySQL data files for the Menu. The data was exported with the line "USE menu" which forces the data to be imported into the menu table even if that's not what you want. For example: mysql -u root -p radicore_v134_menu < radicore/menu/sql/mysql/menu-scheme.sql Will create the menu into the database 'radicore_v134_menu'. While mysql -u root -p radicore_v134_menu < radicore/menu/sql/mysql/menu-data.sql Will fail or insert data into the wrong table because of the "USE menu" directive in the sql file. This problem does not happen for the other databases workflow, dict, or audit. It's a minor annoyance as you have to edit the file if you are using databases with prefixes. Cheers, Kyle Brost ---- www.softelephant.com
creator: ljkbrost
date: 2008-04-28T16:51:26-00:00

Re: v 1.35 - Inconsistent SQL files
type: item
description: This also happens with the audit-scheme.sql.
creator: ljkbrost
date: 2008-04-28T17:29:39-00:00

Re: v 1.35 - Inconsistent SQL files
type: item
description: This also happens with the mnu-user.sql file.
creator: ljkbrost
date: 2008-04-28T17:39:28-00:00

Re: v 1.35 - Inconsistent SQL files
type: item
description: Instead of creating a new SQL loading bug, I add this information here. After loading all the data and trying to login the process fails because the radius login option is enabled by default. This was a real pain to debug and would be very frustrating for new users.
creator: ljkbrost
date: 2008-04-28T18:05:42-00:00

Re: v 1.35 - Inconsistent SQL files
type: item
description: If I do not specify the database name then someone complains, but if I put it in then someone else complains. Some people execute the script without specifying a particlar database name because they assume that the script will automatically switch to the correct database, and then complain that it doesn't work. As it is not possible to know for certain if you are using a prefix with your database names, so the safest option is to leave out the "USE 'xxx';" statement completely. This will mean that everybody will be responsible for identifying the correct database name before executing each script.
creator: AJM
date: 2008-04-28T19:12:50-00:00

Re: v 1.35 - Inconsistent SQL files
type: item
description: Whoops! I shall fix that in the next release.
creator: AJM
date: 2008-04-28T19:18:47-00:00

Re: v 1.35 - Inconsistent SQL files
type: item
description: It is better to require the user to specify the database as you would be less likely to do harm by the framework guessing the wrong name. I agree with your assessment.
creator: ljkbrost
date: 2008-05-01T05:08:17-00:00