import members unique id from another database

[pete39]

I am new to CiviCRM and experimenting with it.

We have an existing membership database in which members have a unique historical sequential membership number that we wish to import into CiviCRM and continue to use so that new members are allocated the next number, and so on.  I think I understand how to create a new custom field to import and contain those existing membership numbers.  My problem is how to continue with this so that CiviCRM  automatically allocates the next sequential membership id number, separate from the contact id number.  Can anyone please tell me whether there is an easy way of doing this?  The import of data has not yet taken place.

[petednz]

Hi Pete - there are a number of issues here to consider.

CiviCRM obviously has its own 'internal id' (cid) for every contact - and it also has membership ids (mid) for memberships. But since in theory a contact can have multiple memberships they are not 'one to one'.

We have hit issues where clients have wanted to have their old systems 'mid' become their new 'cid'. and from memory we did that with some complex import process.

But an easier way would be simply to ensure your db is empty, and the csv you have is a complete list of all numbers - even it it means making some temporary records to then delete if you existing mids are not continuous.

NOt sure i am explaining this that well. But if you have a csv for example with old mids as below

1 - contact in old system but do not import via csv (since I expect your db will already have at least one default contact)
2 - contact in old system, have as first row in your import (assuming cid=2 does not exist), will therefore become cid in civi
3 - contact in old system
4 - no contact in old system but just import with a random name eg qq1 so you can easily find and delete later
5 - contact
6 - no contact in old system (refer #4)

etc

does that make any sense at all?

Alternatively if you are wanting to maintain these numbers in civi as the mid, not the cid, then import your old data and use an External ID, then import the 'memberships' and match on External ID

THat way the next 'contact' to get a 'membership' will get the next available mid.

hth

[pete39]

Hi Pete
I appreciate your input into this, but am a bit confused.

What I envisage the end result is that:

• we have and continue the new automatic CiviCRM contact id number (cid)
• we have and continue the new automatic CiviCRM membership number (mid)
• we import the old database membership numbers to a new field and continue incrementing the numbers in CiviCRM.  This is not the same id number in the old database that will be used for mapping purposes.

I hope I have explained this a little better.

Pete



mm

[petednz]

I was trying to move you to where you might be able to have the cid and the mid and have one of them replace your old xid just to try and keep things simpler than having multiple such 'unique ids' in existence. Sounds like you need some advice on setting up a special field but i don't recall a simple solution. quick search points to these
http://forum.civicrm.org/index.php?topic=18694.0
http://forum.civicrm.org/index.php?topic=12598.0

[Michael McAndrew]

Hey there,

There is no auto-increment functionality for custom fields in CiviCRM, so this would require some custom coding (I don't think anyone has written an extension to do this yet - at least they haven't released it publicly though you might want to google to make sure).

But I would second what Pete said.  Is there a definite reason that the client wants to continue to use the old membership numbers?  I would import all the old ones until now and then use the new ones in future.  You can keep the old ones in the external ID field so they are easily searchable (if someone gets in contact using the "old membership ID", staff can use quick search in the menu to quickly look them up) but if you can get the client to let go of the requirement to continue with the same set of membership numbers, it will simplify things.

Else Pete's idea of importing them with the old number so that CiviCRM's ID and the old ID match is a clever one - worth investigating. Maybe import a load of dummy contacts with all the IDs from 1 to whatever your IDs go up to, and then do another import, overwriting the info, and then delete all contacts that didn't get overwritten.

Michael

[pete39]

Thanks Petednz and Michael for your input on this.  It is very much appreciated and has given me food for thought.

Pete39