Showing results for 
Search instead for 
Do you mean 
Community Home Request Access Read Blogs Share Your Ideas Search Community View My Settings
Silver Contributor
Posts: 835
Registered: ‎03-24-2009

7.5.3, 7.2.2 Opp Contact ID Prefix, New JoinData ID Prefix: WRONG

[ Edited ]

Add a Contact to an Opportunity. I'm getting 'J' as a Prefix for the OppcontactID for a new Opp Contact. Opportunity Contact table now has Q and J prefixed OppcontactIDs.


 Add a Join (Tools Manage Joins). I'm getting a 'Q' as a Prefix for a new join. Joins now have JSYST, jprefix, Jprefix, and Qprefix recordIDs.


the Key Desc that is generated when a new Site Key record is inserted is simply a letter.....used to be a description....Activity, not A.....History, not H....etc.


Hasn't caused any issues that I'm aware of, and am registering this with SLX Tech Support as I'm typing this.


Conistency is usually good to have.....

RJ Samp
Gold Super Contributor
Posts: 3,087
Registered: ‎03-19-2009

Re: 7.5.3, 7.2.2 Opp Contact ID Prefix, New JoinData ID Prefix: WRONG

If you are getting "Q's" then that is the default prefix when the call is made to get an ID for a particular table.


One thing I discovered a while ago was that there are certain tables (about 8 of them) that you should not pass the tablename but rather a different name. In these 8 cases  if you pass the tablename you will get back a "Q" prefix. For example, in the case of the "JOINDATA" table you should be passing "JOIN" as the name.


Not having access to any original design specs on the use of prefix in a key for a (particular table) I can only speculate that the original purpose was to make it easy (ex: strPrefix = Left(ID,1)) to tell what the table was for by just looking at the prefix. Certainly there is code (since day zero and still in use today) the depends on an Account record starting with a capitol "A", Contact w/a capitol "C", "O" for Opportunity,  and address w/ a small "a" (as well as other tables w/their prefix's).


Another was the business of running out of keys, I know we had a discussion several years ago in the Partner NewsGroup about the possibility of running out of unique keys because of the excessive use of the "Q" prefix. At that time (and still now) I thought it would really be great if we could specify (in RESYNCTABLEDEFS) our own prefix for custom tables (we can specify the KeyField ;-)

RJ Ledger - +1 603.369.3047 x101

".. Innovators in Mobility - Experts in Workflow Automation..." - blog: