Etienne Charland wrote:
>
> The point I'm trying to make is not about whether GUID gets stored as
> binary or text...
>
First, the exception being thrown here originates from deep within the .NET
Framework itself and indicates that the number of rows impacted by the query
did not match expectations (e.g. it did not impact 1 row when the primary
key
was used in the WHERE clause).
The reason the BinaryGUID connection string property matters in this context
is that the WHERE clause matching is heavily impacted by it. Similar issues
have been seen before, e.g.:
https://system.data.sqlite.org/index.html/tktview/4bbf851fa5
The "type" handling performed by System.Data.SQLite relies heavily on the
data
types declared for columns and the various connection properties. This
cannot
be helped as the SQLite core library itself does not have knowledge of the
vast
array of data types supported by ADO.NET.
For this specific case, the first step is to determine how these "GUIDs" are
actually being stored in the target database. If they are being stored with
TEXT affinity, then the BinaryGUID setting should be manually set to "false"
in
connection strings for the target database.
The next step is to enable logging of all prepared SQL, and possibly the
values
of bound parameters, to determine if the correct queries are being
generated.
In order to support doing this on a process-wide basis, the environment
variable
"DefaultFlags_SQLiteConnection" (new to 1.0.97.0) may be used, by setting it
to
a value of:
"LogAll" (without the quotes)
The diagnostic output, which should be sent to all registered trace
listeners,
may prove useful.
--
Joe Mistachkin
