Art Of Creation – Dynamics AX Blog
The everyday life of a Dynamics AX developer
July 22, 2010 at 14:43
filed under Dynamics AX
Tagged Application, Dynamics AX, hotfix, Roll up
Hi all!
There seems to be a problem with the recently released RU5 for Dynamics AX 2009 SP1.
Dynamics AX clients are supposed to be backwards compatible, so you can always use the latest client, even if you want to connect to an application with a lower version (e.g. AX 2009 RU4 client to AX 2009 RU3 application). (Edit: Read comment #4 by Florian Dittgen)
But when I tried to connect to an AX 2009 RU3 application (5.0.1500.1313) after I updated my client to RU5 (5.0.1500.2985), it didn’t work.
Dynamics AX only shows the first record in the forms when you use that combination, as you can see in the screenshot below.
Roll up 5
When you connect using a RU4 client (or RU3), there is no problem at all.
Roll up 4
You can uninstall a hotfix rollup from the Add/Remove software screen in the windows control panel if you want to.
I prefer to duplicate the client folder each time I upgrade it so I have all client versions available.
Just fire up bin\ax32.exe for the version you want and you’re good to go :-).
Kenny Saelen
on July 22, 2010 at 16:02
I actually noticed this one today !
I think the problem seems to be with the extra method added to the grid control to enable / disable the automatic resizing of the columns for performance reasons..
Luegisdorf
on July 23, 2010 at 11:25
Confirmed, had the same probleme here, but in a funny way the effect only concerns some tables while on other tables all works fine.
To run concurrent client versions is a good idea. And with the SmartStart 3000 user doesn’t need to decide which client executeable has to be used ^^
kamal
on July 26, 2010 at 22:09
I did have this problem today..but for me the case was strange. The App version and Client version were matching with each other still we had the same situation.
When we examined we found that all the query from the form were suffixed with select firstfast …. so strange finally we ended up re installing everything….
Florian Dittgen
on August 8, 2010 at 11:52
Hello Klaas,
You wrote that Dynamics AX clients are supposed to be backwards compatible, but I don’t agree to this. Ax clients are only compatible (and supported by MS) to the AOS if both have the same kernel build. Until now the clients could run in most cases with a different build, but this happend more by accident then by design. This is the reason why future Ax version will explicitely check this and respond with an exception if the builds are different.
Cheers,
Florian
Klaas Deforche
on August 8, 2010 at 12:15
Hi Florian,
Thanks for your comment and clearing things out.
It seems that I was misinformed about the supposedly backward compatibility.
Good to hear that there will be a check on this in future AX versions. That should make a lot of people’s jobs easier :-).
Arno
on October 20, 2010 at 17:09
Hi Klaas,
Finally I found some more informations about this strange problem we here also have.
We installed a few weeks ago RU 5. And on the server which is now on 5.0.1500.2985 for kernel and application we have the problem that only one record is showed.
If we connect via a workstation, we don’t have the problem.
But workstation is on Kernel 5.0.593.0 and on Application on 5.0.1500.2985.
We logged a ticket by MBS but they don’t seem to know about it.
How concretely can I solve the problem and also running this last RU? Thanks for your answer. Arno
Klaas Deforche
on October 21, 2010 at 22:43
Hi Arno,
The client on your workstation is still 5.0.593.0, correct?
You’ll have to upgrade this client to RU5 (5.0.1500.2985) too.
Client en server kernel versions should always be the same, or you will have all sorts of weird problems.
The application version can be lower than server/client versions (According to someone at Microsoft)
Also, after upgrading, it couldn’t hurt to remove all .auc and .kti files from the users documents and settings on the workstation that is causing problems (C:\Documents and Settings\[USERNAME]\Local Settings\Application Data for XP, or C:\Users\USERNAME\AppData\Local for Vista/7).
We also had problems, even after upgrading to a new client, and the problem was solved by removing those files.
Arno
on October 22, 2010 at 12:05
Hi Klaas,
Thx for your answer.
That’s what I also understood by googling on the web.
But I repeat, the problem I’ve is only on the AOS and Server.
If I connect on AX via a workstation and where the client is on Kernel 5.0.593.0 and on Application on 5.0.1500.2985, I don’t have this kind of problem. Nevertheless I’ll try to do what you suggest (and taking before a BU of the client folder :-)) but I’m affraid that I will have the same problem on my server.
In any case I keep you informed. Greetz, Arno
Arno
on October 22, 2010 at 14:47
We finally solve the problem by installing again the RU5 on the AOS and now we see all the records :-)
But after digging on the web and after harassing MBS I can confirm that:
1) the kernel version of the AOS and the kernel version of the client OF the workstation HAS TO BE the same.
2) after installing a RU, you have to check if in the install folders there is a MSI folder
3) SO YES, you should install the components32.msp (or 64 if you are on Windows 7) on the workstation running AX2009. Doing this put the client of the station on the same level kernel of the AOS. By doing this keep in mind to do a backup as suggested by Klaas here above. Thanks to all!
Klaas Deforche
on October 22, 2010 at 15:57
Hi Arno,
Like you say: client en server kernel version MUST be the same, on every machine.
Thanks for the update!
JimChw
on November 2, 2010 at 17:35
Back in 3.0, the app and kernel versions had to be the same, but then Microsoft “de-linked” the versions (around SP6) so that kernel and app could be different versions.
I think the intent is to stay within the same service pack with app and kernel versions. You could apply a kernel fix that doesn’t affect the app version and vice versa. That should be OK. However, if an app fix comes with a kernel fix I like to install both.
Ajit
on December 23, 2010 at 16:02
Is any one has permanent solution of this issue?
Klaas Deforche
on December 23, 2010 at 20:45
Hi Ajit,
The solution is to use the same version for your client and you server. So if you have updated you server, apply the same update to all clients.
Regards.
Gonzalo Garcia
on March 1, 2011 at 21:54
We recently updated to RU5 in our company, and this problem showed up, and as Klass suggest, the solution is to make both client and server the same version.
But now I am facing a weird problem, I updated my local development environment to RU5 (5.0.1500.2985) both client and server and the problem remains, i have reinstalled everything (Client, AOS and App files) from zero and when I tried to run the upgrade again the installer told me that there was nothing to be updated.
I am basically stuck with this. Any of you guys have an idea about what is going on?
Regards,
Gonzalo
Klaas Deforche
on March 2, 2011 at 10:04
Hi Gonzalo,
That’s strange, if the versions are the same, everyting should work.
The only thing I can think of is removing the AUC and KTI files ( (C:\Documents and Settings\[USERNAME]\Local Settings\Application Data for XP, or C:\Users\USERNAME\AppData\Local for Vista/7)). I noticed some problems with those files after upgrading in the past.
Also, check the version info on ax32.exe and ax32serv.exe to be absolutely sure you have the correct versions. Also start you client bij clicking on ax32.exe instead of using a shortcut.
You are connecting to you local (HR5 upgraded) AOS, right? If you connect to an other AOS, this one should be HR5 too.
Gonzalo Garcia
on April 19, 2011 at 18:06
Hello Klaas,
This issue was solved by reinstalling everything once again, I have to admit that it was a very odd situation. The good part is that now everything is working fine.
Klaas Deforche
on April 19, 2011 at 19:22
Very odd indeed, I’m glad you solved it.