Pass by reference vs. pass by value

This one is for myself, as I often forget how to implement pass by reference and pass by value, and what the difference is between them.
Pass by reference:

Declare varible and set it :
SalesLine salesLine = salesLine4

Down-side is if salesLine4 changes - so does salesLine

Pass by value:

SalesLine salesLine;
salesLine.data(salesLine4);

Happy ax-hacking

If salesLine4 changes - salesLine doesn't

Deleting duplicate records in SQL

Recently I needed to delete some duplicate records across several companies in AX. The table is self-contained so I needn't worry about delete actions or validation and as there are several companies I wanted to try and do it SQL-style. So this is what I came up with

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.

The future of X++

During the summmer Microsoft announced that X++ based Web User Interface is discontinues in the next version of EP which hardly comes as a surprise - Dilip has some nice thoughs on the subject, and as he says this will allow developers to use Web 3.0 Framework.

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.

Office 2010 Technical Preview

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.

So last week I tingled a lot as I had the opportunity to join the technical preview community of Microsoft Office 2010. I grabbed the chance to install the 64-bit version, which is one of the new features of Office 2010, on my windows 7 box, and installation was a breeze.

Having a 64-bit version of Office 2010, the Office package probably being the defacto stadard of productivity suites, is a clear indication that 64-bit software is the future, and that 64-bit will most likely be gaining ground in production environments: "With Office 2010 64-bit edition, advanced users will be able to leverage the increased memory capabilities of 64-bit computing and harness this capability for analysis and manipulation of very large data sets and documents" though some VBA code require reengineering to work with the 64-bit version ( from the technical preview site ).

So let's get on the with the preview, starting off with Word 2010

One of the things I do at work is writing documentation, both technical and user-oriented. In AX 2009 ( and 4.0 - with the prober add-on ) I have Task Recorder at my disposal for easy and fast creation of user-oriented documentation. However, sometimes I need finer detailed screen shots than Task Recorder can provide so I use SnagIt for my needs. This works fine.

In Office 2010 this features has been combined with Windows 7's Snipping Tool so that you can actually past previously snipped screenshots directly into your word documented, e.g.:

This functionality does not make third-party programmes superfluous, such as SnagIt, which has many more excellent and useful functions; the funcinality in the Snipping Tool is pretty basic, but it demonstrats how Microsoft manage to integrate/couple standard Windows functionality with other products in the software portfolio.

This is just one of the new features of Office 2010 and as I spend some more time using it, I will most likely post some of my findings. If you have any questions regarding features of Office 2010, drop me a comment and I will see if I can find it.

Copy - paste utility

The lack of IntelliSense in the MorphX IDE ( and being too cheap to invest in AxAssist ) made me browse for an alternative. I found ArsClip which is a nifty little tool for copying and pasting; and not just for programming. It can hold your Copy and with the right setup Ctrl-Shift-V will show you a list of you previous Copy ready to be inserted.

x++ and C# compared

One indicatation that Dynamics AX developers need to learn C# in order to take full advantage of future versions of AX is when MS starts documenting differences in coding practices.

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)"smart typing" ( I don't know what else to call it - but it's the feature when you start typing something VS automatically completes the string ) - it can be done; AxAssist does it for you - but why not integrate the functionality into MorphX as a standard? Well - perhaps in AX 6?

ODBC with FoxPro

I recently had the pleasure of adventuring into the ODBC connection territory. I discovered that many others previously had done the same ( obviously ) but there was a surprising lack of how-to and other documentation. After some extensive searching I found Brandon's blog in which he meticulously documented an implementation of ODBC. Many excellent observations are included in his description, including AOS considerations, i.e. code-execution placing vs. maintenance of Windows ODBC connection ( he runs the code on the AOS server so that the system ODBC connection driver only needs to setup there and not on the client which would reduce maintainability as changes to the connection potentially would have to be distributed to all clients ).

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.

Happy hacking