so far i don't see any easy way to do this. i only see this possible by plugging my own Event objects.
basically extending each Event object (insert/delete/update) and then implement my own processEvent() function to catch SQLExceptions and then adding my own errors to be used with the xmlErrors tag.
is this true? or is there an easier/better way?
woodchuck
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I remenber....
SQLErrors are catched stored in an errors vector. This vector is stored in the pagecontext and is retrieved by the errors tag.
Here it's tried to translate from the resource bundles.
You can write your own error tag for this purporse. (I did so to show all errors in an message box).
The problem with the sql error text is that it's very, very database dependend an can't be parsed really. There are some tries to do so with the xmlErrors tag - but this works only for oracle. Oracle returns a formatted string with an error number.
The other db's returns clear text mostly together with table and index names wich can't be parsed.
I use interbase and have the same problem. My solution is to show the database text.
Hope that helps,
Henner
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thx for the suggestion. i never thought about making my own errors tag before.
you're right, the problem with making my own errors tag is parsing.
in a way, overriding the Event objects, in my case the DeleteEvent, with my own Event object and just catching *all* SQLExceptions specifically when calling doDelete() and then just returning the same custom error message whenever this happens (ie. no parsing) is easier. the only drawback is that i am assuming all SQLExceptions thrown is going to be the "child record exists constraint" error (ie. no cascade delete setup in database). in such cases, i would return to the user with something like "sorry, cannot delete selected record because dependent child record(s) already exists".
do you think this is a bad idea? i believe most of the time my assumption should be correct. however, if in fact the SQLException is caused by some other reason (like database not working), i will still return the same error message even though it is not the case...
i also thought about writing Interceptors and implementing the preDelete() function to check if there are child records existing. i could do something like "select 1 from employee where dept_no = ?" if i am deleting a record from the department table. but some of my parent tables have many child table dependencies. if there are 30 dependent tables, i don't want to execute 30 of such statements just to check if the parent record is deletable.... right?
do you have any suggestions on handling this situation?
thanks in advance!
woodchuck
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Easier would be your own error object. All sql errors - which you could parse - could get to the "sorry, cannot delete selected record because dependent child record(s) already exists" text.
On the other hand you can use the event mechanism to inject your own delete event. This could be an decedant from the default one with error handling.
Both possible. Second is trickier to configure but with less programming.
Henner
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hihi,
is it possible to intercept the various SQLException thrown by the Event objects?
for example, i want to return custom error messages back to the user instead of the raw database errors..
what is the best way to accomplish this in DbForms?
thanks in advance,
woodchuck
so far i don't see any easy way to do this. i only see this possible by plugging my own Event objects.
basically extending each Event object (insert/delete/update) and then implement my own processEvent() function to catch SQLExceptions and then adding my own errors to be used with the xmlErrors tag.
is this true? or is there an easier/better way?
woodchuck
There must be an easier way. No idea yet and no time to think about.... Please be patient up to the weekend!
Henner
I remenber....
SQLErrors are catched stored in an errors vector. This vector is stored in the pagecontext and is retrieved by the errors tag.
Here it's tried to translate from the resource bundles.
You can write your own error tag for this purporse. (I did so to show all errors in an message box).
The problem with the sql error text is that it's very, very database dependend an can't be parsed really. There are some tries to do so with the xmlErrors tag - but this works only for oracle. Oracle returns a formatted string with an error number.
The other db's returns clear text mostly together with table and index names wich can't be parsed.
I use interbase and have the same problem. My solution is to show the database text.
Hope that helps,
Henner
hi Henner,
thx for the suggestion. i never thought about making my own errors tag before.
you're right, the problem with making my own errors tag is parsing.
in a way, overriding the Event objects, in my case the DeleteEvent, with my own Event object and just catching *all* SQLExceptions specifically when calling doDelete() and then just returning the same custom error message whenever this happens (ie. no parsing) is easier. the only drawback is that i am assuming all SQLExceptions thrown is going to be the "child record exists constraint" error (ie. no cascade delete setup in database). in such cases, i would return to the user with something like "sorry, cannot delete selected record because dependent child record(s) already exists".
do you think this is a bad idea? i believe most of the time my assumption should be correct. however, if in fact the SQLException is caused by some other reason (like database not working), i will still return the same error message even though it is not the case...
i also thought about writing Interceptors and implementing the preDelete() function to check if there are child records existing. i could do something like "select 1 from employee where dept_no = ?" if i am deleting a record from the department table. but some of my parent tables have many child table dependencies. if there are 30 dependent tables, i don't want to execute 30 of such statements just to check if the parent record is deletable.... right?
do you have any suggestions on handling this situation?
thanks in advance!
woodchuck
Easier would be your own error object. All sql errors - which you could parse - could get to the "sorry, cannot delete selected record because dependent child record(s) already exists" text.
On the other hand you can use the event mechanism to inject your own delete event. This could be an decedant from the default one with error handling.
Both possible. Second is trickier to configure but with less programming.
Henner
thanks a lot, Henner!
woodchuck