Hi,

> I really do not care about the count. Although checking the count
> is the only way I know of at the moment to verify that my trans
> succeeded or failed.

The highlevel description of the executeUpdate("INSERT ....") would
be like this:

- "Hi, I'm client 123, TxID 234";
- "Hi, server 345 at your service";
- "Please, insert me row into table T1 with values V1, V2, V3";
- "Done.";
- "How many rows you inserted?";
- "1, as it was requested.";
- "Thanks a lot!";
- "You're wellcome";

As you see, you can remove part of conversation asking the number of
rows inserted.

If something goes wrong with server (server died, network died, etc.)
conversation would be:

- "Hi, I'm client 123, TxID 234";
- "Hi, server 345 at your service";
- "Please, insert me row into table T1 with values V1, V2, V3";
- <timeout/exception>
- "HELP, server died", throw an SQLException.

> > However, what is better - integrity constraints on
> > the server or update count on the client?
> What do you mean, I have integrity constraints like not null, and
> other checks. What else do I need on the server side.
>
> I just need to know on the client side, not the server side.

If your integrity constraints do not allow incorrect database state,
you're on the safe side. No client can make any modification that
will bring database into incorrect state. So, client simply inserts,
updates, deletes and relies on the server to handle this correctly.

> > Is it good? I doubt...
> Are you saying it's not good to use the built in features. Or not
> good to not?

It is definitelly good to use built in features. Yes, you will need a
DBA for each database server you have (Oracle, DB2, MS SQL, Firebird,
PostgreSQL, etc.). But you will be surprised how can you boost the
performance of your application.

Best regards,
Roman Rokytskyy