DynamicsSubs

  Amigos, we all know the riches of XDS (eXtended Data Security) policies, and its vast shores of applicability. If you want to restirct data based on some preconditions, then, yes: XDS is the correct option for you. Suppose you have a requirement: you want to show the user-specific journal lines. I  have created Journal J1, J2, and J5, Tome has created J3, Harry has created J6. When I would logon, I should see only J1, J2 and J5. XDS could be a very solution for all such sitations. Generally these are the steps we follow for creating an XDS policy  a. Create a Query, start with a table for which you want to arrest the data, make it as a Constraint Table. b. Create an XDS policy, assign the created Query, to the policy XDS. Select the above primary table as the primary table for XDS. c. In the XDS policy, you can keep giving the tables' names which you want to arrest, one to the next. d. Select the ContextType as a 'RoleName', otherwise you can also select 'RoleProperty...

   Imagine a situation where you need to add controls to a form, on run time. You have a dynamic source, (example, a booking app, where user would keep on adding newer choices, and you need to bring them to your form as checkboxes -- there is no prefixed set of choices beforehand: it would vary), and you need to add controls to your form by looping through your datasource. A cool way of doing this is to use: Form build controls. For example, for the above situation, you can add FormBuildCheckBoxControl. Or if you need to fill in into a combobox control, you might use FormBuildComboBoxControl.    So what are FormBuild controls actually? For example, the FormBuildComboBoxControl class lets you create, read, update, and delete X++ code and metadata. It behaves as if you are still in designing the UI and can keep on changing the metdata of various controls, while  actually  you are running the code. How to add a FormBuild control: The following code shows that ...

  As a best practice issue, you might have seen this BP deviation warning: The number of fields in <SO_&_So_Table> is more than 18. Consider breaking down the fields into smaller number of fields . This is a standard BP check, that emphasizes to keep the number of fields in a table as low as possible. Factually, keeping the number of fields more than the breakeven of 18 is just not a BP issue, but could lead to various CRUD operations as well as a lot of unforeseen performance impacts (although in standard, you could see a lot many OOB tables that have violated this fact and have over 30+ fields. Standard has safely marked these tables with Cache lookup as: NOTINTTS -- although that might not be a good solution, always). I prefer the following arrangement: The parent table could be kept with a bare minimum number of fields' set, while all the necessary children tables could be mined with the differential number of fields. And make the children-to-parent table relation by ...

  Ever come across a situation where you needed to  a. Using a multi-threaded batch to import a journal header and lines, from a staging table. The table already contains the Journal Ids which you need to assign to the header and allocate the lines under that header. b. You need to continuously check after each line being imported, if the journal with the Id has been created. If not, it will create the header and create the lines under it;  If yes, it will directly create the lines for the header (Find or create). c. As you could rightly guess, this architecture has an inherent sluggishness associated with it -- each time you keep on checking if the header has been created or not, it does mean a lot of performance effects, as a consequence. Also as you can understand it's a multithreaded code, which means each thread has no direct relation with the other -- which does mean there is no way I can talk between the threads/pass on any information. SysGlobalCaches to...