SQL Activity Monitor: Microsoft Dynamics Nav 'Client'

BasDeZwart

Hey all,

I have been stumped regarding this issue for so long that I've decided to register here in hopes that anybody can give me some more tips in order to solve this riddle. Whenever we start the 'Activitiy Monitor' on our SQL instance running the Dynamics Nav DB. we can see who is logged in, from which machine, using which application. Usually when somebody is using their client (We use 5.0 SP1) we see them with the following application description: 'Microsoft Dynamics Nav Client'. But sometimes logins register simply as using the application 'Microsoft Dynamics Nav'. Now we are certain that the executables are exactly the same, and this seems to happen arbitrarily, we cannot recreate this discrepancy. For security and auditing reasons we query the Database regularly, and for now do so with the application name in our 'where' clause. We could use something like 'WHERE Application_Name LIKE '%microsoft%dynamics%' etc..'. But that's dirty, there must be an explainable reason why Dynamics does not always pass the same application name.

I would very much like to find out why Dynamics Nav sometimes announces itself as 'Microsoft Dynamics Nav' instead of 'Microsoft Dynamics Nav Client' to our Database in those cases. It is my personal concern that this might be dangerous in terms of e.g. different NAV versions talking with our DB. Could it be that some clients have a corrupt Nav installation? (We do not figure that to be the case because it only happens sometimes).

Any information on this is greatly appreciated.

Regards,
Bastian

kine

I am expecting this result from research of this problem:

1) The name depends on used language - than there is problem in localization of the client
2) The application is announcing differently when the user is not yet logged in, just connected to the database.

BasDeZwart

Wow, nice find. I'll have somebody check this out and will let you know if this has solved our problems (or atleast give us the security that it couldn't wreck our DB).

kine

BasDeZwart wrote:

Wow, nice find. I'll have somebody check this out and will let you know if this has solved our problems (or atleast give us the security that it couldn't wreck our DB).

Of course, here are other possible causes, this was just from my head, what could be the hint whcih will lead you to the solution...

kriki

Probably it also depends on the client version (and maybe also the build).

BasDeZwart

We have checked these tips, both language and having only the DB open (not the company) did not prove to be the cause (e.g. we can't reproduce this behaviour). We have checked the client versions (and builds), they are all the same (they should be, we use a machine policy to install it so it's the same on all clients). We will now check if the windows locale and language settings might be the cause.

kapamarou

Do you know of any area of your business logic that was built within NAV but uses ADO to connect to the server and execute some procedure or access data? :-k

BasDeZwart

kapamarou wrote:

Do you know of any area of your business logic that was built within NAV but uses ADO to connect to the server and execute some procedure or access data? :-k

YES WE HAVE! \:D/
I am going to check this out right now!
*wonders how he could have missed that*

kriki

BasDeZwart wrote:

kapamarou wrote:

Do you know of any area of your business logic that was built within NAV but uses ADO to connect to the server and execute some procedure or access data? :-k

YES WE HAVE! \:D/
I am going to check this out right now!
*wonders how he could have missed that*

I also wonder how I could forget that: it is correct. I have done some things with ADO and indeed, the Application-text was somewhat different.