Correct me if I am wrong as I do not know how to check, but it looks like Demand Contract Entry is using the 3rd index below. I would like to be using the PK index. Is this even possible?
I’m intrigued, but I think it’s because I really don’t understand the question 
LOL. So, if you look at Demand Contract Entry screen, the DemandContractNum is not shown anywhere. It is like CustNum and VendorNum, hidden in the background. Instead, it appears that the entry screen is using the last index as the DemandContract field and CustNum are the required fields. I don’t understand why they decided to hide the DemandContractNum field as it would just be like having any other transactional number (e.g. Sales Order, PO, Invoice, etc.). Because of this, I wanted to see if I could somehow change the index that they are using.
Does that help?
Hey @jkane
So the index that something uses is how something is looked up in SQL. If you think of dictionary, you have all of the words in alpha order. You have one index. If you think of a Spanish to English dictionary, you’ve add a cross reference to the other language, but you also have 2 halves. One of them is the English word in alpha order, with the related Spanish word, and the second half is essentially a duplicate of the information, but is ordered by the Spanish words in alpha order, so you can see what the English word is. It’s simply another way to look up the related information. That’s what a second index does. The information needs to be present no matter which “Index” you use. It’s just different ways to look up the same information.
To prove that, if you go into the customization and look at the object explorer you will find the DemandContractNum in the view. So even if this isn’t shown on the screen, it’s still present in the dataview. If you really want to check, run the screen in debug mode and you can see the dataset populated.
Other screens that do the same thing are Customer, and related screens. The underlying link is almost always CustNum, which is the immutable key. The CustomerID is what’s shown, which is a changeable reference. So even though it’s not shown, CustNum is the data that’s being used to relate records most of the time.
So to reiterate, the indexes are copies of the data in different orders to be able to find the related data faster. The indexes that are used for the lookup is determined by SQL at the time of the lookup.
Does that help clear things up?
Also, what problem are you trying to solve?
1 Like
Yes! I had a general knowledge of indexes, but the way you explain it is very clear. I was hoping that Epicor was somehow using them for a quick hack to do what I wanted. I will have to build out the functionality I want the long way.
Basically to have a unique ID that is not entered by a human. The thought trail in my mind was that the index was somehow being used to control the behavior of the screen (mandatory fields, searches) and if I could change it, I would not have to build all new searches and such. Basically making the Demand Contract Entry work just like Order Entry.
1 Like
I was originally thinking that, but when I found the Num field I thought that was better than auto numbering that one. How would you do it? Expose the Num field or hi-jack that one.
Remember though, you are on the left and I am on the right!
I would autonumber the visible field. There is less to change in the system to make that work. There are lots of threads out there to “Autonumber” stuff. (part numbers, customer ID’s etc) and it’s going to basically be the same thing. Peruse through this thread and see if you can find something that will work.
Also… I learned a trick back in my high/school college days about looking smart for the teacher. As soon as you know an answer to any question they ask, immediately answer. Then when it gets to the stuff you don’t know, they won’t call on you because you’ve answered a bunch of questions already I do the same thing here. lol.
2 Likes
Just a quick note on that. I know this probably isn’t one of those situations,
but if you’re doing high volume data and/or multiple users, it’s a good idea
to do the autonumber on save/update to reduce the chance of a conflict.
@Banderson , I split the difference and instead of auto-numbering the field, I set up BPMs to copy the DemandContractNum field to DemandContract.
But thinking it through now, I see why you suggested using the visible field. Thanks for your help.
2 Likes
I like it! That’s a nice solution. I didn’t think of that.