SQLite2 source and errors

Every once in a while, I come across a SQLITE2 database that needs to be converted to SQLITE3 format.

Doing so is easy. You just dump out of SQLITE2, and import into SQLITE3, such as:

sqlite2 mysqlite2db.db .dump > sqlite2_mysqlite2db.dump

sqlite3 mysqlite3db.db < sqlite2_mysqlite2db.dump



One problem is though, SQLITE2 is often not available anymore through any of the standard Unix package management systems. So if you have a newer machine with an app that's utilizing a SQLITE2 database and you want to upgrade that app to a newer version that uses SQLITE3, it's tough to get SQLITE2 installed so you can do the conversion.

What I did is download the SQLITE2 source code from:

http://www.sqlite.org/sqlite-source-2_8_17.zip


Then I compiled. (Remove the tclsqlite.c file. It's not needed)

This is on Debian Linux, BTW.

gcc -o sqlite2 *.c


That worked and got me a sqlite2 executable. However, when I tried to use it on my SQLITE2 database, I got:

sqlite2: btree.c:702: sqliteBtreeOpen: Assertion `sizeof(ptr)==sizeof(char*)' failed.

Hmm...what the heck?

I didn't carefully read the error and instead quickly went to googling. However, I didn't find much in the way of help. However, it quickly struck me that this was a 64-bit problem. Aha! I had forgotten to compile the program with the 32-bit flag. No problem.

(On OSX the flag would be -arch i386)

gcc -m32 -o sqlite2 *.c


But that gave me:

/usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory


After a little googling on that, I discovered I needed to install the lib6c-dev-i386 package, since I was running on an AMD 64-bit system. I installed the package, recompiled and everything is working fine.

Doctors' payments

Does anyone else hate trying to pay their doctor as much as I do?

First, you can never figure out how much you owe them. Typically, a huge bill comes first. But you know you don't owe that much, since insurance is going to cover the majority.

So you wait for your next statement to see what you really owe. But now you're past-due. And woe be to you if you visit the doctor more than once in 30-days; you'll be lost in an impossible maze of charges and insurance reimbursements.

Ok, fine. My doctor sent me a "please pay now" notice, so I'm pretty sure this is what I actually owe. No problem. While I'm sitting here paying bills online, I'll just quickly go to their website and pay online.

Except that they don't accept online payment. Are you freaking kidding me? An industry that has massive trouble collecting payments does not provide a way for patients to pay online? Yep, that's right. Ninety-nine percent of doctors have no way for you to pay online.

I could pay with my regular online bill payment service. However, it seems like I have about 12 different accounts associated with the doctors we see. So it's awfully inconvenient to have 12 different payees in my payment service.

Fine. I'll call them. Oh wait - it's 11 pm and an industry which has trouble collecting payments only has its billing office open from 9-5 on weekdays.

Fine. I wait until tomorrow. I call the business office during their advertised hours and listen on hold for 20 minutes while the voice response system tells me my call is important. After 20 minutes, it routes me to a voice mail box. I leave a voice mail. Four hours later, after receiving no call back, I call again. 20 minutes later I leave another voice mail. Four hours later after no call back, I call again. Twenty minutes of repeated "your call is important to us" later, the system tries to transfer me to an operator, but it hangs up instead.

The business office is now closed for the day. To make a long story a little shorter, after two more attempts the next day, I finally get through and pay my bill over the phone with a debit card.

In short, absolutely unacceptable.

Yes, I realize I could just write a check, get a stamp, put it in the envelope and mail it. However, that's not the point. The point is, I want to pay my bill NOW. Online. And you're not letting me do it.

No wonder you have problems getting paid.

So, what's a Dogwatch?

Dogwatch:


1. Nautical. either of two two-hour watches, the first from 4 to 6 p.m., the latter from 6 to 8 p.m.

2. The complete failure of a developer to come up with a company name, thus having to revert to his Navy days for something - anything at all. (This definition obviously mine)

Yep. A while ago I was thinking about publishing some shareware, so I needed a company name for such individual projects, as opposed to the stuff I do with Mark 9 Systems, LLC (Targetware).

So in a fit of desperation, I came up with Dogwatch Software. Why? Well, I was in the Navy, the dogwatch is a Navy watch in the evening and I do most of my work at night. And with that massive effort and reasoning, I had a company name, and then decided not to finish the software products.

I've never been tremendously happy with the name, so I'm always open to suggestions. The best names are short and easily remembered. Bungie, Panic, Blizzard, Pangea, etc. But I haven't come up with any of those and I'm now several years into Dogwatch, so I'll stick with it until I think up something better.

So there you go, the very unremarkable history of the name.

The purpose for the blog is to catalog my independent projects, which at this point, primarily consists of XSquawkBox (http://www.xsquawkbox.net), the VATSIM client (http://vatsim.net) for X-plane.

Often I'll talk about the motivations for working on one feature versus another, particular difficulties I'm facing, or just other random facts and trivia.