Hello

You are absolutely right. This is an error.

Okay, we should fix it in the php script, but how should we handle existing collisions (if we add unique to the DB column)?

Good question. I've no idea at the moment. The problem I see is, that the update script, started by the forum admin/operator, could run into this error but any forum user can use a doublette of an e-mail-address. The update would fail and the cause could only get solved by the doublette-using user. O.k., also the forum admin/operator could solve such problems, but I'm not convinced that it would be a good idea to enforce the forum admin/operator to edit one or more user profiles. Especially when it comes to changing the e-mail-address that is a basic necessity for handling of notifications and user data changes (password, e-mail-address (this is, where it begins to spinning round in circles)).

Additionally, spoken as a user, I wouldn't like it if someone edits my user data profile without prior information and explanatory statement about the action.

On the other hand a forum operator could uncover socket puppets.

By the way. I saw your several commitments to the repo of the last few days. Great work!

Thank you. I'm currently not sure, how we should handle the @-syntax. Any suggestions?

Most (or maybe all) occurences in the code that I remember are mysqli-functions, where the error-message-surpressing @ comes from the times of the old mysql-functions. I don't know if such a contruct is nescessary with the mysqli-functions. I know it was necessary with the old MySQl-function-library.

I think, we cannot avoid searching for every single occurence and check the necessity of surpressing an error message instead of handling the hypothetical error.

Tschö, Auge