Microsoft Dynamics GP 2013 Web Client - Tidbit

Well, this one is surely a delight for me personally, because I am a die hard Dexterity Developer and I always had and will recommend any customization to be on Dexterity.

I am currently watching Convergence 2012 virtual session named "The Road to Microsoft Dynamics GP '12'"and got this snapshot which is self-explanatory:

I took this snapshot as is from the virtual session.

Recently I converted all our existing VBA customizations (critical ones) to Dexterity and now this news. Those who were preaching against Dexterity and predicted it's doomsday, please change your mindset at least from now.

VAIDY

Perils of Using of DEX_ROW_ID on Customization / Integration - David

This one is certainly a nasty issue, if we are going to use DEX_ROW_ID value on customization or integration.

I have personally fallen into a trap by using DEX_ROW_ID on my customization. But now, it's all wisdom out of that bad experience.

Only time when I normally depend on a DEX_ROW_ID is to sort records to understand which record was entered last in the table. That itself may not be always correct. So we may have to add other logical fields that are relevant to a particular record.

For instance, if I have to list out transactions entered on a particular day and check in the order in which the records are created, I would use the Transaction Date and DEX_ROW_ID as SORT ORDER.

There are many other reasons, but restrict yourself to use DEX_ROW_ID only for selecting records and analyze it.

VAIDY

Using substring() with Text Fields - David

Back from my vacation, several posts grabbed my interest as a developer. This post from David is one of them.

David explains how to resolve an issue that was found in Sivakumar's SDT (Support Debugging Tool) based solution. In a nutshell, the issue was with Text type fields and dexterity function substring().

Read it here; Quick Tip: Using substring() with a text field datatype.

VAIDY

Best Practice for Dexterity Version & Build Numbers - David

David's post, Best Practice for Dexterity Version and Build Numbers, explains a very important concept in chunk creation process.

We must version our products which is very important and also ethical. Small-time Dex developers do not understand this process when they deliver a simple customization. 

I sincerely believe that this post from David would enlighten people about this.

VAIDY

"Illegal Address Field" Error while accessing a Global

This one's interesting and quite straightforward too.

I had to create a new Global field in my customization. Instead of creating a new field, I added an existing GP field ('Customer Number') and wrote my code to assign value and retrieve value as required.

I created the chunk and when my code was executed at run-time, I received the following error message:

At the first look, it's all correct. I have referred to a Global field which exists pretty much in my dictionary, otherwise it would not have even got compiled in first place.

So what else would be the reason? It's plain and simple. I created a "new Global field from an existing GP field". Which means, when I created my chunk, I should have added this resource explicitly to my dictionary, using Transfer Resources Dex Utility option. OR I should have first created a new field itself and then add that to Globals.

Since I didn't do above, compiler did not find that resource at all in my dictionary or GP's dictionary (Dynamics.dic) and then threw this error message.

I created a new field itself in my custom dictionary and added that to Globals. Things were perfectly alright.

Sometimes, focusing more on brain draining issues may actually drain your brain. Well, I am serious. Otherwise, how in your opinion I missed this above simple concept?

Update: David has posted a quick tip on why this issue occurs and what is the best possible solution to this.

VAIDY

Access data from other companies from Dexterity

David walks us thru' how we can access data from other companies from a Dexterity code.

I have never written a code like this in my 8 years of experience. That said, I have not met any requirements that challenged me to write such code. With this, David has eased my (our) efforts in finding how it can be done.

Thanks David.

VAIDY

Using Script Debugger in Runtime Mode

David explains us about using Script Debugger in Runtime mode.

There won't be any performance issues obviously as stated by him, but there are some crucial points that we need to think about before enabling it.

Enabling it on live environment is like inviting disaster. I remember I used to do that, but only after all users log off from GP. That particular customer, they don't work 24/7 which gave me the confidence to enable it on live and disable it back once my troubleshooting was over. I would have been in very deep trouble easily had I not remembered disabling that after my task.

