Marco's Blog

NAV2013 reporting and RDP issues

2013-02-28T10:38:00Z

A couple of weeks ago I ran into a problem with Microsoft Dynamics NAV 2013 in combination with Remote Desktop Clients. I also found a blog describing the problem I found:

In short, when printing reports via an RDP session using a wide-screen resolution. All fonts got squished. We didn't see anything wrong while using the preview function, but when really printing the reports, everything looked distorted.

Well, as I said.. I found the blog post by Mark H I mentioned above, but I didn't quite like the possible solutions. Since one of our customers had a serious problem with this bug I contacted Microsoft.

To my surprise MS was fully aware of the problem but at the time they only had the following solutions:

Use Server Side printing (using the Job Queue)
Deploy a Windows Server 2012 (WS 2012 is not affected by this issue)
Only print on local clients..

It may be clear to all of you that the second option is nice for new customers but personally I can imagine the reaction of existing customers when you'll propose it. ("Who is going to pay for this update?") Server side printing on the other hand is not a complete solution, because this only works for batch printing via the job queue.

The problem for the issue as my MS contact stated was actually not in NAV, but in SQL server and/or Windows 2008. This seems logical since Windows 2012 does not have this problem. They told me that they would escalate the issue to the SQL department.

A couple of weeks passed, and I got a few updates that they were still working on the problem. Then, last Wednesday, I got an e-mail that they found a solution!! The complete description can be found in the following KB article: http://support.microsoft.com/kb/2768741

At the moment we are testing the update, and until now everything looks ok on our development environment. Next test will be on our customer environment. So this looks a bit early to be very cheerful, but I didn't want to keep this possible solution to myself.

Note: Much thanks to Lars Lohndorf-Larsen, Duilio Tacconi and the MS Development team for their support!

[NAV2013] Nobody's perfect: Page 291 and 296

2012-11-21T08:39:00Z

As most of you've noticed, Microsoft has (finally) decided to lengthen most of the text fields from 30 to 50 characters.

To my regret, I must say that the MS Dynamics NAV development team made at least a few mistakes here. When you open the global variables window in page 291 and 296 you will see what I mean.

Yep, your eyes are not deceiving you.. the "Description2" variable is still 30 characters. Off course this doesn't have to be a problem if the function that fills the variable is also using a 30 character parameter. But well, since a picture says more than a thousand words:

As you can see the parameter is 50 characters so here we've got a potential overflow error. We've already reported this issue at Microsoft and they've told us that it will be fixed in a future service pack. But for now as they told us:

"From the current release perspective, please go ahead and increase length of Description2 global variable (page 291 and 296) to 50 chars. This will make it consistent with the parameter that sets value here."

Just so you all know.. nobody's perfect.

Tip: Error "The object file cannot be used with this version of the program."

2012-11-19T15:16:00Z

Last week I ran into the strangest error I ever encountered when using NAV. While EXPORTING an object from my NAV2009 R2 client I got the following error.

---------------------------
Microsoft Dynamics NAV Classic
---------------------------
The object file cannot be used with this version of the program.

---------------------------
OK
---------------------------

Ok, this is strange.. and I wouldn't be as flabbergasted as I was now if I was importing something. But this error when EXPORTING from NAV??

After searching for some time, one of my colleagues (David de Groot) asks what my problem was. I told him what I ran into an his response was equally surprising..

"Did you try to export your fob to another folder?"

Off course I answered that question with a "No"..

Well he explained that he ran into the same problem a couple of days ago. The cause of this problem is that in the folder in which I wanted export your fob file, there was already a fob file that was exported with NAV2013. In all it's wisdom, Microsoft has decided that you can no longer export fobs of multiple versions of NAV directly to the same folder.

To our beloved Dynamics NAV development team: Of course this is a nice safety feature but PLEASE make your error messages better to understand!!!

NAV2013 – BrowsForFolder/Running DotNet Client Side

2012-10-02T09:02:00Z

One of the functions I always missed in the old Common Dialog management was the "BrowseForFolder" dialog. Since I think NAV4.0 I used the function below (using the "Microsoft Shell Controls and Automation").

But well, now we've got NAV2013 and the "Commondialog Mgt." Codeunit was gone! (And so is my old function)

Fortunately we now got the "File Management" codeunit with all those file functions upgraded to RTC. With just a little programming this was my first attempt to recreate the function.

The OpenFolderDialog is a "System.Windows.Forms.FolderBrowserDialog" dotNet variable, aswell is the DialogResult variable (this one I copied from one of the other functions in the codeunit).

Just a piece of clean code, nothing special. Later on, I even found a blog post that reveals even more neat functions.

