Hi Shane, On Wed, 31 Jan 2007 09:29:24 -0500, you wrote:
>On 1/31/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> "Shane Harrelson" <[EMAIL PROTECTED]> wrote: >> > when i try to insert a row into a table that has a UNIQUE constraint >> > on a column, and I get the SQLITE_CONSTRAINT result code because i'm >> > inserting a duplicate value, is there anyway to determine the rowid of >> > the conflict? >> > >> > looking at the internals of the VDBE, i found that the rowid of the >> > conflicting row is pushed on top of the VDBE stack. >> > >> > if i'm willing to violate the interface, i can dereference the rowid >> > from the internals of the VDBE struct. i'd rather not do this... is >> > there a more formal mechanism for getting this value without having do >> > to do a separate "select" query? something like >> > sqlite3_last_insert_rowid() -- ie. sqlite3_last_conflict_rowid()? >> > >> >> The official way to find the conflicting entry is to do a query. >> >> SELECT rowid FROM table WHERE uniquecolumn=?; >> >> -- >> D. Richard Hipp <[EMAIL PROTECTED]> >> > >Thank you for the reply. I assumed this was most likely the case, and >as I said in my original email, I was hoping to avoid having to do a >seperate select query for the sake of speed... especially since the >value I needed was so tantalizing close in the VDBE struct. The SELECT will be quite fast, chances are the required pages of the unique index will still be in the cache. In my opinion it is always better to write portable code, so I would prefer to rely on generic SQL than on yet another implementation specific API. Just my 2 cents. -- ( Kees Nuyt ) c[_] ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
