OK, I admit it. My Yahoo screen name is Btrieve2000, perhaps tipping you off that I am a reformed Btrieve database developer. Starting in the mid 1980s, I started working with Btrieve at Posse Inc., a company developing back-office software for retailers. Posse was located in Texas, and in part due to its proximity to SoftCraft, the original developers of Btrieve, Posse was one of SoftCraft’s first customers.

Btrieve was a fairly primitive record manager, rather than a real database system, but at the time it enabled me to reliably store information even though the machines and media on which I needed to record were not terribly reliable. Say what you will, but I had systems running in rock quarries, areas notorious for power failures and lightning strikes, and very rarely did I lose any data.

Long before I met Jim Kyle, he was an icon in the computer programming world. Jim has been publishing articles related to computers and electronics since at least the early 1960s. While he has outlived many of the magazines he wrote for and seems not to write as much as he used to, he is still running a thriving consulting business helping folks repair their Btrieve/Pervasive SQL data files. If you read my recent article called “The Value of Experienced Coders,” you’ll know why Jim is my hero.

Years ago I proposed a book on Btrieve to Addison-Wesley. While the publishing company turned down this idea and I eventually did another book for them, Jim wrote Btrieve Complete, the definitive work on Btrieve, at least through version 6.15.

I did some technical editing on that book and had the pleasure to meet Jim in person at one of the Pervasive Developers Conferences when we were both writing for Btrieve Developer’s Journal (formerly Pervasive Developer’s Journal and now long gone). While I was always impressed with Jim’s writing, including such works as Undocumented DOS, Network Interrupts and PC Interrupts, I am even more impressed with Jim himself. He is one of the most unassuming men I have ever met, yet he has amassed an amazing body of work.

The following questions were asked and answered via email.

 

Doug: You did a lot of early work on electronics, radio and photography. What got you interested in computers?

 

Jim: I went to work for General Electric in July 1965 as a technical writer, hired to do the service manual for the first raster-based video display terminal. Toward the end of that year, my manager and I were shooting the breeze when he observed that we would be out of work in 10 years or so since computers would take over the job of writing. I responded, “In that case, we’ll be the ones to teach them how, so we’ll still have jobs when they replace us.”

I was simply making a smart remark, but he took me seriously and replied, “Great idea. Do it!” He followed through by getting me a terminal and letting me learn to work with the GE in-house time-share system, via a 110-baud telephone connection from Oklahoma City to Phoenix. From that point on I was hooked.

 

Doug: After the low-level DOS programming you were interested in, how did you end up working with Btrieve?

 

Jim: After 24 years in the Oklahoma City plant working for GE, then Honeywell, Control Data/MPI and BancTec, I was laid off in February 1990. By then I had resumed writing, which I had stopped during the 1980s, and was also doing some freelance software development. My major client at the time was Norick Software Inc., and the company had been urging me to quit BancTec and go with them full-time.

When I got the pink slip, I picked up the phone and called Norick. The next Monday I started there at a significant boost in pay! Their systems were built on Btrieve, but I was new to databases and knew only xBase/Clipper. It took me a while to learn to love Btrieve.

 

Doug: Did you work with any other database systems? Have you done anything with Pervasive SQL or some other SQL dialect?

 

Jim: As I said, I worked with Clipper while at BancTec, but I was not deeply into database work at that point. When I had to learn Btrieve, I went looking for a book that would tell me what I wanted to know about it and discovered that none existed. That was the start of my effort to do Btrieve Complete. In the meantime, I kept up with the world of undocumented DOS, and the success of the books on that subject helped convince both Addison-Wesley and Doug Woodward, Btrieve’s original author and CTO of Btrieve Technologies Inc. (BTI) in 1995, that a book on Btrieve would be a good project. [Editor’s note: BTI became Pervasive Software Inc. in 1996.]

Since that time I’ve tried to keep current with all the Pervasive SQL releases, and I’ve done some work using Microsoft Access’ version of SQL, but the majority of my activity is still at the binary level with Btrieve-format files.

 

Doug: There have been a number of blog posts, even petitions, to bring back official Microsoft support for VB6. As I recall, you did some VB work. Do you have any thoughts on the matter?

 

Jim: My data recovery utility is written in VB5, which in 1998 was the simplest way for me to port the original C program into the 32-bit environment. The long-standing problems of incompatibility between DLLs and VB controls have driven me away from VB, though, and my newer programs are all done using Delphi. Until recently I used Delphi 3, but have now upgraded to Delphi 5. As you can see, I don’t subscribe to the “newer is better” philosophy; if a tool does what I need, I tend to stick with it indefinitely. I’ve avoided the .NET frenzy altogether, although one of my sons keeps trying to convince me that it’s a faster, better way to get jobs done.

 

Doug: One thing you cannot help but notice is that you are one of the older hands in any gathering of developers. I mention in the introduction to this interview the value of experienced coders. Were you ever tempted to go into management or sales and leave software development?

 

Jim: Definitely not. In fact, when I was offered the opportunity to become unit manager at GE back in the 1970s, I told them I’d resign before accepting such a position. I consider myself a toolmaker, primarily, and my people skills would not make for a good manager. As for sales, as a consultant I have to sell my services, but selling anything else is pretty much anathema to me. I had my fill of it back in 1954, as a retail clerk in a camera store!

 

