ansaurus

Question

Providing reliable user feedback with SQLite

Answer 1

+1 A:

If I understand correctly you are doing a GUI application that modifies information in a SQLite db.

Not really, you might get SQLITE_BUSY if you have threads; SQLITE_INTERNAL; etc. Check SQLite documentation. Instead of asking for SQLITE_ERROR you could do something like:

SQLITE_OK or SQLITE_DONE depending on what you are doing.

if (ret != SQLITE_OK || ret != SQLITE_DONE)
    //then this is an error.

Don't know in what language are you coding, but I did an abstraction of SQLite in C here. You might find it interesting.
Use sqlite3_trace()

Macarse 2009-06-18 07:42:40

Indeed, anything but OK and DONE would be an error, but are there errors that checking the return values rigorously would miss?Your ADT is most elegant, thank you for the link! I am in fact working in C, reading this code will likely point out many details I've missed.

Kim Reece 2009-06-18 07:48:41

Indeed, anything but OK and DONE would be an error, but are there errors that checking the return values rigorously would miss? => Don't think so. What do you have in mind?About the ADT: Sorry the homepage is in spanish, ask if you need help. np!

Macarse 2009-06-18 07:55:41

Between babelfish and linguistic similarities, I can handle the Spanish text, but thanks for the consideration all the same! (At least it wasn't in Japanese, that would have been a deep challenge.)I have a naturally suspicious mind - trusting that a value got where it was going makes me nervous. Didn't have any particular scenario at hand, though Theo's answer below reminded me that triggers inside the DB can alter what actually ends up happening, which might in theory under a horribly twisted DB design lead to content that wasn't exactly what was submitted. I'd want an accurate display.

Kim Reece 2009-06-18 08:02:26

Try sqlite3_trace(). It might have what you want.

Macarse 2009-06-18 08:14:29

Alas, sqlite3_trace() is per connection, just like the rest of the callback hooks. My third question will not benefit from it, and I don't see any impact it could have on the first two. A good try though.

Kim Reece 2009-06-18 08:20:29

Answer 2

A:

Besides exception handling... You should reselect the data from the db that the user did commit by clicking on the save button. That way you know for sure that the user sees the right data.

Theo 2009-06-18 07:51:02

I like this idea - it's a far easier structure than having the DB use callback hooks whenever something is modified, and I can't think of any hideously convoluted situations that would break it. (Aside, of course, from multiple clients, which I expect I can resolve through polling at worst.)

Kim Reece 2009-06-18 08:23:12

Accepting this one because, while I'm not certain it's necessary, I'm convinced that it's sufficient.

Kim Reece 2009-06-19 08:52:31

ansaurus

tags:

views:

answers:

Providing reliable user feedback with SQLite

related questions