I am coding a new servoy app against a sybase db.
Our db model requires that major schema constraints (Relationships, keys, sequences, etc) are coded in the DB engine rather than Servoy.
This is fine in as much as servoy picks up this stuff when it loads the solution except that when a data-entry task fails in a form the user gets a generic “ApplicationException: Cannot save form data”.
Try and enter the same data using Sybase and you get a much more helpful sql error like “regimeid cannot be null”.
Why doesnt servoy pass the sql error through?
Access passes the sql error text through to the user which gives us some change of debugging the problem…“Cannot save form data” is completely useless
Using version 3.0.1-build 372.
Have I missed something or is this an oversight in the way servoy interacts with backend db engines?
Al.
Good idea but…
what if I am not in a method at the time?
I am talking about a vanilla form with a number of fields…if data entry into those fields fails due to a back-end database error…the user is only presented with a generic error…nothing that explains why the entry has failed.
Wouldnt it make sense for servoy to pass the error text through to the end user? Other front end databases do it (Access) and I know that the backend end db is sending the error string to servoy - so why doesnt servoy pass it on by default?
I see your point. But in my opinion it is not good interface design to present a secretary or whoever is using the system a “constraint violation” (or whatever the DB throws) either. So in those cases I would use a method to make sure everything goes right.
I know. But my point was that a DB error is not better. I wasn’t saying that cannot save form data was helpful. The best is to design the solution in a way where an error like that does not occur at all.
My point was: what is a normal user supposed to do if he either gets a “cannot save form data” or a “ORA-98765 constraint violation”? He will say your solution is buggy.
I think you need to setup your solution so that it is not possible to create violations of whatever kind. If you have for example a constraint on address that requires a customer number, then you shouldn’t have a form that allows a user to create an address directly. Because then, of course, if he doesn’t fill out the customer ID you have a problem. If an address is entered only through a relation from the customer record, there is no problem. The same for deletion. If you allow the user to choose “delete record” from the menu without doing something in a method, you can get violations easily. So you have to replace the default “delete record” by a method that will remove related data if necessary.
You can also use the new error capture node in Servoy 3.0. It will allow you to create a SINGLE method for all the errors (even ones from the backend database). You can then either handle the error, or report it to the user.
True, but what I didn’t know was that this would work outside a method. I need to play with this to find out how it works - I assumed it would be used within running methods, much like try/catch. So much to learn.
OK, now I understand. I’ve just discovered the setting in ‘Solution Settings’ that let’s me name a method to trigger when an error event occurs, and the application.setErrorCapture() developer function.
This is an excellent new feature. I can’t find much detail in the docs nor the forum. It would be helpful to have a How To on the topic.