Next step was to test my function, but then I ran into the following error:

This message is for C/AL programmers: A call to System.Windows.Forms.FolderBrowserDialog.ShowDialog failed with this message: Showing a modal dialog box or form when the application is not running in UserInteractive mode is not a valid operation. Specify the ServiceNotification or DefaultDesktopOnly style to display a notification from a service application.

While looking into what caused the problem I suddenly realised that I forgot one crucial property to set in my variables.

After changing the RunOnClient property to "Yes" ("No" is the default), the error was solved!

When running dotNet components on the client side of your application, keep in mind to check this property!

NAV2013 - Convert your Beta database to the RTM

2012-10-01T08:06:00Z

I just ran into a small 'oops' moment just now.

While the RTM version of NAV2013 is release last week, I decided to updat my client from the beta version to the RTM version.

This is what happened:

I uninstalled the beta client and servers/services
I installed the RTM client and servers/services
I then tried to open my 'beta"-database with the new client.

This is wher everything halted with the message that the database had to be converted. Ok, this is no problem in this case. But when I clicked 'OK', I got the error that the database could nog be converted because there were objects locked in de database. Off course this was a beginners mistake but how to correct it without uninstalling the RTM and re-installing the beta client, unlocking the objects.. etc?

If you run into this problem, this is one solution:

Open your SQL Server Management Studio and input the following query in while connected to the correct SQL instance. (Replace "Demo Database NAV (7-0)" with your own database name)

UPDATE [Demo Database NAV (7-0)].[dbo].[Object]
SET [Locked] = 0
,[Locked By] = ''
WHERE [Locked] = 1
GO

Run the query and close your SQL Server Management Studio before retrying the conversion!

It's just one of those mondays...

NAV2013 - ExportObjects from RTC

2012-09-19T13:35:00Z

Problem?

As Luc van Vugt has posted in his blog, Importobjects and ExportObjects are no longer supported in C/Side code. Because we used this command in many of our development tools I've been looking for an answer for this problem.

First, on the MSDN library, I read the following document: http://msdn.microsoft.com/en-us/library/hh166064%28v=nav.70%29.aspx

In here it states that you can use export objects by using the command line for the FinSQL.exe

OK, that was the first step for me. But how am I going to run this command from RTC as we are not allowed to use the SHELL command anymore?

Solution!

Well, this is how I solved it:

First off all, I created a new codeunit witthe function:

Export Object(VAR Obj : Record Object;Format : 'txt,fob')

In this function I created the following variable:

Name: startCmd
Datatype: DotNet
Subtype: System.Diagnostics.Process.'System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'

Next it was just a matter of entering the following code (ok, I also use a setup table ):

//Exports the selected objects object by object
Setup.GET();
Setup.TESTFIELD("FinSQL filename");
Setup.TESTFIELD("Workspace location");
Setup.TESTFIELD("Server Name");
Setup.TESTFIELD("Database Name");

CommandText := 'command=exportobjects, file="%1", servername="%2", database="%3", '+
'filter="Type=%4;ID=%5", ntauthentication=yes, logfile=C:\QueryExportLog.txt';

IF Obj.FINDSET THEN
REPEAT
startCmd.Start(Setup."FinSQL filename", STRSUBSTNO(CommandText, Setup."Server Name", Setup."Database Name", GetObjectFileName(Obj), Obj.Type, Obj.ID));
UNTIL Obj.NEXT = 0;

Of Course the import objects will probably work in a similar way.. and the system.diagnostics.process.start component can probably be used for a lot of other purposes too!

NAV2013 - Page controls

2012-09-10T08:45:00Z

While upgrading one of our add-ons I ran into the following message.

---------------------------
Microsoft Dynamics NAV Development Environment
---------------------------
Control name 'xxxxxxx' is already being used. Control names must be unique.
---------------------------
OK
---------------------------

Well, what does this mean? In short, when you are upgrading to NAV2013, keep in mind that from now on you can't use the same control name twice within the same page.

It's just one of those small new features you may run into when developing NAV2013.

DDC Event - Session reports are online!

2012-06-22T09:35:00Z

As many of the Dutch Dynamics enthausiasts, I visted the DDC event last Tuesday.

Since I was visiting Waldo's session, Luc van Vugt asked me to write a small blog about this session.(It is in Dutch)

You can see all blog posts of the DDC Events here: http://www.dutchdynamics.net/blog

NAV2013 – Go To Definition

2012-06-19T08:00:00Z

During my exploration of NAV2013 I found out that the NAV development team also changed the "Go To Definition" functionality. In this example I'm using Page 42 "Sales Order".

In NAV2009R2 this context menu is shown when right-clicking the "SalesLines" sub page.

