[R-sig-DB] Add a "dbSendUpdate" function to DBI?

[Paul Gilbert]

On 09/05/2014 11:39 AM, MacQueen, Don wrote:
> Speaking as an end-user, not a package developer, I think that for
> consistency with current behavior of the functions I frequently use (see
> one of Denis Mukhin¹s emails early in this thread), I¹d prefer that this
> new function throw an error when the DB throws an error. Admittedly, I
> don¹t have a deep understanding of the issues involved.

I think it would generally be the case that an end user would like 
their queries to throw errors as reported by the database. But for a 
programming API one might like a bit finer control. For example, in the 
case of an error in the SQL statement it can be useful if the database 
error is reported (from dbGetException()), and also some details about 
objects used by the function to construct the query are reported. In the 
case of an expired con a stop() from the DBI function can be passed 
directly to the user and the extra information, which would just hide 
the real error message, can be skipped. Admittedly, it is difficult to 
know where the distinction should be between FALSE and stop(). But the 
difference between an end users' needs and the needs of a programming 
API is really the reason I think there is a need for two sets of programs.

I personally think of DBI as defining the programming API, and packages 
like RMySQl, RSQLite, etc, implementing the programming API but, in 
fact, these are being used by end users directly to submit queries and 
write batch scripts, so there are two sets of needs. But as I've said 
before, in the end I can work with it either way.

Paul
>
> If within a script I send an SQL statement to the DB in which, for
> example, I refer to a nonexistent table, the DB reports that as an error.
> It makes sense to me that the R function would do the same, which
> immediately stops my script. It¹s telling me I¹ve got an error that *must*
> be fixed. I would prefer being stopped, rather than having to test
> (perhaps that¹s being lazy on my part, but the Œerror¹ behavior is more
> protective).
>
> -Don
>