Ok, back to the drawing board. I thought maybe the problem had to do with incompatible versions of WordPress. So I upgraded the old blog (even though I was maybe risking the data since I did not have a proper backup) and the test blog to see if I could do a restore. Same SQL bug message.
Then I started thinking that the plug-in I was using for creating my backups may be the problem. I went back to WordPress.org for instructions on how to do a direct backup of the mySQL database without using a plug-in. This time I did a restore and I got about a third of my data back. (I got back only three of the ten tables... not good.)
Feeling I was getting closer, I went to the documentation from my webhost and found that their directions on how to to make a backup copy of a mySQL database differed a bit from those given here on WordPress.org. (The phpMyAdmin looks a bit different, too. Maybe an older version?)
Bingo! This time when I did a restore all the tables came back. I checked the table called wp-posts by clicking "browse." I could see a row for every blog post. When I clicked "edit" on one of the rows I could see the full html for the entire post in one of the fields, although it was quite a small field and I had to do a bit of scrolling. I can do the same thing for wp-comments.
This satisfies me that I have a proper backup of my data.
My recommendation is that when you use a plug-in for your backups you check (at least once!) that you are getting a usable backup by restoring it to a test blog like I did.
I do not know if I will hunt down another plug-in to do backups or if I shall stick with the direct method that I used for creating a backup of the mySQL database. It doesn't seem so hard now that I have done it once.
I hope this helps someone else. I don't spend a great deal of time here in the support forum, but I am amazed that a search did not turn up any similar question from anyone else. After all, WordPress said that verifying the backup is "the most important step in the upgrade process!"