getFoundSetUpdater difference between 4.1.6 and 5.1.4

Classic Servoy
1

Hi,

Has there been a change in the databaseManager.getFoundSetUpdater() between 4.1.6 and 5.1.4

As far as I understood the databaseManager.getFoundSetUpdater() executes an update query.

In 4.1.6 this update was done without a databaseManager.saveData(), but I just noticed that in 5.1.4 you must add the databaseManager.saveData() after the FoundSetUpdater.performUpdate().

Is that correct? Should there always be a databaseManager.saveData() after FoundSetUpdater.performUpdate(), or is it a bug introduced in 5.1.4? Or was it originally wrong in 4.1.6?

Martin

2

that depends on how the foundset updater is used…
We cant always just send an update statement (if for example tracking is enabled, see the docs for more info)
And if we dont do that we use records to set the value.
Normally this will also save that data. But maybe you have a situation that something cant be saved somehow at that time
And that record doesnt really stop editing…

3

Johan,

You gave in your reply the situation that is my case.
A difference between my 4.1.6 and my 5.1.4 environment (running the same sourcecode), is that in the 5.1.4 environment indeed the audit trail was enabled, which was not the case in the 4.1.6 environment.
I didn’t expect to find there the origin of my case, but I checked the Wiki pages and indeed it is mentioned:

Boolean performUpdate()

Do the actual update in the database, returns true if successful.
There are 3 types of possible use with the foundset updater

  1. update entire foundset, not possible when the table of the foundset has tracking enabled, will fall back to 3.
  2. update part of foundset, for example the first 4 row (starts with selected row)
  3. safely loop through foundset (starts with selected row)

Martin

4

I disabled tracking because this is not going well.

Records that should be updated, are not updated.
I’ll try to create a sample to reproduce this in a small solution.

Having a look at the documentation, I think I have to find the problem in the current selectedIndex of the foundset.

Do the actual update in the database, returns true if successful.
There are 3 types of possible use with the foundset updater

  1. update entire foundset, not possible when the table of the foundset has tracking enabled, will fall back to 3.
  2. update part of foundset, for example the first 4 row (starts with selected row)
  3. safely loop through foundset (starts with selected row)

Because I looped through the foundset and I wanted to update the complete foundset (set a status) independent of the selectedIndex. The selectedIndex is mostly the last record in my foundset.
And it looks like when tracking is on, the behavior is different (update depends on selectedIndex) compared to no tracking, where an update statement is generated.

I think that the selectedIndex should not have any impact on the FoundSetUpdater behavior, with or without tracking.
if an update should be done starting with a certain index, then there should be a method on the FoundSetUpdater to make this happen, not on the foundset itself
I see the foundset as a result of a selection and expect the FoundSetUpdater always update columns on the whole foundset.

Martin

5

if you use somehow the update per record then yes FoundsetUpdater uses the selected index
This is how it is designed and that will not change.

6

Hi Martin,

I discovered this behaviour with tracking enabled in 2009 and put it on the forum then and got same kind of response from Johan.

Disabling tracking is not an option for us so => no (performance) advantage with foundsetUpdater for us…

We don’t use it any more…

Regards,