Delete user from database

Using Concrete / Help
1

I used 3 different emails to register test users but now want to delete them so I can use again if required. I’ve already deleted them from the back-end by going into advanced options and searched for inactive users.
I’m now trying to delete those users from the database directly as it won’t let me use the email address again.
Every time I try to delete the entry from the database it throws a warning:

#1451 - Cannot delete or update a parent row: a foreign key constraint fails (xxxxxx.UserAttributeValues, CONSTRAINT FK_4DB68CA6FD71026C FOREIGN KEY (uID) REFERENCES Users (uID) ON DELETE RESTRICT ON UPDATE RESTRICT)

Is it not possible to ever delete an inactive users completely?

Thanks, Dean.

2

I just tried:

Creating a user
Deactivating it
Deleting it
Registering a new user with that same email and username

And it seemed to work fine on a demo site here. Can you post your environment information? Wondering if you have some overrides that might be making things deviate from standard core behavior.

3

Hi Evan, thanks for your reply.
This environment

Concrete Version

Core Version - 9.1.3
Version Installed - 9.1.3
Database Version - 20220908074900

Hostname

cloud808.thundercloud.uk

Environment

production

Database Information

Version: 8.0.36
SQL Mode: NO_ENGINE_SUBSTITUTION

Concrete Packages

Lazy Menu (1.1.4), Manual Nav (2.3.3), Multiple files attribute (1.0.8), Nestable Manual Nav (1.4.1), Simple Nav Menu (1.1.0)

Concrete Overrides

None

Concrete Cache Settings

Block Cache - Off
Overrides Cache - Off
Full Page Caching - Off
Full Page Cache Lifetime - Every 6 hours (default setting).

Server Software

Apache

Server API

litespeed

PHP Version

7.4.33

PHP Extensions

bcmath, bz2, calendar, Core, ctype, curl, date, dba, dom, enchant, exif, fileinfo, filter, ftp, gd, gettext, gmp, hash, iconv, imagick, imap, intl, ionCube Loader, json, ldap, libxml, litespeed, mbstring, mysqli, mysqlnd, odbc, openssl, pcre, PDO, pdo_mysql, PDO_ODBC, pdo_pgsql, pdo_sqlite, pgsql, Phar, posix, pspell, redis, Reflection, session, shmop, SimpleXML, snmp, soap, sockets, sodium, SourceGuardian, SPL, sqlite3, standard, sysvmsg, sysvsem, sysvshm, tidy, tokenizer, xml, xmlreader, xmlrpc, xmlwriter, xsl, Zend OPcache, zip, zlib

PHP Settings

max_execution_time - 90
log_errors_max_len - 1024
max_file_uploads - 20
max_input_nesting_level - 64
max_input_time - 60
max_input_vars - 8000
max_multipart_body_parts - -1
memory_limit - 256M
post_max_size - 192M
upload_max_filesize - 256M
ic24.api.max_timeout - 7
ldap.max_links - Unlimited
mbstring.regex_retry_limit - 1000000
mbstring.regex_stack_limit - 100000
mysqli.max_links - Unlimited
mysqli.max_persistent - Unlimited
odbc.max_links - Unlimited
odbc.max_persistent - Unlimited
pcre.backtrack_limit - 1000000
pcre.recursion_limit - 100000
pgsql.max_links - Unlimited
pgsql.max_persistent - Unlimited
redis.pconnect.connection_limit - 0
session.cache_limiter - no value
session.gc_maxlifetime - 7200
soap.wsdl_cache_limit - 5
unserialize_max_depth - 4096
opcache.max_accelerated_files - 4000
opcache.max_file_size - 0
opcache.max_wasted_percentage - 5

4

Hi Dean,

Thanks for posting that environment info - taking a look through it things look mostly straight forward (no overrides, etc.).

If you can test out upgrading to the latest version of Concrete (9.2.7) sometimes these sorts of issues have been resolved already. I haven’t heard of that issue specifically in the past that I can recall, but it’s always a good thing to do to rule out potential issues that have already been resolved by core updates.

1 Like
5

Hi Evan,
You were spot on!
I updated to the latest core, and now I can use previously deleted email address again to test registration.

Thanks for your help.

1 Like
6

You bet! Glad it all worked out.