Index creation fails

[RonP]

In the error log I found the message:

Accountname: guest
Pageadress: lang.js.php?1601738518
ALTER TABLE `membership_userpermissions` ADD UNIQUE INDEX `memberID_tableName` (`memberID`,`tableName`)
Duplicate entry '[email protected]' for key 'memberID_tableName':

The member is a valid member, is not multiple registered.
It seems that every time de App starts the INDEX creation takes place.

This also happened with AppGini version V2414 and still exist wit V2419

What is the problem?
Ron

[RonP]

Hi,
Has someone an idea why this happens?

Ron

[pbottcher]

Hi Ron,

can you check in the database for this memberID. The error states that there seem to be more than one entry.
If that is true, you would need to remove the additional entries.

[RonP]

Hi pbottcher,
Thank you for te reaction,

I've checked end double checked, the member is a single registration.
It is funny that ik "looks like" the he is registered as a Quest.
I don't have any quest registration
Ron

[jsetzer]

If I got it right, it's not about (uniqueness of) members (membership_users-table), but about user-specific permissions (membership_userpermissions-table).

In your favourite SQL editor (like Adminer) you should check for any duplicate entries:

Code: Select all

SELECT `tableName`, `memberID`, count(1) 
FROM `membership_userpermissions` 
GROUP BY `tableName`, `memberID`
HAVING (count(1)>1)

If that query returns any records, those are duplicates. Obviously, that unique constraint cannot be created then.

BTW: did you notice the spelling of memeberId in [email protected]?

I don't know if you are using special user permissions (next to group permissions) at all. Those can be configured in admin area for every user:

chrome_fbZEMIXTeu.png (16.02 KiB) Viewed 11649 times

Just in case you don't need such user-specific permissions, you may consider deleting from that table membership_userpermissions. Afterwards, index-creation should succeed.

[RonP]

Hi,
Hi Jetzer,
Thank you for the clear reply.

I did see the type, but that doesn't matter, I didn't want to see the real address.
I ran your query no duplicate records
I than removed the mentioned registration.... what happened next was: some other record gave de warning.

I think I have to let it rest for now, it is not of any matter however it is a puzzle

[jsetzer]

If...

• ... the SQL error message still occurs (clear error log!)
• ... and there are definitely no duplicates
• ... in exactly this table
• ... of exactly that database

... then I see no reason why that ALTER TABLE statement should fail.

If it was my project, I would manually run the same SQL statement in my SQL-tool to see if the error still occurs and perhaps see some additional debug information.

Furthermore I don't have a clue right now.

[RonP]

Hi jsetzer
As I did all your suggestions..... nothing changed.

I think the best thing to do is to export de table and after that importing it again.
If that still won't work then probably export and later import the other permission tables as well


Ron