Doug: You created one of the most amazing tools I have ever seen for repairing and recovering data from damaged Btrieve/Pervasive SQL files. How did you go about uncovering the details of this proprietary database?

 

Jim: It was easier than even I imagined it could be. I met Doug Woodward when I attended the first Btrieve Developer Conference in Austin back in 1995. At that point I had the go-ahead for the book project from Addison-Wesley, and I asked Doug for his cooperation in doing my research. He responded by giving me a floppy disk with the full file format specs! He went even further than that, and told his people to answer any questions I might come up with. Without his enthusiastic cooperation the book would have been much less complete.

One part of the book contained sample programs that demonstrated all the inner details. These were written in 16-bit C code and ran as command-line demos. Even before the book reached the printer, I realized that the program to extract all data from a file without using the Btrieve engine offered wonderful opportunities for data recovery. So we used it at Automation Resources, the company we developers formed after Norick went belly-up, to recover a month’s worth of data after a disk crash made a file unreadable by Btrieve.

Months later, I found myself coming up to deadline for an issue of Btrieve Developers Journal with nothing to write about. I remembered using SaveData.exe to do recovery, and wrote a column about that. Almost immediately I began getting requests from readers to do recoveries for them. It only took about three months for me to realize that I had a potentially salable service, and took out a quarter-page ad in BDJ to publicize it.

At first I customized the source code for each recovery job, and in doing so came across many little details that I had overlooked originally. Eventually I had enough of them implemented to make it possible to create a general utility. Then an undocumented bug in the 32-bit versions of the 6.15 engine reared its head and made my 16-bit program unusable. That’s when I ported it to Windows and created DataSave98, which is the one I’m still using today. I’ve had feedback from lots of people, and the Windows version has been modified nearly 100 times in the past eight years, but its foundation is still the program from Btrieve Complete.

 

Doug: Have you done anything with XML?

 

Jim: I’m just getting into it now. As usual, I stayed away from it until a conversion job came along that required parsing an XML database so that it could be read into Btrieve files. I’m not yet enthusiastic about using XML to store data, but it’s a great transfer medium-even better than the standard Comma Separated Values format.

 

Doug: Without violating any non-disclosure agreements, what sort of work are you doing these days?

 

Jim: I have almost no non-disclosure agreements in force. Mostly I recover data. My client list is worldwide; in just the past two weeks I’ve done work for clients in the U.K., Ireland, Canada, and half a dozen states in the U.S. In addition to data recovery, I do a bit of data conversion, most of which is either to or from Btrieve-format files. That’s a minor part of my current work, though.

 

Doug: Many years ago, after HTML was created by Tim Berners-Lee (http://infomesh.net/html/history/early/), I independently “discovered” markup languages, and was very proud of myself until I came across the much cooler, more thought out HTML. My markup language involved lots of @ signs and was not terribly device independent; I hard coded things that should not have been. Have you ever “invented” anything, only to discover that something better already exists?

 

Jim: I really don’t know. In 1967, I convinced the software folk at GE Phoenix to add an X-Off character between the CR and LF of their output streams, and an X-On after each prompt for input, so that I could pre-punch paper tapes and let them run overnight to upload my documents to the editing system. This may have been the first use of the X-On/X-Off protocol, but it might not have been. I got a preferred parking spot for a month as a result, and a tool that served nicely for the rest of the time I had to use 110-baud transfer. Eventually we got terminals that could handle 134.5 baud and we quit using paper tape.

 

Doug: Have you recently read any good database-related books or general programming books? Will you be writing any new books?

 

Jim: I haven’t seen many good database books in five years or more, or for that matter any general programming books that I could recommend. Almost everything in the stores seems to be application-specific. As for new books from me, I seriously doubt it. I pretty much quit writing in December 1997, when Windows Technical Journal and VB Tech Journal were shut down. There’s been a little talk of doing a new book about the later versions of Btrieve, but Addison-Wesley isn’t interested in such a small market and I’m not getting much encouragement from Austin either. They now want a non-disclosure agreement before providing any technical details. That puts a real damper on doing any in-depth coverage.

 

Doug: Can you think of a particularly cool tip or trick that many database developers do not know about?

 

Jim: Now that’s a hard question to answer! One thing I’ve encountered frequently is the multiplicity of date formats in files created by different applications. While Btrieve has its own perfectly good “date” format that takes only four bytes and handles any date likely to be encountered, people often avoid it and store dates as text strings in any of several formats. Other applications create a 32-bit binary value like 20050313 that has to be translated back to be human-readable. The most unusual date field I’ve seen recently is a four-byte binary number that doesn’t seem to map to anything.

That last one led me to discover something else. At least some applications depend on the sequence of data entry to preserve date sequence, and after a full rebuild the transactions are no longer sorted by date. If the application does not use a date-field key when displaying information, users are upset.

I found that I could use BUTIL to create an external index on a date field that had no index in the file, then use W32MAINT to create a sequential file following that external index. Rebuilding the file a second time, with the new date-sorted sequential file, restored the original assumption and put transactions back into their proper order.

 

Do you know someone who deserves to be a Database Geek of the Week? Or perhaps that someone is you? Send me an email at editor@simple-talk.com and include “Database Geek of the Week suggestion” in the subject line.