Hi guys, I must say that I still disagree with the conclusions that are drawn in this topic. When I read this I figured let's test this out and I came up with two conclusions. [list] [*]First, the lookup and the prefilter state reacts differently when you actually select something or don't. If I am changing or adding a value, I need to select a record and then the prefilter state is being saved and opened in exactly the same way as it was when the record was selected, but if I just am viewing the look-up and change the prefilters in the progress then the prefilters are reset as soon as I am closing the look-up. This feels to me like inconsistent behaviour. [/list] [list] [*] Second, to use the example of Pim, when I am looking for a person and I have a prefilter to filter for Men or for Women then I find that the display of the values are also affected by the contents of the look-up with respect to their current prefilter state. So I have a list of names of which a few are men and I ju
Sorry, I see that my example didn't work. Let's try it again:[img]https://uploads-eu-west-1.insided.com/thinkwise-en/attachment/32de6420-cdd0-4317-b2dc-3f3d2c5253cf.gif[/img]
Hi Moller, With a title like this, I was hoping to find out more about badges in this topic, but sadly I didn't really find what I was looking for. In the meantime a colleague of mine has shown me two pages in which you can find out more about badges. I hope you don't mind putting up a link to these pages. [url=https://community.thinkwisesoftware.com/blogs-21/community-badges-part-one-430][u]https://community.thinkwisesoftware.com/blogs-21/community-badges-part-one-430[/u][/url] [url=https://community.thinkwisesoftware.com/blogs-21/community-badges-part-two-515][u]https://community.thinkwisesoftware.com/blogs-21/community-badges-part-two-515[/u][/url] Kind regards, Mark
Hi Anne, Thanks for your reply. I am glad to know that this is already on your backlog.
Hi Jasper, Thanks for your reply. There is this other thread in which I examined the state of prefilters when changing the prefilters on the lookup and then close and reopen the lookup again: https://community.thinkwisesoftware.com/development-13/look-up-pre-filters-stay-active-562 Maybe the prefilter state works differently on locked prefilters, I didn't test that, and if so then I could definitely achieve this using your solution. In fact I have already used views with an extra column indicating whether the record is selectable or not. So I will definitely try this. Still it means that the view needs to contain a lot of excess records, while the shortlist that I am really interested in might be pretty small. I would think that the overall performance of a lookup might improve if the display and the selection of a value are properly divided. Kind regards, Mark
Hi Anne, Thanks for your reply. I understand that with invalid cardinality you can have multiple translations, but I don’t quite see how this lookup has an invalid cardinality, since the relationships are defined by their primary keys. The following is a screenshot of the data model: I hope you can properly read it. I guess it is still readable if you zoom in.
Hi Anne, Thanks for your reply. I must say that I don’t fully understand the necessity of this particular validation. I understand the fact that if you can reach 2 or more possible translation for the look-up in your look-up chain that you will have a problem that needs to be addressed, but in my opinion that would mean that each individual look-up should be evaluated and if they all prove to be correct then the look-up chain would also be correct. Since my look-ups all use the primary key, they all should prove to be correct. With this strategy you don’t need to validate the look-up chain, but simply validate each individual look-up. In addition this validation is an error which means that I cannot simply approve the validation message, but need to solve it, while in fact there is nothing wrong with the model. Your suggestion to use a prefilter and reduce the number of columns in the reference is actually creating a bad look-up reference, because the reference will undoubtedly find mu
I see that this is on the backlog. I would like to ask how far the plans are for this feature?
Hi Mark, Thanks, I would really appreciate it.
Hi Mark, I know that parsing is difficult and that you can have a multitude of different expression fields, but my suggestion is not to have the SF parse the resulting query and optimise it, but to give this type of control to the developer. I would like to be able to create a join, the same way you would normally draw references. So this is not meant as a replacement for expression fields or a way to make the SF more intelligent, but as an additional method for us to create better performing query’s A view is definitely a possible way to gain more control, but in our experience views also cost a lot of performance.
As I mentioned before it is primarily aimed at reusing the from part to obtain a better performance. It is often the case that when you want to see a field from another table that you also want see another field of the same table or even more. I do see the value in the error that warns about returning multiple values, but the performance of expression fields is definitely something that quickly becomes a problem.
Thanks for the update. If the idea is to extend this further then I am all for it.
Already have an account? Login
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.
We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.
