Is there a better way to go about this?
We have a ‘main’ document that uses a state and product to lookup a contact person. The lookup form has three fields 1) name, 2) state (up to 50) and 3) product (also up to 50). Let’s keep it simple and say that one person handles one product but in 30 states. This person now appears 30 times in the lookup view.
In reality, many people handle many products and states so the number of entries in the lookup view grows exponentially. This is working for us but it is at times slow and I’m sure the view index will keep expanding also.
Is there a better way to go about this than a @DBLookup? Or could I use a series of lookups and/or views to make it more efficient?
Subject: @Dblookup alternative?
Your view shoudl look like this
Column 1
State+product
Categorised
Column 2
person
Categorised
Column 3
Any old thing - say @created?
Now your lookup is
@dblookup(“”:“nocache”;“”;viewname;state+product;2)
That will gve you a list of all people supportung that product in that state and each person will only appear once
Chris boote
Subject: @Dblookup alternative?
Depending on the nature of your data (quantities and types of lookup) folders per salesperson might work well for organizing information.
If you find that you’ve outgrown the functionality of views and lookups, placing a RDMS on the back end, linked via DECS/LEI, can help greatly with reporting lookups.
I’d suggest a backward step to an architectural evaluation before implementing a methodology that might be replaced as need continue to outpace functionality.
Collin