|
conradveen01
|
March 29, 2016 at 12:34 pm
We recently had to rebuild our database and reinstall our website.
We reloaded all of the wp_esp_* tables after everything was installed and everything seemed perfect.
However, new registrations are overwriting previously existing registrations.
Can someone help us identify if there is the equivalent of a sequence number somewhere that needs incremented to prevent the collisions between existing and new registrations?
Thanks!!!
|
|
Lorenzo Orlando Caum
|
March 29, 2016 at 1:20 pm
Hi Conrad,
Could you tell us more about how the database was rebuilt?
For example, did you restore a backup of the database using a tool like Duplicator?
—
Lorenzo
|
|
conradveen01
|
March 29, 2016 at 1:35 pm
We had a full WP database backup using the BackUpWordPress plugin as a single SQL file.
We reinstalled WordPress from scratch, reinstalled all plugins including EE 4.8.38.p
We made a copy of the SQL file and edited it removing all objects and data for tables that did not have the wp_es_* name format.
We used the mysql command line to read in and process the SQL file.
All tables included a DROP and CREATE in the SQL like this:
DROP TABLE IF EXISTS wp_esp_answer;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE wp_esp_answer (
ANS_ID int(10) unsigned NOT NULL AUTO_INCREMENT,
REG_ID int(10) unsigned NOT NULL,
QST_ID int(10) unsigned NOT NULL,
ANS_value text NOT NULL,
PRIMARY KEY (ANS_ID),
KEY REG_ID (REG_ID),
KEY QST_ID (QST_ID)
) ENGINE=InnoDB AUTO_INCREMENT=571 DEFAULT CHARSET=utf8;
/*!40101 SET character_set_client = @saved_cs_client */;
|
|
conradveen01
|
March 29, 2016 at 1:37 pm
Reposting the SQL DDL using code block:
DROP TABLE IF EXISTSwp_esp_answer`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE wp_esp_answer (
ANS_ID int(10) unsigned NOT NULL AUTO_INCREMENT,
REG_ID int(10) unsigned NOT NULL,
QST_ID int(10) unsigned NOT NULL,
ANS_value text NOT NULL,
PRIMARY KEY (ANS_ID),
KEY REG_ID (REG_ID),
KEY QST_ID (QST_ID)
) ENGINE=InnoDB AUTO_INCREMENT=571 DEFAULT CHARSET=utf8;
/*!40101 SET character_set_client = @saved_cs_client */;
`
|
|
Lorenzo Orlando Caum
|
March 29, 2016 at 1:49 pm
Hello, I’ll double-check with a developer but it looks like you may have dropped a custom table for Event Espresso 4 and then created a new one.
Could you confirm that you were not trying to merge data from one site to another? That won’t work since information is stored in native WP tables and support information in custom Event Espresso tables.
—
Lorenzo
|
|
conradveen01
|
March 29, 2016 at 2:46 pm
We were restoring data from the original site back to a newly restored installation of the same website.
|
|
conradveen01
|
March 29, 2016 at 2:49 pm
One possibility is there may have been a stored value in another WP table that we did not restore relative to the EE installation but we don’t have the insight to know where or what that might have been.
|
|
Josh
|
March 29, 2016 at 3:49 pm
You are correct, Event Espresso also uses the _posts table to store registration information, specifically for attendees because Event Espresso Attendees are a custom post type.
|
|
conradveen01
|
March 30, 2016 at 11:11 am
Thanks for the input. We were able to identify that we are missing four previous registrations, have one conflicting (two different registrant names with the same ID) and two new.
This was a huge relief to be able to identify the impact, we can manage those manually.
|
|
Josh
|
March 30, 2016 at 12:47 pm
You’re welcome.
|
