Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    After upgrading to smartgwt13 we see issue with startEditingNew()

    In my application we have windows to create new/update records for some entities. Everything was working fine before 13 upgrade but now we see issues with thsi particular method startEditingNew() where it randomly adds the data to teh records. So our new window is supposed to create new records starting from 1 and update window should display existing records and we can also add new entries to existing data so it should update. But what we see for NEW there is DS fetch being called internally on calling startEditingNew() method to add new entries to window. We can surely say that its from gwt because I added loggers before and after this method call and I see the totalrecordscount mismatch. Snippet of code->LogHelper.log("new Record 7 : "+ skeletonLocationsGrid.getTotalRows());

    skeletonLocationsGrid.startEditingNew(defaultValues);

    LogHelper.log("new Record 8 : "+ skeletonLocationsGrid.getTotalRows());

    And here's the console output.
    Ideally teh count should become 1 but from somwhere its adding 1000 not sure from where. Could you please suggest if there is any alternate way to use this? Click image for larger version

Name:	2025-07-11 19_49_04-Clipboard.png
Views:	41
Size:	1.8 KB
ID:	276023

    #2
    This isn't much to go on - you may want to review the Debugging topic in order to understand the information you should supply in order to make it possible to help you.

    Also, make sure you're using the latest patched version of SmartGWT 13 (it's not clear whether you are on 13.0 or 13.1) and please always report the specific build date as well.

    But to take a guess - please confirm:

    1) you have a SmartGWT Window containing a ListGrid

    2) the ListGrid is databound but you do not fetch records, instead, you call startEditingNew() several times to allow users to add new records

    3) at some point in your startEditingNew() calls, you see a fetch against the DataSource, and listGrid.getTotalRows() changes to 1001

    If this is all correct, then:

    1) probably the 1000 is what you have configured for the resultSet.fetchSize

    2) something you're calling during this flow is making the ListGrid think it needs to do a server fetch

    To troubleshoot this, if you're unable to make the problem reproducible for us, consider enabling the "fetchTrace" log category at DEBUG level, or just setting a breakpoint in any method involved in a fetch (such as dataSource.transformRequest()) so you can see the stack trace and understand what method call is ultimately triggering the fetch.

    Comment


      #3
      Thanks for the reply. Adding the asked information-

      1) Smartgwt version details-
      Isomorphic-SmartClient-Package-Date: 2023-08-22
      Isomorphic-SmartClient-Version: 13.0p

      2) you have a SmartGWT Window containing a ListGrid ->Yes that is correct. It contains a ListGrid

      3) the ListGrid is databound but you do not fetch records, instead, you call startEditingNew() several times to allow users to add new records -> Certainly, we are not doing any fetch call and just calling startEditingNew() to allow users to add new records which can be called multiple times.

      Before upgrade we were on v11.1p_2018-03-17 and did not face this issue. We still have some env with older gwt version as mentioned and there is no issue there. We do not see any backend IDACall being triggered in older versions. Code wise nothing has changed so not sure from where this IDACall is being triggered after upgrade. We do not have any resultSet.fetchSize configured in our system. Please suggest if there is any alternate method we can use or any solution from gwt side?

      Comment


        #4
        Following up on this. It looks like you haven't taken the recommended troubleshooting steps and also have not provided a way to reproduce the problem, so we cannot do anything further yet.

        Note by the way that it is never enough to just say "the problem appeared on upgrade". The most common case of this is bad usage that was tolerated by an old version but doesn't work in the new version. But it's still bad usage.

        And obviously, there's still nothing we can do without a way to reproduce the problem.

        Comment

        Working...
        X