I have a requirement in which I have to access a SQL view from within my customisation dictionary, in order to create a custom lookup for users to select a value based on an Extender form and an Extender lookup. Easiest option is to create an Extender view (which in turn creates a SQL view for us).
Now, this is the view that I am suppose to refer to from my custom dictionary. Dexterity allows us to refer to any SQL object by simply create a TABLE definition and mention the SQL object (table or view) name as the physical name.
Everything looks perfect till you actually see below error messages at runtime:
Error message is quite obvious; you do not have DEX_ROW_ID in that SQL view that you are referring to. Every single Dexterity table must have DEX_ROW_ID at the backend. It cannot afford to not have one.
So how am I going to resolve this? By simply adding a record number dynamically to the SQL view created by Extender. How to do that? By adding the T-SQL function ROW_NUMBER(). This is how I achieved it:
Everything works other than pictures; that’s what I had found. Upon drilling down further, what I realised is that it sounds obvious that it doesn’t work on Mac based browsers. Reason: Native Pictures.
Definition of Native Picture says following:
Consider, for instance, the following snapshot of GP login window on a web client rendered on Mac Safari:
It’s not shown. Initially I thought it was something to do with Silverlight rendering. But not exactly. It’s because, this picture is a Native Picture. And by definition, it’s specific to Windows OS. Look at this picture definition below:
Apparently, by nature, it’s NOT supposed to show up on any OS other than Windows.
It’s not just this picture. Lookup Button icons, Note icons are all Native Picture types. And due to that, they are not going to render on any other OS. And if I am not mistaken, this will remain as it is at least till next major version of GP.
Those who implement GP web client MUST be aware of this.
This book is penned by one of the most experienced GP personality and multiple times MVP, Leslie Vail. Packt Publishing has published this book.
I strongly recommend this book to all GP developers/consultants who would like to know how to develop anything with regards to Dynamics GP; be it a new feature addition, a feature modification or just a cosmetic enhancement.
Thanks Leslie Vail for this wonderfully written book with every single important concept being covered.
We can write cross dictionary triggers on DEX.DIC. I had tried this once, some years ago, and could not succeed. I never got a chance or requirement again that would push me beyond that limit. Looks like that chance is here and now.
And this is certainly the right time for me to reblog this point and the post itself.
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.
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.
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?
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.