Child pages
  • Errors & Warnings
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Current »

Servoy generates both designtime and runtime errors and warnings for things that should receive attention of the developer of the application.

 

Most warnings are self-explanatory, but some require some further explanation. This chapter provides that explanation

Runtime Errors & Warnings

 Update/insert failed, unexpected nr of records affected: expected 1, actual 0

This error indicates that an update or delete of a record failed.

When Servoy performs an update or delete on a record, it checks whether the database reports back that the record was actually updated or deleted. If the database reports that the update or delete did not take place, the Update/insert failed, unexpected nr of records affected: expected 1, actual 0 error is reported.

The database can report that the update or delete failed when based on the SQL executed on the database no record was found to update or delete. There could be different reasons for the database not being able to locate the record to update or delete, some of which are explained below.

One scenario that may result in this error is when records are created that do not match the active filters: when a record is deleted or updated in the database the active filter conditions (FoundSet filters and table filters) are added to the generated sql. If the conditions are not met, the update will not happen and Servoy throws this exception. For example, a table filter 'tenant_id = 4' is active and a new customer record is created with null value for the tenant_id. This record can be saved in the database, but a consecutive update or delete will fail (update customers set name = ? where id = ? and tenant_id = 4).

Another scenario that may cause this error to be raised is when the record modified/deleted outside Servoy and Servoy is not notified. For example, an orders record is deleted from outside of Servoy while it is loaded in a Servoy Client and that Servoy Client then attempt to delete it. That delete fails with the above error because the database reports that delete from Servoy did not occur, because the record didn't exist.

By default the Servoy Application Server will raise this exception when such scenario occurs. It is possible to suppress these errors by setting the server property servoy.server.throwErrorOnUnexpectedUpdateCount to false. However, this should be used with care and only as a temporary solution until the underlying problem has been discovered and fixed.

 \{xxx\} was accessed while not fully created yet, check for scope variables recursively referring to each other, scope stack:[\{xxx\}]

This warning indicates that a scope is being accessed through scripting while it is still being initialized.

Scopes in Servoy are lazy loading, which means that they are only instantiated when they are first accessed. While they are initialized, first all functions are added to the scope and then, in order as they appear in the source file all variables are added to the scope. Note that this order in which things get initialized is standard JavaScript behavior.

The warning occurs when the value of one of the scope variables of the scope that is being initialized (scope A) is referencing another scope (scope B), which in turn has a variable who's value references back the first scope (scope A). At this point, the warning will be generated, because scope A is being accessed again due to the initialization of a scope variable in scope B, while scope A is still being initialized.

Such a circular reference where a value of a scope variable of scope A references a scope B which in turn has a scope variable that references scope A again can result in odd runtime errors, as the variable in scope B might access a property of scope A that is not yet available. This is the reason why the warning is raised.

The way to have the warning not appear is to change the structure of the code in such a way that there are no circular references between scopes in the values of scope variables

 

 

  • No labels