Search on any part of the field

Alex_Chow · 2010-06-22

Is there a way to do this without entering wildcards in the RTC?

Waldo · 2010-06-23

I don't think so .. and to be honest, I don't hope so

.

With some development, it's possible, but I don't have to explain that to you, of course

Alex_Chow · 2010-06-23

Waldo wrote:

I don't think so .. and to be honest, I don't hope so .

Why not? It's one of the most useful tools when searching for items and customers. Imagine searching on the name:
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.

Waldo wrote:

With some development, it's possible, but I don't have to explain that to you, of course

Do share. Did you blog about this already?

David_Singleton · 2010-06-23

Alex Chow wrote:

Why not? It's one of the most useful tools when searching for items and customers. Imagine searching on the name:
The Cronus Company
Cronus Company

Or the Item description:
42" black leather table
42" brown leather table

Yes but what about performance.

Alex_Chow · 2010-06-23

David Singleton wrote:

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.

DenSter · 2010-06-23

Any part of the field is not so bad as long as find as you type is turned off.

kine · 2010-06-24

DenSter wrote:

Any part of the field is not so bad as long as find as you type is turned off.

But you do not have the standard Find Dialog in RTC... 8)

Waldo · 2010-06-24

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...

David_Singleton · 2010-06-24

Alex Chow wrote:

David Singleton wrote:

Yes but what about performance.

Besides, the search any part of field is already pretty fast in the classic client.

Maybe the customers you have with big systems are more disciplined. In a smaller system it wont be a big issue.

David_Singleton · 2010-06-24

Waldo wrote:

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.

Waldo · 2010-06-24

That might be the case .. I was never aware of this .. and indeed, the developer is an "old school" developer ;°)

David_Singleton · 2010-06-24

Waldo wrote:

That might be the case .. I was never aware of this .. and indeed, the developer is an "old school" developer ;°)

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.

Alex_Chow · 2010-06-24

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...

Alex_Chow · 2010-06-24

David Singleton wrote:

Waldo wrote:

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:

Waldo · 2010-06-25

Alex Chow wrote:

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...

:-k hm .. true ..

Waldo · 2010-06-25

Alex Chow wrote:

...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.

Alex Chow wrote:

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..

Alex_Chow · 2010-06-25

Waldo wrote:

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.

Waldo wrote:

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?

Waldo · 2010-06-28

Alex Chow wrote:

...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

David_Singleton · 2010-06-28

Alex Chow wrote:

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.

Belias · 2010-06-28

Waldo wrote:

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...

Waldo · 2010-06-28

Belias wrote:

... 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 ..

Alex_Chow · 2010-07-01

This search thing is really bugging me.

So if I search on "A Cronus Company" on the customer name, I have to type in

*Cronus*

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?

Mogens_Fogh · 2010-07-23

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??

Any ideas (or bugs)?

Alex_Chow · 2010-07-23

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.

Mogens_Fogh · 2010-07-24

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...

Alex_Chow · 2010-07-24

Mogens Fogh wrote:

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.

djswim · 2010-07-26

Mogens Fogh wrote:

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).

Search on any part of the field

Comments

Categories