Alex, isn't it just a matter of replacing spaces with "*" and go from there?
But I agree with the performance-question. I once had a customer with 250000 items and 40 people continuously searched like *desc* ... on the Item Description and Search Description. This is always a table scan .. . Doing that wih 40 people all the time .. it's a huge load on the database... . The first "*" is a hell.
Furthermore there are solutions to search in any text or code field in a table .. so what we did once was:
- provide a setup in which fields you want to search for a given table
- when searching, split the different words and put them in an array
- do a search and put the results in a temp table... all words should be part of any of the fields in the setup
- show temp table in lookup-form.
So, if you would give in "Alex California" and you would have set up the customer table to search in "Name, Address, City, Country, ...", then you would be amongst the results.. .
This is a performance impact, and the user should be warned about this .. explained how it works .. and they should deliberately activate this kind of search-option, knowing that it can slow down the database... . In that case, it's fine by me ... .
I can't give you the code, because it's part of a product of ours .. but if this explanation is not enough .. I'll try to elaborate some more...
Furthermore there are solutions to search in any text or code field in a table .. so what we did once was:
- provide a setup in which fields you want to search for a given table
- when searching, split the different words and put them in an array
- do a search and put the results in a temp table... all words should be part of any of the fields in the setup
- show temp table in lookup-form.
So, if you would give in "Alex California" and you would have set up the customer table to search in "Name, Address, City, Country, ...", then you would be amongst the results.. .
This is a performance impact, and the user should be warned about this .. explained how it works .. and they should deliberately activate this kind of search-option, knowing that it can slow down the database... . In that case, it's fine by me ... .
I can't give you the code, because it's part of a product of ours .. but if this explanation is not enough .. I'll try to elaborate some more...
This was a part of the original Marketing Module granule for Navision which eventually became Relationship Management in ver 1.3 so was a standard feature of Navision. In the earlier versions it still contained all this code, but was for some reason eventually removed. Its probably where your developers got it from.
Why making RTC harder to search when the goal is to get more people to like RTC?
This client in particular has about 25,000 customers with manufacturing BOMs. If NAV is truly a software for the small-mid size companies, the larger clients with 250,000 SKUs is maybe less than 10% of the whole NAV install base.
I just don't understand why the target it to a specific market when you don't include the features for that specific market...
Furthermore there are solutions to search in any text or code field in a table .. so what we did once was:
- provide a setup in which fields you want to search for a given table
- when searching, split the different words and put them in an array
- do a search and put the results in a temp table... all words should be part of any of the fields in the setup
- show temp table in lookup-form.
So, if you would give in "Alex California" and you would have set up the customer table to search in "Name, Address, City, Country, ...", then you would be amongst the results.. .
This is a performance impact, and the user should be warned about this .. explained how it works .. and they should deliberately activate this kind of search-option, knowing that it can slow down the database... . In that case, it's fine by me ... .
I can't give you the code, because it's part of a product of ours .. but if this explanation is not enough .. I'll try to elaborate some more...
This was a part of the original Marketing Module granule for Navision which eventually became Relationship Management in ver 1.3 so was a standard feature of Navision. In the earlier versions it still contained all this code, but was for some reason eventually removed. Its probably where your developers got it from.
This in a granule called Contact Search. I think your programmer just extended to the customer table.
Searching on a separate screen is great. Where it's really important is when the users are trying to enter an order. Are you saying that they have to open another form to do there search, then go back to the order and type in the proper customer number?
In addition, you cannot type in the customer name on the Sell-to Customer No. field anymore... :thumbsdown:
Why making RTC harder to search when the goal is to get more people to like RTC?
This client in particular has about 25,000 customers with manufacturing BOMs. If NAV is truly a software for the small-mid size companies, the larger clients with 250,000 SKUs is maybe less than 10% of the whole NAV install base.
I just don't understand why the target it to a specific market when you don't include the features for that specific market...
...This in a granule called Contact Search. I think your programmer just extended to the customer table.
Searching on a separate screen is great. Where it's really important is when the users are trying to enter an order. Are you saying that they have to open another form to do there search, then go back to the order and type in the proper customer number?
You can use an alternative lookupformid and go from there. You can also start with the text that was given in the Customer NO. (for example), take that text to the next form, do the search, open in "onlookup" and then if "OK", then use that record (Customer No.). So in fact, you can simulate the lookup, together with the new search function .. all seemless, using the OnValidate of the field.
You get what I mean?
Now, I must say, we didn't re-use the default "Customer No." field on order, but we inserted a new field "Customer Search", and used that OnValidate. Just to not interfere with the default behavious, and still being able to use that default behaviour.
In addition, you cannot type in the customer name on the Sell-to Customer No. field anymore... :thumbsdown:
In a way you still can, even on the very field you want. YOu should get used to the field groups, and the drop down that shows when you give in a customer name. You can set a new "default column". If you set it to "Name", you can just give in the name, and the fieldgroups-dropdown-thingy will make sure you can just type and enter..
You can use an alternative lookupformid and go from there. You can also start with the text that was given in the Customer NO. (for example), take that text to the next form, do the search, open in "onlookup" and then if "OK", then use that record (Customer No.). So in fact, you can simulate the lookup, together with the new search function .. all seemless, using the OnValidate of the field.
You get what I mean?
This requires a lot of programming on the lookups for each table so it's consistant. The number of hours it will take to do this system wide change and I highly doubt customers will be willing to pay for this when it's such an easy process in the classic client.
In a way you still can, even on the very field you want. YOu should get used to the field groups, and the drop down that shows when you give in a customer name. You can set a new "default column". If you set it to "Name", you can just give in the name, and the fieldgroups-dropdown-thingy will make sure you can just type and enter..
If the user knows the name of the customer already, they have to push extra keystrokes, search on the name, then click on it to select?
...If the user knows the name of the customer already, they have to push extra keystrokes, search on the name, then click on it to select?
not necessarily.
If the default filter is set to "name" (which you can do with the field groups/drop down thing), then you just have to give in the name and enter .. it will select the right customer.
If two customers have the same name, there could be a problem .. but you can watch what is going on, because of the automatic dropdown..
But I understand you're not a fan
In addition, you cannot type in the customer name on the Sell-to Customer No. field anymore... :thumbsdown:
I agree, I like the new feature but ...
...why remove the old one. Search Name entry in "No." fields was great. OK not for all customers, but very good for a lot. The only customization I normally make is the code on the table that generates search name.
A good example: I have a client that had the code for their customers as First Three letters then 3 digits. So Cronus International might be CRO102. To do this in Navision automatically is a lot of hassle. So what we did was add code to the Customer Name field something like
Cust.Setfilter(No.,%1..,copystr(rec.no, 1, 3)
if findlast then
incstr
et.
then put this in search name. So the "old" users that know the old codes keep working the old way, but new users we teach the proper Navision way.
You CAN NOT do this in RTC, because its not consistent.
It was a great feature, and it always annoys me when they remove great features *. Oh and history shows that removed features generally come back in 5 or 10 years, so I guess it will be released later as a "new" feature.
* = Red Screens, Indent code, SETGLOBALFILTER, and more that they took away then brought back.
In a way you still can, even on the very field you want. YOu should get used to the field groups, and the drop down that shows when you give in a customer name. You can set a new "default column". If you set it to "Name", you can just give in the name, and the fieldgroups-dropdown-thingy will make sure you can just type and enter..
i thought about it, also...but remember that "personalized" lookups (those with some code in the trigger) can't have the "dropdown lookup" (strange name ), but only the entire form being shown.
another thing i hate is that the ctrl+f shortcut (which is a poor man's old F7) does not get automatically the focus of the field you want to filter...the easiest way to filter a field in a list is to do ALT+f3,ctrl+f and then type the desired value...crappy...
-Mirko-
"Never memorize what you can easily find in a book".....Or Mibuso My Blog
... another thing i hate is that the ctrl+f shortcut (which is a poor man's old F7) does not get automatically the focus of the field you want to filter...
I absolutely agree .. I would like to see that happen as well ..
Just curious. I'm a dev in the Nav win client team and am currently investigating/lobbying for extended search capabilities for next version of Nav. I was focused on global search (Ctrl+F3) in multiple tables, but as mentioned performance is a major player here.
Seeing your response on F3 or Alt+F3, F3 does open up quite a few interesting options for future search capabilities which should be doable even for Nav next. E.g. select field automatically if doing F3 in grid and getting rid of ‘*’ and maybe case sensitivity. However, would it make sense in the F3 search to be able to select an “any” field for doing full table / visible fields search as part of the filter? Or somehow allow the multiple fields search directly??
Well, for starters, I would bring back the existing search features NAV has in place in the classic client. Searching on all the fields in NAV is nice, but I highly doubt its usefulness. Searching on the right field is easily trainable and not worth spending tons of hours of development time on it.
We are already investigating features like search n' replace which would bring in a lot of the classic search. However, global search is the way of the world and what most new users expect...
We are already investigating features like search n' replace which would bring in a lot of the classic search. However, global search is the way of the world and what most new users expect...
The ideal situation is to just have an area where the user can type in the search criteria, then whatever table the form is currently display would search any fields within the table based on the match. The display would sort by whatever the default sort would be.
This would be the most straight forward way to have it implemented without normal users to learn tech. It would also bring the WOW! factor in.
However, global search is the way of the world and what most new users expect...
I've spent years training new users not to expect that
Seriously though, if it means better usability and better performance, wax the current system and have people choose their column. I don't think I've ever gotten a support call from someone searching for a Customer name in the Phone No. field and not figuring it out... at least never more than once from the same person. And I've worked a LOT of Tier 1 support (see my signature).
Comments
With some development, it's possible, but I don't have to explain that to you, of course
Eric Wauters
MVP - Microsoft Dynamics NAV
My blog
The Cronus Company
Cronus Company
Or the Item description:
42" black leather table
42" brown leather table
There's no way the user can easily find what they're looking for.
Do share. Did you blog about this already?
AP Commerce, Inc. = where I work
Getting Started with Dynamics NAV 2013 Application Development = my book
Implementing Microsoft Dynamics NAV - 3rd Edition = my 2nd book
Yes but what about performance.
This is one of the case where usability should trump performance.
Besides, the search any part of field is already pretty fast in the classic client.
AP Commerce, Inc. = where I work
Getting Started with Dynamics NAV 2013 Application Development = my book
Implementing Microsoft Dynamics NAV - 3rd Edition = my 2nd book
RIS Plus, LLC
MVP - Dynamics NAV
My BLOG
NAVERTICA a.s.
But I agree with the performance-question. I once had a customer with 250000 items and 40 people continuously searched like *desc* ... on the Item Description and Search Description. This is always a table scan .. . Doing that wih 40 people all the time .. it's a huge load on the database... . The first "*" is a hell.
Furthermore there are solutions to search in any text or code field in a table .. so what we did once was:
- provide a setup in which fields you want to search for a given table
- when searching, split the different words and put them in an array
- do a search and put the results in a temp table... all words should be part of any of the fields in the setup
- show temp table in lookup-form.
So, if you would give in "Alex California" and you would have set up the customer table to search in "Name, Address, City, Country, ...", then you would be amongst the results.. .
This is a performance impact, and the user should be warned about this .. explained how it works .. and they should deliberately activate this kind of search-option, knowing that it can slow down the database... . In that case, it's fine by me ... .
I can't give you the code, because it's part of a product of ours .. but if this explanation is not enough .. I'll try to elaborate some more...
Eric Wauters
MVP - Microsoft Dynamics NAV
My blog
Maybe the customers you have with big systems are more disciplined. In a smaller system it wont be a big issue.
This was a part of the original Marketing Module granule for Navision which eventually became Relationship Management in ver 1.3 so was a standard feature of Navision. In the earlier versions it still contained all this code, but was for some reason eventually removed. Its probably where your developers got it from.
Eric Wauters
MVP - Microsoft Dynamics NAV
My blog
Actually not sure how you understood my post, but the reason was just to let people know that if they want the code its out there if they look.
This client in particular has about 25,000 customers with manufacturing BOMs. If NAV is truly a software for the small-mid size companies, the larger clients with 250,000 SKUs is maybe less than 10% of the whole NAV install base.
I just don't understand why the target it to a specific market when you don't include the features for that specific market...
AP Commerce, Inc. = where I work
Getting Started with Dynamics NAV 2013 Application Development = my book
Implementing Microsoft Dynamics NAV - 3rd Edition = my 2nd book
This in a granule called Contact Search. I think your programmer just extended to the customer table.
Searching on a separate screen is great. Where it's really important is when the users are trying to enter an order. Are you saying that they have to open another form to do there search, then go back to the order and type in the proper customer number?
In addition, you cannot type in the customer name on the Sell-to Customer No. field anymore... :thumbsdown:
AP Commerce, Inc. = where I work
Getting Started with Dynamics NAV 2013 Application Development = my book
Implementing Microsoft Dynamics NAV - 3rd Edition = my 2nd book
:-k hm .. true ..
Eric Wauters
MVP - Microsoft Dynamics NAV
My blog
You can use an alternative lookupformid and go from there. You can also start with the text that was given in the Customer NO. (for example), take that text to the next form, do the search, open in "onlookup" and then if "OK", then use that record (Customer No.). So in fact, you can simulate the lookup, together with the new search function .. all seemless, using the OnValidate of the field.
You get what I mean?
Now, I must say, we didn't re-use the default "Customer No." field on order, but we inserted a new field "Customer Search", and used that OnValidate. Just to not interfere with the default behavious, and still being able to use that default behaviour.
In a way you still can, even on the very field you want. YOu should get used to the field groups, and the drop down that shows when you give in a customer name. You can set a new "default column". If you set it to "Name", you can just give in the name, and the fieldgroups-dropdown-thingy will make sure you can just type and enter..
Eric Wauters
MVP - Microsoft Dynamics NAV
My blog
If the user knows the name of the customer already, they have to push extra keystrokes, search on the name, then click on it to select?
AP Commerce, Inc. = where I work
Getting Started with Dynamics NAV 2013 Application Development = my book
Implementing Microsoft Dynamics NAV - 3rd Edition = my 2nd book
If the default filter is set to "name" (which you can do with the field groups/drop down thing), then you just have to give in the name and enter .. it will select the right customer.
If two customers have the same name, there could be a problem .. but you can watch what is going on, because of the automatic dropdown..
But I understand you're not a fan
Eric Wauters
MVP - Microsoft Dynamics NAV
My blog
I agree, I like the new feature but ...
...why remove the old one. Search Name entry in "No." fields was great. OK not for all customers, but very good for a lot. The only customization I normally make is the code on the table that generates search name.
A good example: I have a client that had the code for their customers as First Three letters then 3 digits. So Cronus International might be CRO102. To do this in Navision automatically is a lot of hassle. So what we did was add code to the Customer Name field something like
Cust.Setfilter(No.,%1..,copystr(rec.no, 1, 3)
if findlast then
incstr
et.
then put this in search name. So the "old" users that know the old codes keep working the old way, but new users we teach the proper Navision way.
You CAN NOT do this in RTC, because its not consistent.
It was a great feature, and it always annoys me when they remove great features *. Oh and history shows that removed features generally come back in 5 or 10 years, so I guess it will be released later as a "new" feature.
* = Red Screens, Indent code, SETGLOBALFILTER, and more that they took away then brought back.
another thing i hate is that the ctrl+f shortcut (which is a poor man's old F7) does not get automatically the focus of the field you want to filter...the easiest way to filter a field in a list is to do ALT+f3,ctrl+f and then type the desired value...crappy...
"Never memorize what you can easily find in a book".....Or Mibuso
My Blog
Eric Wauters
MVP - Microsoft Dynamics NAV
My blog
So if I search on "A Cronus Company" on the customer name, I have to type in
In the filter field. And it's case sensitive, unless you show the Search Description. Which is another field...
Tell me, what other non-programming application do you use today that requires you to enter * as a criteria?
AP Commerce, Inc. = where I work
Getting Started with Dynamics NAV 2013 Application Development = my book
Implementing Microsoft Dynamics NAV - 3rd Edition = my 2nd book
Seeing your response on F3 or Alt+F3, F3 does open up quite a few interesting options for future search capabilities which should be doable even for Nav next. E.g. select field automatically if doing F3 in grid and getting rid of ‘*’ and maybe case sensitivity. However, would it make sense in the F3 search to be able to select an “any” field for doing full table / visible fields search as part of the filter? Or somehow allow the multiple fields search directly??
Any ideas (or bugs)?
AP Commerce, Inc. = where I work
Getting Started with Dynamics NAV 2013 Application Development = my book
Implementing Microsoft Dynamics NAV - 3rd Edition = my 2nd book
The ideal situation is to just have an area where the user can type in the search criteria, then whatever table the form is currently display would search any fields within the table based on the match. The display would sort by whatever the default sort would be.
This would be the most straight forward way to have it implemented without normal users to learn tech. It would also bring the WOW! factor in.
AP Commerce, Inc. = where I work
Getting Started with Dynamics NAV 2013 Application Development = my book
Implementing Microsoft Dynamics NAV - 3rd Edition = my 2nd book
I've spent years training new users not to expect that
Seriously though, if it means better usability and better performance, wax the current system and have people choose their column. I don't think I've ever gotten a support call from someone searching for a Customer name in the Phone No. field and not figuring it out... at least never more than once from the same person. And I've worked a LOT of Tier 1 support (see my signature).
"Show All..."
"Oh..."