However, when doing the same thing in NAV2013, you get this:

Conclusion: In NAV2013 you can now easily open the used sub page with "Go To Definition" or Ctrl+F12 which will save you a lot of switching back to the object designer!

Note: Do not forget: The next Dutch Dynamics Comunity Event is this evening in Gorinchem (NL) with, among others, a session presented by Partner Ready Software (Gary Winter, Eric Wauters (Waldo) and Mark Brummel).

NAV2013 – Security (2)

2012-06-13T07:32:00Z

After posting my last blog about changes in security for NAV2013, one of my colleagues Jan Trommelen pointed out that he was a bit disappointed about something Microsoft missed while creating the new "User Card" page.

Wouldn't it be nice to have a direct link from this user card to the "User Setup" (table 91) because you now still have to setup a user in two steps.

If you also would like this addition to appear in a future version of NAV2013. Please vote for it on Microsoft Connect!

NAV2013 – Security

2012-06-12T13:50:00Z

As all of you that got their hands on the NAV2013 Beta noticed, a lot has changed. One of the things is that security is no longer set up in the classic client!

On the "Tools" menu, the "Security" menu is missing! From now on the usermanagement is done in the "Administration" department, followed by "IT Adminstration" and "General". In this menu you wil find the "Users" list and "Permission Sets".

As you will notice the user card shows a lot more information in one page then the original user form did. I.e. you can instantly see what permission sets a user has been assigned to. You can also add notes and links to a user.

For now it looks like NAV is supporting the following types of users.

Windows Authentication
Username Authentication
NavUserPassword
AccessControlService

In short, Windows Authentication is equal to the Windows logins we allready new on NAV2009 and earlier versions.

"Username Authentication" and "NavUserPassword" look similar to database logins, although at this time, I wasn't able to test them.

The AccessControlService users are here to prepare Microsoft Dynamics Nav for Azure.

Not all information is available at this time, but in one of my next blogs I will try to get more in dept with the new user options.

NAV2013 - Bye bye forms

2012-05-24T08:21:00Z

As most of you know, with the introduction of NAV2013, Microsoft decided to get rid of forms and dataports alltogether.

Because I developed a set of tools using forms, I wondered if there was a way around this. So I exported my set of tools from NAV2009 as a fob to import it into NAV2013.

It seems that our friends at Microsoft anticipated this as the following images will show to you.

First the fob file as opened in notepad.

Now, when you import the fob file into NAV2013, this is what the import worksheet is showing:

Conclusion: Forms are really really gone.. so back to the drawing board for your development tools...

It's been a long time..

2012-04-27T10:29:00Z

It's been a long time since I wrote my last blog post. Partly because the birth of our youngest daughter, mainly because there was not that mucht news for me to tell at the moment. But that is all going to change in the near future because NAV 7/2013 is coming!

If all goes well, I'm planning to write a few blogs on this new NAV version.

For now, you'll have to do with a Dutch blog I wrote during the Dutch Dynamics Community Event on April 17th.

You can find it here.

The dataport is dead, long live the xmlport!

2011-04-18T13:43:00Z

Since the release of the Role Tailored Client, it is well known that dataports will no longer be supported in NAV. My first reaction to this was: "Oh no, how will we import bulk data into NAV then, if we don't have an XML file?"

And there was another problem; you weren't able to run an XML port directly.

As some of you know I'm speaking past tense here. Somewhere in the release process of NAV 2009, Microsoft listened to the community or had a brain wave and fitted in some new features for XMLports.

For those of you, who aren't familiar with the new features, just read along!

New properties

First of all, Microsoft added a number of properties to the XMLport that make this object type a lot more useful than it already was.

On the left side, the XMLport properties in NAV 4.0, on the right side the properties in NAV 2009 R2. Note that some of the new properties look a lot like properties that we all know so well from dataports!

Does this mean you can use an XMLport as a RTC supported dataport? Yes you can!

Now just look at some of those new properties :

Property name	Allowed Values	Usage
Format	Xml, Variable Text, Fixed Text	Tells the xmlport which type of formatting to handle. When setting this to variable or fixed text, you do not longer have an xmlport but a dataport in disguise.
FileName		The filename to use for the xmlport.
FieldDelimiter		This property replaces the "FieldStartDelimiter" and "FieldEndDelimiter" properties of the dataport. In here you can set the characters that specify the beginning and end of a field.
FieldSeparator		This is the replacement for the old FieldSeparator property, for CSV files you can use ';' here.
RecordSeparator		This is the character that separates records when using a non-XML format. By default, this is "<NewLine>".
TableSeparator		This is the character that separates tables when using a non-XML format. By default, this is a double "<NewLine>".
UseRequestForm		This property sets if you use a requestformpage when running the XMLport (!)

