On 11/1/07, paha <[EMAIL PROTECTED]> wrote:
>
> Hi, there is following code in provider (at least in the version i have, it's
> possibly not brand new but i updated it not so long ago)
>
> int rowsAffected = command.ExecuteNonQuery();
> if (rowsAffected == 0)
> {
>    throw new DBConcurrencyException("An attempt to execute an INSERT,
> UPDATE, or DELETE statement resulted in zero records affected.");
> }
>
> My question is  - why not filling DBConcurrencyException with the Row, that
> caused the error? There are some situations where i would prefer to have
> this Row returned by exception (e.g. show user the problem, get new values
> for this row and show them to user). For now a have to find it myself and re
> throw exception. It should not be big deal to add this code to provider, is
> it?
>
> throw new DBConcurrencyException("An attempt to execute an INSERT, UPDATE,
> or DELETE statement resulted in zero records affected.", null, new
> DataRow[]{row});

This may be not big problem to change. If there's no objection, I can do this.

> Or maybe there is some reason not to do so?
>
> One more little question, also about this Exceptions. What do you think
> about throwing localized messages? (I mean storing once (new
> DBConcurrencyException()).Message, (new DataException()).Message and so on
> somewhere in local dictionary, and using them instead of English string
> variables? IMHO it might be useful when you have

Why? Exception text should be help for developer. The error message
for user shoudl be handled on application side.

> DbDataAdapter.ContinueOnError set to true, you get Rows with RowError texts,
> but you cannot find out then, which exception this row raises. And one more
> :) (the last question) about it. If you have this
> DbDataAdapter.ContinueOnError = true, and the row has an error, is it
> defined by standard, that row should call AcceptChanges anyway, again IMHO
> it might be useful that erroneous rows preserve their RowVersions, so that
> the user can repeat action after error correction . If AcceptChanges is
> called, i don't know anymore, if a row was meant to be
> updated/inserted/deleted and cannot repeat operation.

Where did you find this?
So, if I understand this, if we have ContinueOnError = true and we're
throwing DBConcurrencyException, we should call AcceptChanges *and*
preserve RowState?

> If i say stupid things, please forgive me :)
>
>
> --
> View this message in context: 
> http://www.nabble.com/DBConcurrencyException-tf4731950.html#a13530573
> Sent from the firebird-net-provider mailing list archive at Nabble.com.
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Firebird-net-provider mailing list
> Firebird-net-provider@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
>


-- 
Jiri {x2} Cincura (Microsoft Student Partner)
http://blog.vyvojar.cz/jirka/ | http://www.ID3renamer.com

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

Reply via email to