Sunday, 20 December 2009
So when it got round to AX development, I was scared s**tless over the lack of how-to's, documentation and manuals for AX. Much of know-how seemed to be anchored in the people who somehow were in contact with the Damgaard company or former Damgaard employees and the most common respons to programming problems was "see if you can find similar functionality in the std. application, and steal with pride". However, many of the problems were not represented in the std. application though of such a general nature, that someone out there must have a solution or hint to how to solve it. And this is where blogs and forums enter the scene. There are a plethora of blogs and forum posts out there which deal with, suggest solutions to an almost ever increasing pool of good questions ( imo - there are no stupid questions ).
Two of the sites which helped me - and continue to do so - are Axaptapedia and the Axapta Programming site and to a lesser extend MSDN, and this blog is my way of repaying the AX community in the same way I was helped in my hours of need for specific problems, and general discussions on AX related stuff.
Then I read the Microsoft Dynamics AX SDK Updates Blog and as of Nov. 10th Community content ( or wiki content ) can be added to articles ( currently only SDK 2009 - but 4.0 is in the making ). Great days are ahead of us - more books on X++ development are published now than when I started, the most recent ( 'Microsoft Dynamics AX 2009 Programming : Getting started' by Erlen Dalen ) appears to be an up-to-date of Steen Andreasen's MorphX IT ( which I still recommend to new AX developers ), but adding the possibilty of contributing to MSDN will increase it's overall value to AX developers out there. Kudos to the MS AX2009 SDK team which do a great job adding value to the documentation which was sparse to say the least until an increased effort from MS came about some years ago.
Tuesday, 24 November 2009
Pass by reference:
Declare varible and set it :
SalesLine salesLine = salesLine4
Down-side is if salesLine4 changes - so does salesLine
Pass by value:
If salesLine4 changes - salesLine doesn't
Monday, 16 November 2009
DELETE FROM [Table with Duplicates]
WHERE [Primary Key Field] IN
DELETE FROM [Table with Duplicates]
WHERE [Primary Key Field] IN
SELECT a.[Primary Key Field]
FROM [Table with Duplicates] a,
[Table with Duplicates] b
WHERE a.[Primary Key Field]!= b.[Primary Key Field] -- i.e. Userkey
AND a.[Value to check]= b.[Value to Check] -- i.e. Lastname
AND a.[Second Value to Check] = b.[Second Value to Check] -- i.e. Firstname
AND a.[Primary Key Field] < b.[Primary Key Field] -- i.e. Userkey
Respect to the original poster at SQL Server forum.
Remember always to backup your data and try the SQL-statement on a test table before you do anything on data which will be used in live environments.
Wednesday, 2 September 2009
On Channel 9 - "Dynamics Program Manager Peter Villadsen and Software Developer Gustavo Plancarte teach us about a new tool they've developed that translates X++ byte code into MSIL. We learn a lot of history along the way and gain insights into the process of taking X++ into the .NET age.
Microsoft Dynamics features a proprietary language called X++ (basically a superset of Java, with some strong data primitives added) and a complete stack (compiler, interpreter and debugger) that goes with it. The new feature Peter and team have developed is a tool to generate managed code from the X++ intermediate language produced by the X++ compiler. This will have profound impact on the performance of the business applications written in X++, and it very clearly points to where they'll be going in the next few releases of Dynamics Ax."
Watch the video here.
My thoughts on the subject - as I posted on Dilip's blog, is that X++ sooner than later will become the new COBOL; 'pure' X++ code and developers will never die completly due to the exsisting code-base already out there, which has to be maintained but when the full implementation of an intermedia langauge parser comes into exsistence .NET programmers will be able to code Dynamics AX customizations in e.g. Visual Studio. There are many blessings in X++ - Extended Data Types and it's function to name one - which does not exsist in other languages ( to my knowledge ) which newer generations of developers will probably not fanthom if the platform will be migrated completly to the .NET-platform.
The progress begs the question - what are the advantages in the migration from X++ to .NET? Hard to tell for a X++ 'evangelist' but one thing could be the that Microsoft wish to consolidate NAV and AX development to the .NET platform through the intermediate language and thus open ERP development to the many exsisting .NET developers. This will perhaps position Microsoft better in the ERP market versus e.g. SAP if in a few years all the .NET programmers will be able to develop ERP solutions?
The days where a X++ developer could get by with "only" SQL and X++ skills are soon to end. Already for ISVs to give customers the full advantage of their Dynamics AX 2009 investment, their competencies has to include .NET programmers and Business Intelligence people (e.g. MDX, Reporting Services) on top of the traditional X++ and SQL teams. This will bring new challenges to ISVs and Dynamics AX team composition.
Saturday, 18 July 2009
Beta testing - technical preview - the words make me tingle, and getting the opportunity to actually get my hands on alpha/beta/RC software makes me tingle even more. I've done my fair share of pre-rtm testing in my time, e.g. running Firefox before it actually was called Firefox, writing this blog post on my Windows 7 64 bit RC box, loving Opera 10 which had many of the features that IE and Firefox later adopted and doing QA for OpenOffice.
Thursday, 25 June 2009
Sunday, 14 June 2009
Personally, X++ was the first programming language which I've felt pretty comfortable with even though I've done som Java programming ( and the mandatory html coding which most programmers start out with ).
I see the need for AX developers to hone ( or just begin on ) their C# skills with the introduction of EP ( version 2009 ) and the reporting service integration with e.g. the role center. I've done som Hello Word-ish programming in C# using Visual Studio 2008 and I must say that I like it. One area where X++ and MorphX out ranks C# and VS is form development. After having created some rather basic forms in C# using VS it was a pleasure returning to MorphX's drag and drop design.
From what I can gather future version of AX will include a brand new approach to the layers and id ranges on elements but these advantages a side - MorphX still could adopt some of the features from VS, in my opinion. One thing I really like about VS is it's IntelliSense (Thanks Morten)
If you are implementing an ODBC connection for the first time on AX 2009, I highly recommend reading Brandon's step-by-step description.
So implementig an ODBC connection should be a run of the mill type of assignment, had it not been for one small detail... FoxPro. One of Brandon's main consideratations was exactly that the ODBC connection should be created on the AOS, but the systems requirements for the AOS in the case in question on which the ODBC connection would be created stated that the OS ( Windows Server 2008 ) should be 64-bit, and FoxPro only runs 32-bit and since the AOS instance in AX2009 runs in 64-bit mode - it cannot access the 32-bit FoxPro drivers ( and as far as I could tell there never will be a 64-bit implementation of the ODBC drivers for FoxPro ).
So maintainability aside - I had to distribute the ODBC connection to all clients force the class which handles the code to run on the client. This can be done since the AX2009 client still runs 32-bit ( and in 32-bit mode on 64-bit OS ).
Task completed - but the journey probably would have been longer and more tedious had it not been for Brandon's blog.
Hope my expericences with FoxPro ODBC connection in connection with AX2009 helps someone, just as Brandon's blog helped me.
Thursday, 14 May 2009
static void importJob(Args _args)
Filename fileName = @"c:\test\test.csv";
permission = new FileIOPermission(fileName, #read);
file = new AsciiIo(fileName, #read);
if(!file || file.status() != IO_Status::Ok)
throw error(strFmt("@SYS76826", file));
while(file.status() == IO_Status::Ok)
line = file.read();
custTable.AccountNum = conPeek(line, 1);
Saturday, 2 May 2009
Thanks to GregP for his helpful tips and insisting that he could get it to work.
EDIT: There is a small aber dabei ( which roughly translates "there is a but", I just happen to like the German term better ). In order for the AutoRun to function, development rights for the user-group are necessary, as the function we utilize is typically used to automate installation/configuration. Giving the user group full development rights though is not an option in this scenario, so after some fiddling about I found that the only security setting the user group needs is SysLastMinuteCheck
which, by the way, only can be set giving the user group full development right and then removing all but this SysLastMinuteCheck.
Tuesday, 17 February 2009
Respect to original poster (though I can't remember where I found it - but the idea is not mine)
On main datasource:
public void executeQuery()
if ( element.args().caller() &&
Friday, 13 February 2009
Therefore I needed to call the method in code, for which I had two options, either calling the form controls method by setting AutoDeclaration to Yes and then calling modified or calling the datasource table's field's method which I chose.
e.g. ProdTable_ds.object(fieldnum(ProdTable, ItemId)).modified();
but where to place the code? After some time I found out that if I placed it on active() of the datasource the form showed the correct information.
Monday, 5 January 2009
void workspaceWindowCreated(int _hWnd)
SqlSystem sqlSystem = new SqlSystem();
LoginProperty loginProperty = sqlSystem.createLoginProperty();
// Put workspace window specific initialization here.
// Show application details in title bar
WinAPI::setWindowText(_hWnd, strFmt("%1 - %2@%3 (%4)", WinAPI::getWindowText(_hWnd), loginProperty.getDatabase(), loginProperty.getServer(), this.currentAOLayer()));