Skip to Content
Author's profile photo Mark Pe

Information: Controlling Complex Table Data and Delete queries to run in every transmit for Agentry

Are you a new designer or a season veteran in Agentry?

If yes, you probably started to learn how to create complex tables while attending the MOB-300 (Agentry Essentials) class.

The class is based on SQL examples on creating complex tables, fetches and transactions. If you are season veteran then you probably just need to get some refreshers on some known topics.

The purpose of a complex table is to store X amount of records in the mobile device that requires rapid searches for your mobile application to be used in your logic or transactions.

As a new mobile designer or season veteran, one of the stories or requirements that you may get from the company you are building the mobility solutions for is how to control the data that is downloaded to the mobile device.

The questions you may get are as follows:

  • Do you expect the mobility user to always get the most up to date records for each transmit?
  • Do you only need to download delta updates on each transmit?
  • Do you just get the records based on a fetch (on-demand)?
  • What if the user has 2 million records but is using a cellular network with low signals and the transmission is too long?

Some of those questions above may lead you to ask how to control data being loaded or deleted in Agentry and especially data in SQL backend due to overhead/cost of the transmit.

This blog will concentrate on SQL Backend and controlling the Complex Table Data and Delete Queries.

A Complex Table Data query is in charge of getting the data from the backend to store newly initialized data (rebuild) or updated data in the complex table while the Delete queries is in charge of removing the record from the complex table.

The first thing a new designer needs to know is that you need to setup a transmission type to connect the Agentry client to the Agentry Server. In this example, we are using the Angel connection. This transmit configuration setting is to setup most WiFi and LAN connection or default connection for transmission. In the picture below, the user is allowed to select or deselect the option to check for Complex Tables. It is mandatory to enable it to run the Data and Delete queries in every transmit unless you designed your application to be more strategic or tied to types of transmission (discussed below).


Why is this option available?

The Agentry software gives the user the control to enable when and when not to download the table data based on business rules. A perfect example of this is when the user is on the field and is using GPRS then to not allow the user to download multi-million rows of data until the user is using the LAN.  The expectation here is that the user has several settings available to be chosen as designed by the user/designer (ex: Angel, GPRS, WiFi and others). One technique a user can do to switch from one selection to another is during transmit to press cancel right away. This enables the drop down selection to be active so that the user can select which one to use (i.e. GPRS, WiFi and others) provided that you have more than 1 selection available (based on your design – seen under the transmit configuration tab).

What will happen if you turn off the option above (Check Complex Tables)?

Then you may want to look at this KB article that explains the expectation on what occurs (problems) and what options are available to you in the Agentry Editor. Table Data or Delete query does not run in every transmission – Agentry (you will need your S number to check it out and you may bookmark it). Check KBA symptoms as what is expected.

The article above is a good Knowledge Base Article (KBA) to learn what to setup if you are designing a complex table. You may click on the link and save it for reference as it will also explain what happens if you select the other Agentry options “Check Complex Tables and User Request: Allow user to check for table updates” like the picture below.


The 2 pictures above are available in the Agentry editor and it may affect other backend types but this blog concentrates on SQL backend.

The MOB-300 class will discussed creating the Data and Deleted queries in detail and the SAP Work Manager for Maximo product has real examples (if you have license for it you may download it for reference). I normally recommend to the customer to get one copy of the SAP Work Manager for Maximo if they are designing a SQL backend from scratch to get all reference or examples on how one can do a complex table, fetch, transaction and others. They can also attend the MOB-320 class (they will give you a copy and explain each component, properties, complex table and others in detail). The MOB-320 class is perfect for mobility designers who specialize in SQL or Oracle backend and Java type of application while the MOB-310 is perfect for Java and SAP backend.

Additional comments:

– The products designed under Agentry like Work Manager for SAP uses Java backend (it does not have Data or Delete query) and most of the control are in the SAP Agentry ConfigPanel (or JavaBE.ini for older versions of Work Manager).

– The products designed under Agentry like Work Manager for IBM Maximo uses SQL backend and this blog relates to it (it has Data or Delete Query).

To readers: If you like this type of information please do like and/or bookmark this article and all articles reference herein for us to validate its importance to the user community and for us to create more.


Mark Pe

AGS Senior Product Support Engineer

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Roopa M
      Roopa M

      Hi Mark,

      Very useful blog. Can we use this reload query concept in Work Manager which is dealing with the SAP back end.

      If so could you please suggest me the steps to be carried out.


      Author's profile photo Former Member
      Former Member

      The Reload Query shown here is only for the SQL backends.  There is a Reload Java Function already called "willRebuildTable".  This function is already being called by the SAPCommons file in the  If you want to change how it works then you will need to override the current function.

      Base Agentry Information.

      • willRebuildTable

        public boolean willRebuildTable() throws AgentryExceptionThis method is called by the Agentry server to determine whether the server should rebuild the client's complex table from scratch. If you return true from this method, then a subsequent call to dataIterator() should return the full set of complex table records and deleteIterator() should return nothing; if you return false from this method then dataIterator() and deleteIterator() should return incremental changes.

        Note that if the client's last data update date was invalid, then the Agentry Server will assume that the table needs to be reloaded and will not call this method at all.

        When the Agentry server calls this method, it will store the result of the call into the _rebuilding field. That field will also be initialized by the constructor to true if _clientLastDataUpdateTime is invalid or false if it is not, so that the field will contain the correct value even if the Agentry server does not call this method.

        The default implementation of this method returns the value of _rebuilding as set by the constructor.

        true if the client's table should be rebuilt from scratch, or false if the client's existing table should be updated.
        AgentryException - if an error occurs.
      Author's profile photo Mark Pe
      Mark Pe
      Blog Post Author


      This blog or case study specifies what occurs if the user/designer allows to check for complex table update from the Agentry editor. From the KBA article: 1978261 (above):


      • If the Check Complex Tables is set to Every Transmission and the option "User Request - Allow user to check for table updates" is enabled in the Agentry editor then the following occurs:
        • The first time the application is initiated, the data query is called. However, only when the user specifically selects "Check for Table Updates", the data and delete queries are launched in the next transmission only
        • After this transmission, the "Check for Table Updates" is automatically unselected and both queries will not be launched again in transmissions unless "Check for Table Updates" is selected in the mobile device again


      This is basically the control from the Agentry server side. Steve specified the control from the application side "Work Manager".

      In essence, you have the reload mechanism controlled in two places in Work Manager that works in series (like a water pipe - there are 2 valves. The first valve is from the Agentry side and the second valve is in the application side. If you turn on both valves then water will flow).

      There is an assumption that the user already pre-configured the Agentry side so the application side will utilize what Steve specified in the Java code.


      Mark Pe

      SAP Senior Support Engineer

      Author's profile photo Former Member
      Former Member


      Just wondering if there is an option to check for Complex table update every time the user logs in?



      Author's profile photo Mark Pe
      Mark Pe
      Blog Post Author


      Most of our application by design already has the check for complex table update every time the user clicks on the start/transmit button (which signals the backend that the user is online and ready to get fetches or pushes). By simply logging in to the client only enables the user to see the mobile apps.  The transmit button is key.

      Best Regards,