Accounts and contacts ID's

[skeeby]

I think i did a mistake somewhere while importing over 4000 accounts and 2500 contacts into sugar the other day...
While mapping the fields, i mapped the original IDs of the alien software with sugar's IDs, and now i have a lot of accounts having ID's like "4985" instead of the usual "e45t-wer8-sfd8-778f"...

Is there a way to correct this, for example by reexporting all accounts and contacts out, and reimporting them without mapping the ID field (Will then sugar attribute own IDs ?), or wil this destroy all parent / child relationships between accounts and contacts ?

Thoughts highly appreciated here...

[Superman]

You dont need to correct this, since imported IDs are good as well.

note: of course, it would be better if all those 6, 500 imported records would have unique IDs only. If so, then throughout all sugar tables these IDs would be unique as well.

[Superman]

For instance, look at Users extracted from Sugar Sample Data Dump (test installation).
Here is what IDs it give:
userid / username
1 / admin
chris_id / chris
will_id / will

[skeeby]

Hi Farkhad,

My thoughts on this matter are rather related to the use of Zuckerreports and IReport software, which needs for the mapping of parameters such as ACCOUNT_ID always the same ID types, which is not the case In my database, because i have now as well "4985" IDs as well as "xxxx-xxxx-xxxx-xxxx" IDs...

Do you think the use of IReport is still possible with those 2 different ID types ?

Cheers

[Markku]

Hi, I don't think Zucker or iReport are sensitive to the length or format of the ID's as long they are unique (like they are in this case) and the data type stays unchanged (varchar that is). If you change ID type from varchar to another data type, it is probably different story.

"4985" and "xxxx-xxxx-xxxx-xxxx" look very different but both as saved as text and if they are unique, Sugar will not complain.

[Superman]

......+1

[skeeby]

Thx to you both