Microsoft Dynamics AX Blog
I faced a very strange error two times so far saying that there is date2StrUsr function:
“The wrong number of arguments has been specified for the function”
and on the base enum DateFlags:
“The enumeration does not exist on DateFlags base enum”.
Actually this has happened due to some “crash” in the SP1 of Microsoft Dynamics AX 2009. DateFlags and date2StrUsr with the new arguments have been added to SP1 of Dynamics AX 2009.
I still do not know what the cause of this error is. The two times I have faced this problem were on two different clients where those clients were in the system configuration phase and some data were imported already. So before this error came up, there were using the system with the SP1 installed just perfectly.
Anyway, in order to solve the problem.. you simply have to uninstall the AOS only.. restart your server, re-install it again with the same name you were specifying as an AOS name.
I’m listing here the steps of how you do that in a safe manner. You might not go through them, but if you’re system is up and running and contains data that you don’t want to lose.. do the following:
- Stop the AOS service
- Backup your DB in case you something went wrong (you never know)
- Install a new another AOS instance, DB and Application Files for testing purposes (you don’t need to start the service here)
- Install SP1 on the new AOS and Application Files
- Run the service
- Open your Dynamics AX client on the new AOS configuration. Go with check-list steps.. most importantly: Compile and Database Synchronization (no need to import any data)
- After you’re done of the check list, go to AOT and try to compile: CurrencyExchHelper.. class. Insure that it complies with no errors. (This class uses DateFlags and date2StrUsr of SP1). If you see the same errors on this new AOS instance, then your SP1 installation went wrong. Re-install it again. You might also insure that you are using good installation files by downloading them again from PartnerSource.
- After insuring the the SP1 installation went just right, you might need to move also the customization you were doing on the old instance. So stop the service, get the customized layer like axVAR.aod for example and paste it in the new application folder.
- Run the service again, and compile the whole application by going to: Administrationà Periodic à Compile application
- Now, you need to re-install the AOS service in the same name, by:
- Uninstall the AOS from Programs and features on Windows 2008 or Add/Remove programs on Windows 2003
- Restart the machine (this is important)
- Install the AOS in the same name of the old service (do not run the service)
- Install SP1 for the new AOS
- Stop all services of Dynamics AX 2009
- Start the Microsoft Dynamics AX 2009 Server Configuration Utility and change the application Instance of the old AOS to the new application folder. Also do the same for the database (point to the new database).
- Run the Old Service.
- Open Dynamics AX client on the old configuration and go to the CurrencyExchHelper class. Compile it and insure that it shows no errors.
- Stop the service. Go to the old application folder, delete the file: axapd.aoi
- Start the Microsoft Dynamics AX 2009 Server Configuration Utility. Point the new service (with same old name) to the old database and application folder.
- Run the service.
- Terarararaaaa it runs and no compilation errors again! It is recommended that you re-compile the application again.
Search the site
Dynamics AX 2012 Event
Recent Posts
- D365FO | Cannot Connect to SQL Server Database on Your Cloud Test Machines
- Intro to Microsoft Dynamics AX in Arabic – سلسلة حلقات مايكروسوفت داينامكس إيه إكس بالعربية
- Microsoft Dynamics Launch – Sunday, 24th February – Intercontinental Hotel, Riyadh
- Files of Our AX Brains Dec 2012 Event
- It was a great day!
- Tomorrow is the day for our Dynamics AX Brains Technical Seminar
- Dynamics AX Brains December 2012 Technical Seminar
- Windows Server 2012: Built from the Cloud Up
Tags
Archives
- October 2019 (1)
- January 2014 (1)
- February 2013 (1)
- December 2012 (4)
- September 2012 (2)
- December 2011 (2)
- November 2011 (3)
- July 2011 (3)
- June 2011 (4)
- May 2011 (3)
- April 2011 (4)
- March 2011 (12)
- February 2011 (2)
- January 2011 (3)
- December 2010 (1)
- November 2010 (1)
- October 2010 (5)
- August 2010 (1)
- July 2010 (3)
- June 2010 (4)
- May 2010 (5)
- April 2010 (1)
- March 2010 (9)
- February 2010 (4)
- January 2010 (4)
- December 2009 (11)
- September 2009 (1)
- August 2009 (1)
- July 2009 (2)
- September 2008 (1)
Random Testimonial
- ~ Ahmad Al-Shanshoury, Senior Dynamics AX Consultant at Al-Fanar IT
"I am pleased to be able to write this recommendation for Mr. Amer Atiyah, I was lucky to work with Amer during our implementation of Dynamics AX at AlOthaim company. Since the day one, I know him as an energetic and goal-oriented person Amer demonstrated a strong work ethic and a dedication to success. His efforts have produced high quality results time and time again.His extraordinary ability to analyze problems and outline necessary courses of action was invaluable, simply I can see Amer innovative, creative, intelligent and ambitious, in addition of his powerful Technical background. Seldom have I been able to recommend someone without reservation. It is a pleasure to do so in the case of Amer"
- Read more testimonials »
this error is accured when you compile any method used the base enum DateFalgs from Ax Client that is not updated with SP1.
to solve it just compile the same method from ax client updated with SP1
Totally agree! Thats what must be done simply…
I have had this issue recently. One of my colleagues found a suitable fix. It appears that the Global class function date2Strusr had only 1 variable in the SYS layer. in the SYP layer this was increased to include the flags integer. It seems that somehow this object has not been fully recognised after the SP1 deployment but the classes that call that object are expecting to pass additional variables. we found that, by temporarily adding a USR layer additional change to this Date2StrUSr function, compiling it, and then removing the USR layer had the effect of re-linking the SYP layer version of this function and hence allowing the compile errors to be rectified.
Give it a go as it worked fine for us and fixed all of the compile issues in one go.