I’ve been through the online help, but can’t find information on how to filter for Test (or similar) I could get close with ?Test?, but I wondered if there was a way to ‘escape’ the * so that it was a character to filter on, rather than a wildcard. Thanks, Chris
Try rec.setfilter(field,’%1’,‘test’); Sorry- I reread your post, obviously this solution won’t work without wildcards…
Hi Chris, I hope i understand you correctly. You do not want to know how to do this by programming, do you? Using * is the right way to set Filters in Navision using F7 or Ctrl+F7. Test filters for all records with an “Test” in the Fieldvalues. Using an @ filters for all, regardless of the upper letters, e.g. @test shows ATEstAAA and Atestbbb and AAATESTAAA. Hope this helps. Regards, Frank
I think Chris actually has a field where the value is TEST Unfortunately, I don’t know how to filter for TEST only and not get ATESTA or BBTESTBB also returned by the filter. I guess there is no way and the “solution” is never using the special character * in a field.
That’s correct Nelson - sorry if I wasn’t clear. The actual data is Test (or similar), and I want to tell users how to filter for that, using field/table filters.
In our old system we also used “" here & there (descriptions, cust name’s. etc) But when we moved to Navision it was becoming a problem. So we exported our data to text file Find/Replaced all "” with “~”. Imported it back - everything works great. Headache gone.
You can use =TEST
[Yeah!] All hail Viktoras! [:D]
Thanks Viktoras, this works for filters. But our client has items named A4 and A14; when she enters A4 in the field, it gets replaced immediately with A14 (the system interprets A4 as a filter, and takes the first matching entry). =A4 does not work, nor does it help to put a filter like >A14. Seeing your post made me think of A?4, and this gives A4 as desired (thanks). But if our client creates an item called AA4, then A?4 will not work. One solution is to set ValidateTableRelation = No in the table, but you need the Developer’s Licence to do this. A very inefficient solution is to rename the item A4 to XYZ123, enter this item, and then rename XYZ123 to A4. If anyone knows of any better approach, I would appreciate knowing about it. Thanks, Alastair
Use SQL Queries to look at the SQL tables directly.
The client uses Navision database, not SQL server.
quote:
But our client has items named A4 and A14; when she enters A4 in the field, it gets replaced immediately with A14 (the system interprets A*4 as a filter, and takes the first matching entry).
Originally posted by afarr - 2005 Jan 26 : 13:34:52
In which field do you have problems to enter item A*4? I tried similar situation, but didn’t find problems
When I enter A4 in the No. field on a Purchase Line (with Type = Item), it gets replaced by A14. This is because A14 < A4 (having an item called A54 would not be a problem, but A14 is), and because ValidateTableRelation = Yes on that field.
The behaviour of this has actually changed during the 3.70 release. I will try to find the specific fix when it occured, but I’m guessing you’re not running with as late as 3.70A? The new behaviour tries to first lookup an exact match in the related table before using a wildcard filter. So entering A4 would find A4 if present.
Thanks, it’s good to know that. The client’s database is 3.7 and may not have the latest fix, but I’m sure that we do, so I’ll tell my colleagues to apply all the fixes up to 3.7A.
Sorry, Chris, I found out more on this: the change was done way back for 3.60 (from hotfix 17 and onwards) but only for the SQL version so the behaviour you describe is still present in the product today for the Navision Server version.