We recently started utilizing the TNEW Guest Checkout feature on our site. As warned in the documentation, whenever a patron drops out of the check out process without ultimately purchasing a ticket a dummy TNEW Guest Checkout account is created. The documentation suggests merging all of these dups together, which we can certainly do, but I was wondering if anyone else has a different process that they have implemented and find to be more effective than scheduling the merge,
IIRC there is a setting available for you to decide whether these guest accounts should be created as members of a single household, or as individual records.
Merging these records is pointless in my opinion -- the merge process only moves data from one constituent to another -- it doesn't actually delete anything, just inactivates the "delete" constituent. What I do is have a step in my nightly database maintenance script that just inactivates all the guest checkout records outright. Here's the script:
DECLARE @inactive_reason int;
SELECT @inactive_reason = id
FROM TR_INACTIVE_REASON
WHERE [description] = 'Abandoned Guest Checkout'
UPDATE T_CUSTOMER
SET inactive = 2,
inactive_reason = @inactive_reason
WHERE lname = 'TNEW Guest Checkout'
AND inactive = 1
AND last_activity_dt < DATEADD(hh, -1, GETDATE())
Unknown said: We recently started utilizing the TNEW Guest Checkout feature on our site. As warned in the documentation, whenever a patron drops out of the check out process without ultimately purchasing a ticket a dummy TNEW Guest Checkout account is created. The documentation suggests merging all of these dups together, which we can certainly do, but I was wondering if anyone else has a different process that they have implemented and find to be more effective than scheduling the merge,
I would advise against this. There's a possibility you could merge two active sessions together. TNEW's session sharing allows a site to overwrite the TTL/expires of the sessions which could result in a user gaining access to another user's account information/account (while this would require external changes, it is possible, and within reason, that someone would want to extend user sessions into the future OR that existing session sharing code extends the sessions for some unknown or ill-conceived reason)
As Nick mentioned merging the account doesn't free up much in the database; You can deactivate the accounts just as easily.
Is this still considered best practice? Looking to clean up our database.