Maximum number of recursive SQL levels during api_datasource.setcurrentrow

Question

Hi,

i try to write a procedure to prevent the user leaving a master row when details have been changed and should be committed first.

For example: the user is in master row 3, clicks on the details, makes a change and then clicks in master row 4. I want an alert with a message to save changes first and stay in master row 3.

I have created an alert for this, named askCommitFirst.

And the procedure does something like this:

if api_datasource.isdmlnecessary('DS_DETAIL') = 'Y'
then
  l_rowid := api_datasource.getpreviouscurrentrowid('DS_MASTER');
  api_alert.show('askCommitFirst');
  api_datasource.setcurrentrow('TM_CUT_SERIES_CUT',l_rowid);  
else
  query_details_for_selected_master_row.
end if;

This leads to this error message:

ERROR : 27-01-2017 17:17:59 DS_MASTER ( DBObjectAccess ) : blablabla => ORA-00036: maximum number of recursive SQL levels (50) exceeded

When i erase the api_datasource.setcurrentrow part, i get this error message:

System message: Event data is invalid. Your last request is ignored.

This error seems logical to me, because the user wants to go to master row 4 which is not allowed and he should go back to row 3.

Any hint to solve this and make sure that the user stays in de master row?

Kind regards, Jan Willem

Answer 1

0	THE SOLUTION for this kind of problems is a VALIDATE_RECORD event at datasource level. A VALIDATE_FIELD event would be a nice addition too. And the Formspider team says .... link answered 16 Feb, 08:04 brg 11●1●4 accept rate: 0%

Answer 2

0

Hi Jan Willem,

I was able to replicate this issue. There is a known bug in Alerts that is causing this behavior. If you temporarily replace the alert with a call to api_application.showpopupMessage you should be OK.

We'll fix this issue in the next release.

Kind Regards,
Yalim

link

answered 20 Feb, 20:06

formspider ♦♦
138●2●10
accept rate: 22%

To be clear, I don't get the same error you get, but I get an error as well. But the call to showpopupmessage resolves the issue in my case, and I suspect it will solve it for you too.

(20 Feb, 20:07) formspider ♦♦

Answer 3

Hi Yalim, good to hear that you can reproduce this :)

I guess it makes a difference which actions are called. In our case there is an action on the datasource when the user navigates to another row AND there is also an action on-focus of the record to display record X from Y. Probably when we should merge these actions, the error message would be the same.

With alerts the users can choose between commit or rollback and then immediately proceed with the action. With the showpopupmessage i can only show a message and stop processing. So that's less user friendly.

I can remember someone else also asked a question about committing details when navigating to another parent, but can not find it anymore. It would probably be more logical if it would be possible to commit changes in details of multiple parents. So instead of only querying details, the application should store the other details somewhere. Don't know if it is possible... Guess it's very complex to do, escpecially when there are many detail panels. I think it would be better so save changes automatically as much as possible.

Answer 4

0

Hi Jan Willem,

I think I have a workaround. I built a custom dialog and showed this custom dialog instead of showing an alert object. I did not run into any issues. It all seemed to work.

Would this workaround work for you? You can put as many buttons to this custom dialog as you want.

Hope this helps.

Kind Regards,
Yalim

link

answered 01 Mar, 16:45

formspider ♦♦
138●2●10
accept rate: 22%

Answer 5

Hi Yalim,

indeed a custom dialog would be a work-around :). But is that what we want?

I still think we need to make a fundamental decision about what to do with the "logical units of work".

Users do not think in terms like master-detail. They just want to enter some data and then save their work all at once. The reason we are having this discussion is that master-detail screens always lead to this unlogical commit in the middle of logical units of work. In other words: what we really should do is keep the details alive and not-committed until the user clicks commit.

Or perhaps it is better to save every change automatically. In our app (built with Formspider Mobile) there is no save button at all.

I do not yet know what to do...

Kind regards, Jan Willem

Maximum number of recursive SQL levels during api_datasource.setcurrentrow

Follow this question

Related questions