> It occurs to me that if you expect the insert to normally
> succeed, you could start by trying the insert, if it fails
> you can investigate further with the count(*) query to
> see if the problem is the existing row. This would be
> one access for success, 2 for failure instead of 1+
> for failure and 2 for success (Even if the key is missing,
> the insert might fail for other reasons.. maybe a unique
> index).
I support this idea. Some time before I've used the same
technique for the small datawarehouse, it worked perfectly.
> Another possibility (presumably for the future) would be
> to have JAWS customizable with a plugin/database
> vendor and recognize their error messages.
That would be great. I've tried to customize the JAWS jdbc
command object, but left that idea because of complexities:
The reason is the inheritence of all JDBC<command>. Usually
one need to change only JDBCCommand in order to customize
it to the database, but then you're not able to tell all
other commands to use new one.
I suggest that we define the abstract class that can takes
JDBCCommand as constructor parameter and then invokes all
methods on the passed JDBCCommand. All concrete commands
should be inherited from that abstract class. It seems to
me that in this case we will be able to customize JAWS
for different databases easily.
Regards,
Roman
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
