Welcome to the LimeSurvey Community Forum

Ask the community, share ideas, and connect with other LimeSurvey users!

Duplicated e-mail-adresses when copying participants from the CPDB to a survey

  • socius
  • socius's Avatar Topic Author
  • Offline
  • Premium Member
  • Premium Member
More
5 years 3 months ago - 5 years 3 months ago #178594 by socius
Hi everybody,

I was looking forward to put the CPDB (central participant db) to work for a project consisting of multiple surveys for a closed group of participants. In this case it would be comfortable to copy the cases from the CPDB to these surveys instead of uploading tokenlists for each survey - and it enables to blacklist etc. from the CPDB for all surveys at once. But I encountered some strange behavior (Remark: I use LS 2.6.7 LTS).

I imported around 30.000 participants into the CPDB. All the e-mail-addresses were unique in the CPDB. But: When I export the participants from the CPDB to a survey some case's e-mail addresses show up several times with different tokens, i.e. the tokens of other participants. In other words: the participant gets duplicated in the token table, but not completely: only the e-mail-address, the token and the rest of the attributes comes from another participant.






[Remark: these two respondents are the first and the second in the CPDB - to me it seems that the first case is by far the most duplicated one - and I only noticed the second after I renamed the first and copied again, s. 2) below.]

[Another Remark: I deleted the token table of the survey and again copied some cases from the CPDB to the token table, leaving out the two below mentioned cases. Result: the first case of the CPDB was copied to the token table without being selected! Ok that's no even stranger...]


I looked up the tables I uploaded to the CPDB several times, I can't find the cause for this. (Remark: The import into the CPDB was not without problems - I tried several times and had to end the import after letting the turning symbol turn for a whole night in the end I cut the 30.000 into 5 smaller chunks - that worked.)

What I asked myself and checked:

1) Are there duplicates in the CDPB? Checked the uniqueness of the duplicated cases with the email-address and the participant_id. Answer: No. The participant_id is unique in both cases.

2) I changed the e-mail address of the duplicated case and imported again from the CPDB. Result: Duplicated Versions also from the renamed version.



3) I did a consistency check of the DB, but that was ok (one orphaned question attribute, but that should not bother here to much - should it?)


I have no idea what to do, delete the CPDB and start from anew? Don't use the CPDB? - did someone encounter something like that before? I did not find it in the forum nor in the bugtracker.

[A last remark: I just tried to reproduce this on another installation (2.6.4 LTS) and I could really reproduce this :-(
In that case the CPDB contains only 100 cases, but the result is the same: after copying from the CPDB the token table of the survey contains the first entry of the CDBP lots of times (13 of 25 entries)... Firstname, Lastname and E-Mail-Address of the other participants are written over - the token is ok...]


Thanks a lot for your time and any hint!
Best, G
Last edit: 5 years 3 months ago by socius. Reason: Added some remarks
The topic has been locked.
  • socius
  • socius's Avatar Topic Author
  • Offline
  • Premium Member
  • Premium Member
More
5 years 3 months ago #179107 by socius
Hi everyone,

seems that this experience I had with the CPDB is not too common - that's good! :-) I had to abandon work with the CPDB and now just upload the table into the single surveys. That's not as comfortable as ist would be with the central data base, but the upload is quick and works.

Downside is, that it's not possible to change the content of the attribute fields (or add attributes and fill these) with a new upload of the table, since there is no "update fields" option as at CPDB Upload (at least in 2.6.4LTS - and to my knowledge) - but in most cases, where you do not have to change the values in this table this does not matter.

All the best,
G
The topic has been locked.

Lime-years ahead

Online-surveys for every purse and purpose