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:
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.
Mariano’s latest post explains how to add more comment lines to POP Purchase Order report. The idea is to split the comment text into 80 characters sized fields and then displaying it on separate report sections. I leave you here so you could refer to this awesome piece of post from Mariano. It’s a step-by-step guide on how to do this.
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.
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.