Well, yeah, I was hoping to get it out of a succession of queries. SQLite's API is hidden behind a wrapper, and most of it is masked out, so getting access to the API is problematic. Unfortunately, the semantics of the return code on that API call mean that the execute took place, not necessarily that the execute statement succeeded (I have no idea why), so I can't look at the return to determine if a change occurred.
I have found change_count in func.c; when testing that using sqlite.exe, if I do an Insert, and then write a 'changes' select, I get 0 changes. However, when I do the insert and select as a single statement (that is, I hit enter only once, not twice), I get back changes = 1, which is what I need for now. I assume that for SQLite3, instead of change_count, I should use 'changes'? --Keith On Thu, 6 Jan 2005 14:30:06 -0500 (EST), Clay Dowling <[EMAIL PROTECTED]> wrote: > > Keith Herold said: > > I know I can recover the last_insert_rowid() in SQLite in the SQL > > query itself; is there an equivalant SQL function to sqlite_changes or > > sqlite_last_statement_changes (from 2.8.15)? If, for example, an > > insert doesn't take place, I get the last id of the insert *before* > > this one. What I would really like is to be able to determine whether > > the last insert actually inserted something or not, but from within > > the SQL query. > > You can check the result code of your API function call to see if the > query succeeded or not. A failed call means that it didn't do the insert. > SQLITE_DONE or SQLITE_OK means that your insert happened and the > last_insert_id() result is your new id. > > Clay > > -- > Lazarus Notes from Lazarus Internet Development > http://www.lazarusid.com/notes/ > Articles, Reviews and Commentary on web development > -- ****************************************************** - Ever notice how 'big' isn't, compared to 'small'? - Sounds like a Wookie; acts like mad cow. - I'm not a professional; I just get paid to do this. - Rules for programming: 1. Get it working, right? 2. Get it working right. - Things I've learned about multithreaded programming: 123... PPArrvooottieedcc ttm ueelvvteeirrtyyhtt rhheiianndgge dwi hnpi rctohhg eri aslm omscitanalgt iowcbh,je engceltvo ebwrah lip,co hso srci abonlt ehb .ee^Nr waicscee snsoetd 'aotb jtehcet -slaomcea lt'il m^Ne from two or more threads ******************************************************
