I considered a similar solution to that, and in controlled
circumstances, it would probably work. It has two unfortunate
consequences though:
A) if the jdbc driver changes, you're out of luck and
B) if the user has different language settings, again, out of luck.
For me, those are very significant considerations, because this is for
an office app where I won't have complete control over the environment
and localization support for at least two languages (english and french)
is a requirement.
I'm really hoping that I can find a better idea than that, because while
it is probably possible for that to work ... well it just doesn't sit
right with me. I'd be willing and happy to contribute to the current
efforts to add error code support to the back end, but I don't really
know where to start and I'm not a terrific C programmer either way. Are
there any other solutions out there?
regards,
Derek
John Cavacas wrote:
>Anyway, with this framework and the JDBC part of it, you can implement
>that sort of solution. The JDBC framework has a custom
>SQLExceptionTranslator interface that you can implement for custom SQL
>exceptions. The author include a Oracle implementation of this class,
>and since Oracle supports error codes, the solution is very clean. My
>idea is to create a PostgreSQL implementation of this interface, but
>since there are no error codes in PostgreSQL, I was going to parse out
>strings... yep, problably not the fastest thing on the planet but I'm
>going to attempt it and see how it works out.
>
>
>
