web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Forums / Microsoft Dynamics GP (Archived) / VST : Table linked to ...
Microsoft Dynamics GP (Archived)

VST : Table linked to Scrolling Window?

(0) ShareShare
ReportReport
Posted on by Pablito 225

Hi :

I have previously used Modifier and VST to add a few enhancements to an existing 3rd party GP/Dexterity application. On one of their windows, I would simply like to be able to scan the entries available in a scrolling window control. I was under the impression that a scrolling window is linked to a single Table object in Dexterity. Though I thought I'd found the correct one (the form contains many tables), we've had a few occasions where the scanned table was empty despite the scrolling window clearly having contents. Is there any way to determine the Dexterity table bound to a scrolling window? Any suggestions as to how best to tackle this?

Cheers,

Paul

*This post is locked for comments

I have the same question (0)
  • Suggested answer
    MG-16101311-0 Profile Picture
    MG-16101311-0 26,225 on at

    If you open the form with Modifier, then double click on the scrolling window in question, you will see the Properties window. On the Object tab you will see the LinkedTable property.

    That said, it's probably a lot easier to simply make the changes directly to the table, then clear and refill the scrolling window.

  • Pablito Profile Picture
    Pablito 225 on at

    I thought the linked table would be listed under the Object tab, but it being greyed out made it inaccessible. It never occurred to me to double click the scrolling window control. Simple enough... thank you!

    So I've now confirmed that I am looking at the right table which means that I still can't explain the intermittent behaviour. Perhaps it is race condition whereby the table is cleared by the time I look at it. I'll have to think about this a bit more.

    I've not done Dexterity development, so I can't say I fully understand how the Dexterity table is linked to SQL. I assume it is simply tied to a view, stored procedure or table function in some way, but I don't suppose that without the 3rd party's source code, that I can determine this easily? Oh... can the contents of a Dexterity table simply be manually "built up" like any data structure? That would make things harder and would explain the DEXSQL.log's many small and seemingly repetitive calls to small utility-like stored procedures.

    Paul

  • Suggested answer
    MG-16101311-0 Profile Picture
    MG-16101311-0 26,225 on at

    Paul,

    All good questions.

    From a Dexterity standpoint, when you open that form, the runtime engine opens a table buffer (an area in memory) for each one of the associated tables on that form. When a record is read from the physical table, it is transferred to the table buffer, where you can execute any operations, before committing the table buffer back to the physical table. To access a form table buffer, you need to refer to that form in VST, as follows:

    TableError err;
err = Dynamics.Forms.SopEntry.Tables.SopLineWork.GetFirst();
do
{
    // do something with the table buffer
    if (Dynamics.Forms.SopEntry.Tables.SopLineWork.ItemDescription.IsEmpty)
    {
        Dynamics.Forms.SopEntry.Tables.SopLineWork.ItemDescription.Value = "Added by VST";
        err = Dynamics.Forms.SopEntry.Tables.SopLineWork.Save();
    }

    err = Dynamics.Forms.SopEntry.Tables.SopLineWork.GetNext();

}
while (err == TableError.NoError);


    Note that above I am even affecting a record within the context of the form table buffer, which of course, will make the changes physically. So to your point, the table buffer is a pseudo-data structure on it's own.

    The entries you see in the Dexsql log runtime engine calls to table auto-procedures. There's an auto-procedure per table operation (CRUD), per index, if the Dex developer has chosen to leave the default settings. When the runtime engine cannot find these, it actually translates sanScript table access syntax into pass-through SQL. As you can imagine, pass-through SQL is not compiled and would require the overhead of creating a query plan for it (although newer versions of SQL Server seem to have an answer to that), hence taking a performance hit. Stored procs are compiled and have a defined query plan.

  • Pablito Profile Picture
    Pablito 225 on at

    Thanks for the clarifications Mariano! This is all useful information.

    Indeed, I am accessing the table in roughly this manner though I have no current need to change its contents.

    I thought about it a bit further and can't see this being a race condition. My counting utility is invoked from a SaveButton.ClickBeforeOriginal
    handler so nothing should have been cleared at that point (as I am running before the save which does clear the form). That said, I have discovered something new today that is interestingly in the same area so I am wondering if the two could be related. I'll post that in a different thread to try and keep things a little cleaner.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Congratulations to the November Top 10 Community Leaders!

These are the community rock stars!

Leaderboard > 🔒一 Microsoft Dynamics GP (Archived)

#1
Community Member Profile Picture

Community Member 2

#2
mtabor Profile Picture

mtabor 1

#2
Victoria Yudin Profile Picture

Victoria Yudin 1

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans