I wondered why you've chosen the kPrime fields to be text format and start with letters to signify what table they're from.

I'm not necessarily *against* it per se, but I wondered if you're actually using that field format or the actual letters for any scripts or tricky relationship wizardry that I should be aware of.

The reason I ask is that I need to automate the import of data for thousands of customers when I upgrade them from my previous version of Indie Band Manager and all of my previous key fields were numeric only.

As a result I have to make a choice here on whether I modify my customers data as I import it to match your formats, or change the kPrime field formats first instead.

I'm trying to fore-tell any gotchas that may occur on either side and figure out which way is the best way to go. I can already envision a few potential snafus if I try to add the letters "ad" before each address key field for example, or "co" before each contact record. It adds a lot of complexity to my import scripts. But if there's a compelling reason to do so I'm glad to figure it out in advance to give my customers the benefits.

Thanks! -Charlie

Hey Charlie,

So the prefixing isn't used for anything: we don't have any calcs that test to see if an ID begins with a P or a C or anything like that. We included the prefixing because it makes it easy for folks to know if they're using the right IDs when they're debugging. So you don't need to modify your existing data: importing strings that lack the prefix will be fine.

The text vs. number thing is don't to make it easy for any key in the solution to be multi-valued, and so we don't have any number-to-text relationship problems. I'd leave these alone (keep them as text) when importing your numbers into them.

Hope that makes sense.

All good John, thanks.