C/SIDE Solution Development: When to use validate

Capone
Member Posts: 125
Hi!
I'm studying to the C/SIDE Solution Development exam and during my studies I can't really get a grip on when to use validate.
Don't get me wrong, I know how to use validate it is more a philosophical on how often I should use it.
I have almost stopped using := instead I use validate. Sometimes it has happened that I need to write some validation code in a trigger but then I realise that the coder before haven't been using validate when given the field the value which means that I have to go through all code that has := and replace it with validate which could be a time consuming process.
In the C/SIDE Solution Development examples they mostly use := unless they know they have trigger code that want to run with validate.
What are your opinions about validate? Do you prefer it over := or do you only use it when you need it?
I'm studying to the C/SIDE Solution Development exam and during my studies I can't really get a grip on when to use validate.
Don't get me wrong, I know how to use validate it is more a philosophical on how often I should use it.
I have almost stopped using := instead I use validate. Sometimes it has happened that I need to write some validation code in a trigger but then I realise that the coder before haven't been using validate when given the field the value which means that I have to go through all code that has := and replace it with validate which could be a time consuming process.
In the C/SIDE Solution Development examples they mostly use := unless they know they have trigger code that want to run with validate.
What are your opinions about validate? Do you prefer it over := or do you only use it when you need it?
Hello IT, have you tried to turn it off and on?
Have you checked the cables?
Have you released the filters?
http://www.navfreak.com
Have you checked the cables?
Have you released the filters?
http://www.navfreak.com
0
Answers
-
-
Thanks! Exactly what I was looking for but I had hoped for an more simplier answer but they usually aren'tHello IT, have you tried to turn it off and on?
Have you checked the cables?
Have you released the filters?
http://www.navfreak.com0 -
I don't agree with the gimmicky message in that blog post at all, it simplifies this issue way too much. There's no hard and fast rule as to when to use it and when not to. It's up to you, you have to decide whether to validate a field or if you want to take care of associated values in your code.
One very common modification is to automate certain steps, like some process that automatically creates an order based on certain parameters. I usually start with actually doing the process manually myself, and note what all happens during the process. simulating a manual process often is a series of strategically placed VALIDATE statements. You'll be amazed at how much happens automatically behind the scenes when you validate field values. Setting up a completely valid sales header for instance can be as simple as doing an INSERT(TRUE), and then validating the Sell-to Customer, the External Document number. Then on the line rarely does a user need to do more than enter an Item number and a Quantity, and maybe 1 or 2 other fields. By simply validating those fields, you can automate that process very quickly.
On the other hand, there are some functions that are called repeatedly (Quantity and Amount update functions for instance), so it pays to investigate each process and see if you can find those and change it to simple assignments. HOWEVER, if you DON'T validate, then you WILL need to take care of business logic in code. Most of the time though, VALIDATE is a very powerful tool to make sure that business logic runs properly.0 -
mohana_cse06 wrote:Have a look at this blog
http://dynamicsuser.net/blogs/vanvugt/archive/2011/01/18/never-use-validate.aspx
The article written is not good advice and I do not recommend any person taking that article seriously.
The rule is to use VALIDATE when there are coding behind the fields you're modifying. There are exceptions to the rule, but not many cases.
The order of what fields to validate is important too if you're inserting or modifying a table like item journal or general journal.Confessions of a Dynamics NAV Consultant = my blog
AP Commerce, Inc. = where I work
Getting Started with Dynamics NAV 2013 Application Development = my book
Implementing Microsoft Dynamics NAV - 3rd Edition = my 2nd book0 -
The article by itself is not good but the discussion in the comment section is good. It makes you aware of the pros and cons about using validate.Hello IT, have you tried to turn it off and on?
Have you checked the cables?
Have you released the filters?
http://www.navfreak.com0 -
Hey guys, the article (my writing) was intended to get that discussion. I see you are critical, and yes you should. But then also read the series I wrote on validation and then you could understand what I meant all together. There I also explain what Daniel suggest toDenSter wrote:start with actually doing the process manually myself, and note what all happens during the processDenSter wrote:are called repeatedly (Quantity and Amount update functions for instance), so it pays to investigate each process and see if you can find those and change it to simple assignments0
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 116 Navision DOS
- 851 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 617 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 320 Dynamics CRM
- 111 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 990 SQL General
- 383 SQL Performance
- 34 SQL Tips & Tricks
- 35 Design Patterns (General & Best Practices)
- 1 Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.6K General
- 1.1K General Chat
- 1.6K Website
- 83 Testing
- 1.2K Download section
- 23 How Tos section
- 252 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions