referential Integrity

  

HI experts,

Anyone can explain me more on referential Integrity OR share any documents??

Hi Ritesh,

What do you mean? How is this OutSystems related?

Kilian Hekhuis wrote:

Hi Ritesh,

What do you mean? How is this OutSystems related?

referential Integrity is Delete rule:

1. Protect
2. Delete
3. Ignore

Pls correct me if I m wrong:
1. Protect rule will not allow deleting the record if there is any reference key
2. Delete rule will delete the record and reference key record as well
3. Ignore rule will ignore the reference key relation and delete the record.


Pls, let me know If I'm wrong.


Also, pls answer me, what is different between a server action finish with "End" and finish with destination "Current", how it will impact the preparation? 


Hi Ritesh,

You are right about the three delete rules. If Entity A has a foreign key relation to Entity B, and you try to delete a record from B:

  • with "Protect" an Exception occurs and neither record is deleted;
  • with "Delete" all records of Entity A that reference the record from B are also deleted, as well as the record from B, and;
  • with "Ignore" only record B is deleted, leaving A with an invalid reference.

Note that "Ignore" is the fastest, and "Delete" is the slowest one.

As for your second question, if I recall correctly: when ending a Screen Action (not a Server Action - Server Actions cannot end with a Screen!) with "End", if it was called via an Ajax Submit, that's that, nothing further happens. If it was called with a normal Submit, the screen is reloaded and the Preperation is called, but the IsLoadingScreen() system function will return False. The context of the screen and its widgets will remain intact. If you end with a Current Screen, that's the same as with any Screen, and the Preperation is also run but IsLoadingScreen() will return True. The context and the widgets will be cleared, as if you loaded it anew.

Kilian Hekhuis wrote:

Hi Ritesh,

You are right about the three delete rules. If Entity A has a foreign key relation to Entity B, and you try to delete a record from B:

  • with "Protect" an Exception occurs and neither record is deleted;
  • with "Delete" all records of Entity A that reference the record from B are also deleted, as well as the record from B, and;
  • with "Ignore" only record B is deleted, leaving A with an invalid reference.

Note that "Ignore" is the fastest, and "Delete" is the slowest one.

As for your second question, if I recall correctly: when ending a Screen Action (not a Server Action - Server Actions cannot end with a Screen!) with "End", if it was called via an Ajax Submit, that's that, nothing further happens. If it was called with a normal Submit, the screen is reloaded and the Preperation is called, but the IsLoadingScreen() system function will return False. The context of the screen and its widgets will remain intact. If you end with a Current Screen, that's the same as with any Screen, and the Preperation is also run but IsLoadingScreen() will return True. The context and the widgets will be cleared, as if you loaded it anew.

Thanks for your reply.

Can u pls clear one more doubt:

what's the difference between screen Action and server action?


Solution

Hi Ritesh,

A Screen Action lives "inside" a screen, visually and conceptually. You add it by selecting "Add Screen Action" from the context menu of a Screen:

Next, you'll have a Screen Action:

Screen Actions can only be called by Screen elements: Links, Buttons, On Notify of Web Blocks (unless you're doing Mobile, in which case Screen Actions can call each other).

Screen Actions have access to everything that's part of the Screen, the Screen's Variables, Input Parameters, Widgets. Since they operate in the context of the Screen, they can end in redirections to other Screens and Downloads.

Server Actions live on the Logic tab, below the "Server Actions" folder (they are called "Server Actions" since P10, when "Client Actions" were introduced for Mobile. Before that, they were just called "Actions"). They can be called from anywhere in an application, both from Screen Actions and Server Actions (and Client Actions on Mobile). If they are Functions, they can be called from any Expression, even those on a Web Screen. Since they needn't operator in the context of a Screen (they might be called by a Timer, for example), they can only end in an End or an Exception, but not in a redirect or a Download.

Solution