Finance | Project Operations, Human Resources, ...

Query::update_recordset Bug

(1) Share

Report

Posted on by Ludovico M.

Hello,

I'm trying to use Query::update_recordset, but I think I found a bug

Here is a sample job that I created.

If you run that in debug mode, you will see that the method InventTable.Update is always called, even if SkipDataMethods, Events and DatabaseLog are passed as TRUE. The execution revert to a 1 by 1 update operation, thus becoming really slow

If I use the update_recordset (not the class) the update method is not called and the execution is fast

Maybe this is a bug in the class?

internal final class TestUpdateRecordSet
{
    /// <summary>
    /// Class entry point. The system will call this method when a designated menu 
    /// is selected or when execution starts and this class is set as the startup class.
    /// </summary>
    /// <param name = "_args">The specified arguments.</param>
    public static void main(Args _args)
    {
        Query q = new Query();
        QueryBuildDataSource qbds = q.addDataSource(tableNum(InventTable));
        qbds.addRange(fieldNum(InventTable, ItemId)).value("020061253001");
              
        Map fieldMap = new Map(Types::String, Types::String);
        fieldMap.insert(fieldStr(InventTable, NetWeight), any2Str("105"));
        Query::update_recordset(fieldMap, q, true, true, true);
    }
}

I have the same question (0)

All responses (6)

Answers (0)

Sort by

Suggested answer

Anton Venter 20,946 Super User 2026 Season 1 on at

Like (0)

Report
Copy link

Link copied!

Probably not a bug and is functioning as designed with the idea of if you need a fast solution, you could use the update_recordset statement.

Was this reply helpful? Yes No
Ludovico M. 27 on at

Like (0)

Report
Copy link

Link copied!

Your answer make no sense to me

There are 3 parameters on the method Query::update_recordset(fieldMap, q, true, true, true); that are completely ignored and not doing what they should do.

If you need a fast solution and you have Query::update_recordset method, you should definitely be able to use it.

Was this reply helpful? Yes No
Layan Jwei 8,282 Super User 2026 Season 1 on at

Like (0)

Report
Copy link

Link copied!

Hi Ludovico,

Can you show us the code you did for update_recordset where the update wasn't called?

As far as I'm aware, if InventTable "update" method has some code in it, then there should be a fall back

Also you could check this link:
Maintain Fast SQL Operations | Microsoft Learn

Was this reply helpful? Yes No
Ludovico M. 27 on at

Like (0)

Report
Copy link

Link copied!
Hi Layan, sure, here is the code:

static void Job340(Args _args) { InventTable inventTable; inventTable.skipDataMethods(true); inventTable.skipDatabaseLog(true); inventTable.skipEvents(true); update_recordSet inventTable setting netWeight = 10; }

This do not call the update method.

If you comment the skip* methods, the update method will be called.

The same behaviour should apply to the Query::update_recordset method, but the 3 skip* parameters are ignored

Was this reply helpful? Yes No
Layan Jwei 8,282 Super User 2026 Season 1 on at

Like (0)

Report
Copy link

Link copied!

Hi Ludovico,

True, based on the link i put in my last reply, it says that we can prevent the fall back for the "update_recordset" if the update method had code, by using "Skip data methods".

So i would assume this link was only talking about the normal update_recordset and not the Query::update_recordset.
But I agree with you, that the query one should work since they added a parameter called "Skip data methods" -- maybe you should raise a ticket with Microsoft if you are sure it's not working OR just use update_recordset if it will still work with what you are trying to do.

Thanks,
Layan Jweihan
Please mark this answer as "Verified" if it solved your issue. In order to help others who will face a similar issue in the future

Was this reply helpful? Yes No
Anton Venter 20,946 Super User 2026 Season 1 on at

Like (0)

Report
Copy link

Link copied!

Ludovico,

Then it's a bug indeed. Sorry, I totally missed the fact that there is a skipDataUpdate parameter in the Query::update_recordset method.

Was this reply helpful? Yes No