Unlike other languages PowerShell does not allow you to just continue a command on a new line.
You have to specifically tell it to do that by adding a “Backtick” character.
This one:
`
Example:
Split-NAVApplicationObjectFile -Source “C:\Users\Marije Brummel\Documents\Export.txt” `
-Destination “C:\Users\Marije Brummel\Documents\Files\” `
-Force
Whether you like it or not, if you want to be a succesful Dynamics NAV developer in the future you have to understand PowerShell. So do I.
Currently I am working on an integration project where we make an interface between an external solution and NAV using WebServices. Idea is to ship the software with Delta files instead of a fob.
So I am running my PowerShell and notice some differences between NAV2013R2 and NAV2015.
This is what I run:
NAV2013R2:
$MergeResult = Update-NAVApplicationObject -Target “C:\Users\Marije Brummel\Documents\DynamicsNAVNA71\Files\” `
-Delta “C:\Users\Marije Brummel\Documents\Delta\” `
-Result “C:\Users\Marije Brummel\Documents\New Object\” -Force
NAV2015
$MergeResult = Update-NAVApplicationObject -TargetPath “C:\Users\Marije Brummel\Documents\DynamicsNAVNA80\Files\” `
-DeltaPath “C:\Users\Marije Brummel\Documents\Delta\” `
-ResultPath “C:\Users\Marije Brummel\Documents\New Object 80\” -Force
As you can see the parameters have changed, but so has the resultset.
Unfortunately there is not much documentation on the resultset, only on the cmdlet parameters.
But I ran into a video from Bas Graaf taht shows this:
$MergeResult | Get-Member
This returns a list with the object members.
NAV2013R2:
Name MemberType Definition
—- ———- ———-
Equals Method bool Equals(System.Object obj)
GetHashCode Method int GetHashCode()
GetType Method type GetType()
ToString Method string ToString()
Conflict Property Microsoft.Dynamics.Nav.Model.Tools.ApplicationObjectFileInfo Conflict {get;}
Error Property Microsoft.Dynamics.Nav.Model.Tools.ErrorInfo Error {get;}
Id Property int Id {get;}
ObjectType Property string ObjectType {get;}
Result Property Microsoft.Dynamics.Nav.Model.Tools.ApplicationObjectFileInfo Result {get;}
UpdateResult Property Microsoft.Dynamics.Nav.Model.Tools.UpdateResult UpdateResult {get;}
NAV2015:
Name MemberType Definition
—- ———- ———-
Equals Method bool Equals(System.Object obj)
GetHashCode Method int GetHashCode()
GetType Method type GetType()
ToString Method string ToString()
PSPath NoteProperty System.String PSPath=C:\Users\Marije Brummel\Documents\New Object 80\COD84001.TXT
Conflict Property Microsoft.Dynamics.Nav.Model.Tools.ApplicationObjectFileInfo Conflict {get;}
Error Property Microsoft.Dynamics.Nav.Model.Tools.ErrorInfo Error {get;}
Id Property int Id {get;}
ObjectType Property string ObjectType {get;}
Result Property Microsoft.Dynamics.Nav.Model.Tools.ApplicationObjectFileInfo Result {get;}
UpdateResult Property Microsoft.Dynamics.Nav.Model.Tools.UpdateResult UpdateResult {get;}
So as you can see (I hope) the Path is missing in NAV2013R2.
What I ended up doing is using the NAV2015 cmdlet for NAV2013R2 objects. There is probably a smart way to figure out a filename from the other properties.
Challenge for someone?
Marije
With Microsoft Dynamics NAV 2015 Microsoft introduced a great new property on the Report object: Temporary.
This behaves the same as the SoureTableTemporary property on a page and basically eliminates the need of using integer dataitems and loops on reports.
It also makes it easier to use Query as a datasource for a report like I did for a page in this post:
https://marijebrummel.wordpress.com/2013/09/10/tip-35-using-queries-in-pages-reports/
Lets repeat this exercise. We will use the same Query and Temporary Table and use in on a report instead.
The query combines sales information from the Value entries per customer.
And we create a class for the query as a table.
We need to define the table on a report and activate the new property
And since the table is now empty we need to populate it like the table on the page like this:
Then after we created a Layout for the report:
Voila, enjoy
This post is more a reminder for myself, each time I run into this when installing NAV on customers machines I have to search for the command.
I love modern development, PowerShell, TFS, etc. But it does not make life easier to understand all these technologies.
When running PowerShell on a new machine you might encounter this error:
It is telling you that PowerShell scripts are disabled.
Enabling is easy by running the Windows PowerShell IDE as administrator and executing this:
Works for me. After this I can work with the Development Commandlets.
Every now and then it happens. I get the feeling I am the only one not knowing a trick. Off course I realise that is not the case so I share what I learn.
MenuSuite and Search
As you might know or should know, the MenuSuite object is used for the search in Dynamics NAV.
This is the reason why you see almost a dozen instances of Navigate when you search it. It has been defined in the MenuSuite at as many places as that.
Search Criteria
So far nothing new for me. However I was watching How Do I videos this weekend from Claus Londstrom and Alexander Totovic when I noticed them typing in this:
If you type in “rep sel sal” it will search for words containing these words. This was the thing I did not know and wanted to share.
Enjoy.
I’ve already posted a few times about the possibilty of doing SETCURRENTKEY on non key (indexed) fields and doing flowfields and CALCSUMS on non SumIndexFields.
Another option that we have is to do a SETCURRENTKEY on a flowfield.
For example:
This will give the following result:
And we can check that this is correct:
Be careful. Mind performance.
Enjoy.
Ok, enough about these Design Patterns. Time for a real tip you can start using in 3 minutes.
We all know that pages use more real estate than classic forms and we are limmited to two columns. Putting two controls side by side in one column is cumbersome.
One of the things I run into a lot since I do many logistics customers (TMS) is addresses on pages. When not on Master Data you are typically not allowed to change them.
Address fields take up a lot of space, like here:
We need up to five elements to display an address. What if I tell you how to show it like this:
It is extremely easy. An address uses the room of less than 2 normal fields.
Step 1 – Add Function to Source table
Like this:
Here we return the address with a cariage return and line feed between the address and the Post code. You can make this smarter off course.
Step 2 – Add Function as Control with MultiLine property
Like this:
And voici, you are good to go!
This Blog Article was brought forward from my old blog
After all the theory about VSift in my previous blog posts now a tip about how to tune VSIFT.
Before I continue first this.
VSift is not a bad technology but the implementation in NAV has one big downside. The good old SIFT levels have disapeared.
In older versions of NAV there was a SIFT Level property. This enabled you to decide which SIFT level best suited your implementation.
Many people say: Disable all top levels. But I disagree on that. Measure the exact levels you need and only enable those or better: creating your own levels.
That is what this blog is all about: creating your own levels. Before SQL came I used to tune big C/Side databases and also then we did not have this SIFT Levels property, so we had to create our own.
To know how that is done it is critical to know how the NDBCS driver works. This driver decides which VSIFT to use. This driver is as stupid as SQL is intelligent. (Sorry Dean). As far as I know it has always been this way, also in the Natvive days but maybe some MSFT folks can post about this.
When NAV need to calculate a flowfield it reads the Key table top down and grabs the first key that matches the definition.
Now since selectivity and number of reads/records is extremely important for your performance it can be interesting to create keys that are narrower and reduce the number of reads.
Example:
When I open the G/L account in NAV this query is executed:
SELECT
SUM(“SUM$Amount”) FROM dbo.”CRONUS Nederland BV$G_L Entry$VSIFT$1″ WITH(NOEXPAND) WHERE ((“G_L Account No_”=@P1
))
With an average of xx reads.
Now when I disable this VSIFT$1 level, NAV has to go to the next available level.
When the other fields in the index are heavily used and have a lot of values, the number of reads can be huge!
So what if you have a customer who uses NAV for 7 years thus having potentialy 2500 posting dates.
In the old days you would simply enable the top SIFT bucket but what with VSIFT?
Answer; Create a new key above the old keys so the driver will pick that up and give it priority.
Voila, it is as simple as that.
BUT: Be carefull: You could potentialy be changing business logic. NAV has the nasty habbit of allowing halfsyntaxed SETCURRENTKEY statements. In that case it uses the first key that it can find that starts with those fields. Maybe that in another blog… 
Ok, I admit this is not a tip, but information I found out today and could not find anywhere in documentation.
I am upgrading one of my longer running customers to NAV2015 (eventually). So one of the tasks is to make pages for these creative forms with many fields.
I thought to be smart and save some real estate by promoting a fast tab with a lot of flags. I had 8 flags, so I expected a fasttab with 8 occurances of Yes or No.
Instead, there are only 5 promoted fields. (Nee means No in Dutch).
So I started experimenting, searching on internet and testing in 2015, since I am making the pages in 2009R2 for a hybrid phase.
It seems that there is a limit of promoted fields on fasttabs to 5. Don’t ask me why. Must be something someone thought make sense as a decision for the entire NAV community.
So, Microsoft: Please remove this limitation, or at least make it like 10 or so.
Marije Brummel Blog | Business Central, Azure and more...