CiviCRM Community Forums (archive)

Hi there,

We've got an interesting issue on our drupal 6 / Civi 3.4.7 setup.

We're seeing custom data and relationships for contact ID's that have yet been created:

Attachment one: Most recent ID is 14330

Attachment two: Relationship data for 14661, 14659 - these user IDs do not exist yet!

Attachment three: Custom field data for User IDs that don't exist yet

Would love to hear any thoughts on what might cause this.

This is causing issues in that new contacts get random profiles assigned to them.

Happy to supply any more info that would help.

Thanks
Neil

It is an unusual problem to have.  It suggests legacy data in the database. 

What is the history to this problem?  Eg. Has it just appeared? Have you personally maintained the CiviCRM installation since its first inception? If not, are you in contact with previous maintainers?  Were there any data imports at the beginning or at any time since? Have all database changes been through the UI or at some stage has someone had direct access to the MySQL database?  etc.

Hi All,

Thanks so much for your time. Here are some answers to questions:

Not sure what your CiviCRM level of expertise

I'd give myself 6/10, I know the fundamentals and very experienced with drupal

Is your custom group set for only Indivduals or for all contacts?

See attachment, most are against certain contact types, but technical interests, which only apply to Indivduals are set to apply to all.

Could you have created a contact without noticing? For example, if you enter an employer in a contact form, the relationship 'Employer/employee' is created automatically, and if the company does not exist a contact will be created for the company.

I don't think we have anything like that happening. Every time a drupal user registers we create a contact, but only saving first name, last name, address and company name (which doesn't create a organisation). Even if this were happening, the most recent contact ID in the contact table and the most recent contact ID in the relationships table would be the same right? You wouldn't have relationship data for contact IDs that "don't exist yet"

What is the history to this problem?  Eg. Has it just appeared? Have you personally maintained the CiviCRM installation since its first inception? If not, are you in contact with previous maintainers?  Were there any data imports at the beginning or at any time since? Have all database changes been through the UI or at some stage has someone had direct access to the MySQL database?

We noticed it around 3 weeks ago, going back comparting drupal users to civi it looks like it has been happening for around 12 weeks. We develop and maintain the site. We did a number of imports in 2011 / 2012 but only started noticing issues now. No one has done any direct DB changes.

What do you see if you look at contact 14661 in CiviCRM?

That contact doesn't exist! The most recent is 14330. That's what makes it so odd!

Thanks everyone for your continued help, would appreciate any more thoughts. Will do a write up of the symptoms, cause and fix once this is resolved.

Weird!! I would imagine you would get all sort of DB errors if the record does not exist in civicrm_contact?

Actually not really, because that contact is never referred to, because it doesn't exist...

What do get though is random profile info and relationships applied to new contacts because they are using IDs which don't exist in the contact table but do exist in the relationship and custom data tables

Yeah, that is true. What CiviCRM version are you on?

3.4.7 + D6

I'm not a developer, so you should wait for a second opinion, but, whether or not I knew where the data had come from, I would make a copy of the rogue entries, delete them from the database and carefully monitor the situation from now on.

That makes sense Joanne. Also, is there any modification or upgrades that have happened in the period when this thing started, either on CiviCRM or on Drupal?

You should make sure your tables are INNODB & the Foreign key constraints exist on the contact id fields

NB - you might modify your original post to say contact_ids instead of user_ids as appropriate as it is a bit confusing