Database Error Logging

[ShaunR]

I briefly mentioned a logging API that I've been using for logging errors, warnings etc to a SQLite database in the NLog thread. Since it seemed to be of interest, I thought I'd knock together a demo so that peeps could see how I use it and demonstrate some of the features using database enables above and beyond boring old text file logs (it requires the SQLite API for Labview installed)

So here she is.....

If people approve and think it's useful, I will add it to the SQLite API for Labview as an example.

[jcarmody]

If people approve and think it's useful, I will add it to the SQLite API for Labview as an example.

I was hoping you would post this; it will be useful in my next project. Thanks.

[ShaunR]

I was hoping you would post this; it will be useful in my next project. Thanks.

Actually this is a slightly older one than I use currently. The latest one passes the errors via a queue to an asynchronous process that then writes the to DB but the main bulk of it is still the same.

[drjdpowell]

Hi Shaun,

Can you clarify the “fair use” of your database logger (and SQLite API)? I’d like to use it (or a modified version) as an error logger in custom software projects for clients.

— James

[ShaunR]

Hi Shaun,

Can you clarify the “fair use” of your database logger (and SQLite API)? I’d like to use it (or a modified version) as an error logger in custom software projects for clients.

— James

Well. The database logger is shipped, as an example, with the SQLite API now (so it is covered by the sqlite api license). But it's not a lot of good without the API. I suppose you could hack the api stuff out and use something else, but I think it would be a lot more complicated.

"Fair Use" is a bit moot since the SQLite API is distributed under a non-commercial share-alike license, so for evaluations, articles etc (where fair use is targeted) it is perfectly acceptable to use it under the current license.

[drjdpowell]

Well. The database logger is shipped, as an example, with the SQLite API now (so it is covered by the sqlite api license). But it's not a lot of good without the API. I suppose you could hack the api stuff out and use something else, but I think it would be a lot more complicated.

"Fair Use" is a bit moot since the SQLite API is distributed under a non-commercial share-alike license, so for evaluations, articles etc (where fair use is targeted) it is perfectly acceptable to use it under the current license.

Sorry, I know little about the terminology of licensing. At a consulting firm I’m doing some work for, they would like a reusable error/debug logger for use in their many projects. I suggested your logger. But, if I read it right, the SQLite API has to be licensed for each project (each “product”), which isn’t going to fly. My other options are a non-database solution, using Saphir’s SmartSQLVIEW, or calling the SQLite all directly with SQL statements. I actually prefer the last option (even though it will be much more limited and less polished than your stuff) as I can then use it as a logger in my message/actor framework without inheriting any licensing issues. Need to polish up my SQL, anyway.

[ShaunR]

but not fair use to use in commerical apps?

Examples of fair use include commentary, criticism, news reporting, research, teaching, library archiving and scholarship

Common misunderstandings

• Any use that seems fair is fair use. In the law, the term fair use has a specific meaning that only partly overlaps the plain-English meaning of the words. While judges have much leeway in deciding how to apply fair use guidelines, not every use that is commonly considered "fair" counts as fair use under the law.
  

Source.

[ShaunR]

Sorry, I know little about the terminology of licensing. At a consulting firm I’m doing some work for, they would like a reusable error/debug logger for use in their many projects. I suggested your logger. But, if I read it right, the SQLite API has to be licensed for each project (each “product”), which isn’t going to fly. My other options are a non-database solution, using Saphir’s SmartSQLVIEW, or calling the SQLite all directly with SQL statements. I actually prefer the last option (even though it will be much more limited and less polished than your stuff) as I can then use it as a logger in my message/actor framework without inheriting any licensing issues. Need to polish up my SQL, anyway.

Indeed. Your mileage will depend on what you want. The advantage of the license/waiver is that it's not a per-seat license (effectively a site-wide license) so you can have lots of developers and install it on as many machines as you like (for developing that product) as well as no new fees for updates (of the toolkit) or periodic payments. 100 developersx1 product = about $1200 for the lifetime of the SQLite API (free upgrades).

And lets not forget that if you are using it internally (e.g for your production line) it's completely free. I prefer to think of it that businesses that are interested in using it for monetising are supporting the development so that everone can benefit (after all, if you are selling product, the commercial cost is passed on, is it not?).

The other way you have to pay per developer and everytime a new release (of the toolkit) comes out. 100 developersx1 product= about $69,900 every time you want to upgrade.

It always strikes me as funny (as in ha, ha) that Labview people are prepared to pay tens of thousands of dollars every year to NI (basically just to get bug fixes) but balk at trivial costs for anything non-NI.

I'm not making huge amounts off of it. But if others are, shouldn't a little bit of that come my way?

At the end of the day, though. It depends on how much you value your time. For the amount of time I have spent on the API, I would have quoted considerably more if a customer wanted it. (the gochtya are the dlls )

Edited February 21, 2012 by ShaunR

[drjdpowell]

Ah, but 1 developer x many (small) projects that could use logging and it gets expensive. Anyway, it’s looking like we’re going with modifying a text-log system from another project. Boring.

I’ll keep your API in mind, though, for any large project where a SQLite database would be a prime feature, rather than just a nicer way of logging.

[ShaunR]

Ah, but 1 developer x many (small) projects that could use logging and it gets expensive.

Not if he gives them away free too

Edited February 21, 2012 by ShaunR