Even a single Dex debug message box would be more than enough to drive a user crazy.

VAIDY

Required Fields - Additional Tip

This one is a simple tip, yet very useful one. Frank reminds us on where and what would be the problem if we don't see required fields as we wished to.

Now, this one is for developers. If it's a customization that we have developed and on that if users are not able to see required fields as they wish, then you know what the problem is: Set Required property to TRUE without fail for all fields that are suppose to be REQUIRED and make sure that you have linked the prompts (Link Prompt action) for those fields correctly.

VAIDY

Dexterity Script Profile to solve Performance Issue - David

Waiting for 30 seconds after simply clicking a checkbox is indeed a nasty thing.

David explains us on how to solve Performance Issue using Dexterity Script Profile by taking above issue, reported by some customer.

It's a detailed post with step by step explanations on how he could solve it.

Must read for all consultants and developers.

VAIDY

Dexterity "Reject Script" Command - David

David's recent post on reject script command in Dexterity has got some really crucial information about it's scope and usage.

After 7+ years of Dexterity experience, I did learn something which I had not in the past. MUST READ for any Dex developer.

VAIDY

The Future of Microsoft Dynamics GP Technologies - Mariano

Mariano highlights 5 coolest technologies for Microsoft Dynamics GP in coming years to watch out for. I can't agree for more, since I am already seeing 3 of the highlighted 5 currently.

Just to list you those technologies:

1. Microsoft Lync
2. Microsoft Silverlight
3. Microsoft Visual Studio Lightswitch
4. Cloud Computing
5. Microsoft Dexterity (yeah you did hear it right)

And to know why the above are cool, check out his post: The Future of Microsoft Dynamics GP: 5 Cool Technologies You Should Watch For (and Learn) in the Coming Years

VAIDY

Issues with GP 2010 SP1 DYNAMICS.DIC - David Musgrave

David informs us about a very strange but critical issue that's been faced by developers when using GP 2010 SP1 DYNAMICS.DIC dictionary.

This is really critical to be informed about, so all Dex Developers please make sure that you read this post from David, as it also mentions some workaround till a proper fix is released.

Read it here: Unknown identifier 'DYNAMICS' or other Constant with GP 2010 SP1.

VAIDY

Microsoft Dexterity 2010 R2 - Enhancements

David sums up Dexterity 2010 R2 enhancements and gives us a glimpse of how it's going to be, referring to Feature of the Day posts from Inside Microsoft Dynamics GP.

Pretty exciting to learn these new features, obviously.

VAIDY

Difference between Saving & Compiling a Dexterity Code

I was quite taken back by this very difference of Saving a Code and Compiling a Code in Dexterity.

Alright, let me explain.

I was demonstrating a customization my team yesterday and I had to change some code to show a Window on a Button Click event. The only code I had to change in that event script was to add the following statement:

open window [Window_Name];

And even a Non-Dexterity developer would tell us that the above statement do not contain any error, unless the window [Window_Name] do not exist at all. But in my case it did.

I SAVED the code and closed the Project. Created a Chunk and deployed it. To my confusion, the code piece that I added never worked. I was confused to say the least. Why not? I did add the code and created the chunk.

That's where I made a mistake. I SAVED the code instead of COMPILING it. Only when we compile a Dexterity Code, it gets effective. Saving the code won't affect the business logic and it would not have reflected in the chunk on that portion.

So, SAVING a code is totally different from COMPILING a code.

VAIDY

Dexterity Incompatibility with .NET Framework 3.5SP1

This post from Dynamics Confessions blog, informs us about Incompatibility of Dexterity 10.00.320 Build with .NET Framework 3.5SP1.

Those who are working on similar lines, have a look at this article and be informed on what needs to be done in such scenarios.

NOTE: Download Dexterity 10.00.324 Build separately from PartnerSource and install it as soon as you apply GP SP4 on Dexterity. Because this particular Build 324 is the actual SP4 for Dexterity Common Components and Dexterity itself.

VAIDY