Positional DML statement longevity

[aafemt]

If a positional DML statement is prepared and then referenced cursor is closed and reopened, what should be the behavior of a following attempt to execute the prepared statement?

Should it throw an error?
Should it be executed ok if the new cursor is compatible with the old one (i.e. includes the same table)?

[asfernandes]

I believe you should always start saying what is the current behavior and if it was changed anytime, as the current/old behavior will always have importance on the decision if something already existing is wrong or correct.

[aafemt]

Current behavior is throwing error. I failed to locate positioned DML code in FB 2.1 sources so I cannot tell how it worked back then.

Because it is rather a question of design and UX, I would prefer to disregard current and past behaviors concentrating on the usability of the feature.

[dyemanov]

In the ideal world, I suppose it could be executed again without errors. The question is whether it's appropriate to move the cursor compatibility check from the prepare time to the execution time.

[hvlad]

Could it be in both places ?

[aafemt]

Sure it could. I've almost done it there. Routine mapCursorKey() instead of throwing error immediately can easily relink parent cursor if possible.