Webgui works for a while and then it starts to complain about duplicate keys. First it did it with documents, now it does it with users.
2007/06/26 13:52:38 - ERROR - doku2010.conf WebGUI::Session::ErrorHandler::error[183] - Couldn't execute operation WebGUI::Operation::User::www_editUserSaveRoot cause:
ModPerl::Util::exit: (120000) exit was called at /data/WebGUI/lib/WebGUI/Session/ErrorHandler.pm line 2312007/06/26 14:00:25 - FATAL - doku2010.conf - main::[[undef]] - Couldn't execute prepared statement: insert into users (userId,dateCreated) values (?,?) : With place holders: TQ7dOsuh3V_tJbbHVbKxCA, 1182855625. Root cause: Duplicate entry '0' for key 12007/06/26 14:00:25 - ERROR - doku2010.conf - main::[[undef]] - Couldn't execute operation : WebGUI::Operation::User::www_editUserSave. Root cause: ModPerl::Util::exit: (120000) exit was called at /data/WebGUI/lib/WebGUI/Session/ErrorHandler.pm line 231
Does the log lie or is there a bug in sql statament generation or somewhere in the database definition? For our database users-table contains two columns defined with constraint PRI (__recordId | varchar(22) | NO | PRI and __revision | int(11) | NO | PRI) and neither of them get any value if the log is to be believed.
Is there anything else I can do than restore everything from backups and wait this to happen again?
[quote]What version of mysql and WebGUI do you have installed? I've got the similar errors with mysql >= 5.0.40. [/quote]
7.3.18 and Mysql -server version: "5.0.32-Debian_3-log Debian etch distribution"
This is probably something that can be done bypriviledged Webgui user. Or two different somethings that user can do. One alters asset-table structure by adding new columns and changing primary key and the other alters users table by adding 10 new columns and changing primary key.
The user-table alteration causes inserts to fail because the new primary key fields are not updated. Same is true for assets table.
Any idea how I could find out what this something is? And how this can be undone?
That something is sql form. All _I_ did was to enable sql-link for webgui database. Test it's function with sql-form on users-table and that was it. Either sql-form is buggy, which I can not say because I have not purchased documentation, or it requires some more preparations to use.
If you just do a form with table name, title and import you break your table. Sql form adds its own 10 columns and changes the primary key of the table. I do not know how to undo these changes from webgui's interface but fortunately I can do it from the database itself.
Summa summarum, I don't know if this actually is a bug or not.
You are not supposed to be able to use SQLForm on the WebGUI database. If you were able to do so, then that is the bug that needs to be fixed.
It was designed that way to prevent exactly this type of problem.
There is no code to prevent users from using the WebGUI database with the SQLForm.
Users who read this: If you do use the WebGUI database, and if you point it at one of the WebGUI tables, you risk nuking your site! Do not do this!