Is this starting to look like a dataport or not?

RequestOptionsPage

Another little known feature of the XMLport is the RequestOptionsPage. In here you can customize the equivalent of the old RequestOptionsForm that we know so well from the old Dataport.

Note that the caption of this page is used when running the XML Port, so keep this in mind.

Creating a simple RTC text export

To make all if this a little more clear, I've created a small example XML port that can export/import customer information in a CSV format.

First we create a new XMLPort with the following layout.

Keep in mind that the first element in a text-XMLport has to be a "Text" source type; I called this one 'Root'. The second element is a 'Table' element called Customer, with the Customer table as the data source.

Next I added the different fields I want to export/import. In this case the fields "No." and "Name".

So far we still got a normal XMLport that would produce the data in XML as a result. To get a CSV file format, I changed the following properties.

Finally, I filled the caption at the RequestOptionsPage and saved and compiled the XMLport.

How to run the XMLport?

In the old days, you had to run an XMLport from code. So next to the XMLport object you had to use a codeunit, report or function to get it to do its magic.

In the RTC this is not an issue anymore. Just add the XMLport to the RTC Menu suite and you are good to go!

When running the RTC, you'll find the XMLport in the menu suite. Just click it and you'll get our new XMLports RequestOptionsPage!

Just set the filters and click 'OK'. Next you'll get the following dialog.

If you choose to open the file, you'll see the result of our work.

The conclusion: We no longer even need the dataport! Because now, all Dataport functionality is merged in the XMLport.

Tip: NAV Classic Server – hidden features

2011-04-14T06:40:00Z

It has been a while since my last blog post. There were a couple of reasons for this:

First, my wife and me are expecting our third child, so I was busy redecorating
Second, I was so busy the last month at work with my projects
And third, I didn't have any inspiration for a new post.

But all that changed last week when our newest MVP Luc van Vugt wanted to install multiple classic servers on a single machine. (I know, this is old school NAV). The installation went ok, but

In the old days (if I recall this correctly NAV 3.70 and earlier) all you had to do was create a copy of the server folder change the name of the second server and make an entry in the hosts and service files for each server and you were good to go. (Note: these two files are in the well-known "C:\Windows\System32\drivers\etc" folder) To change a setting to one of the servers, you just opened the folder of the corresponding server and with the "server.exe" you could change the settings for that server.

In the latest NAV versions things started to work a little different. I'll explain this in the following example.

Setting the hosts and services file

As in the old days, we are going to change the entries in the hosts and service files on the server (and client) machines.

Add the following entries to the hosts file:

127.0.0.1 server1
127.0.0.1 server2

(Note that on the client machines 127.0.0.1 should be replaced by the server's ip-address.)

Add the following entries to the services file:

server1 2407/tcp #NAV Server 1
server2 2408/tcp #NAV Server 2

Now, what's new then?

With the old NAV versions the trick was to make a copy of the server folder and change the settings of that copy to the new server in the command prompt.

So, for changing a setting of one server you just had to browse to the appropriate folder and change the settings using the "server.exe" in that directory. The settings were stored in the directory itself in a "dbms.zup" file.

Now, the copy process is still the same, but there have been some strange glitches now since NAV started to use the windows profiles to store its settings.

The settings are no longer stored per server folder but in the registry. Changing the server name with "server servername=<yourservername>" will allow you to change the server settings for that server using the command prompt.

When installing the server as a service these latest settings are stored in the registry.

As the screen capture above shows, the registry settings can be found by using "regedit".

The strange thing is that you can edit the values in here, but when I got the settings of the server in the command prompt I still got the old settings. The settings that are used in the command prompt also stored in the "dbms.zup" file.

Now here's where it gets tricky, when I just change the folder to the second server in the command prompt. I get a list of the server I changed the latest. These settings get copied out of the "dbms.zup" file and not from the registry!

Latest server settings are shown above. I first installed "SERVER1" in the "c:\server\" folder and then installed "SERVER2" into the "c:\server2\" folder. Now change to the folder of the first server and type "server" and see what happens:

So IF you plan to install two classic servers on one machine, in my humble opion the best practice is to put the complete command string in a batch file (i.e. "Server1.bat" and "Server2.bat") in its corresponding folder.

You probably are thinking by now, why still copy the folder. I asked myself that question too.. When trying to run the two services from the same directory (different database with a different server name) I ran into the following error:

"You cannot open another database or create a new database because the database was opened on the server with the program property database=<database name>. ..."

Since the path of the server.exe is also stored in the registry, my conclusion was that running the exact same executable twice is giving this problem.