BUTIL documentation

[Paul4]

Does someone have documentation for BUTIL.EXE?

The tips that appear with BUTIL /? are very sparse, close to being worthless for someone who isn't familiar with Btrieve.


Like many others here, I'm attempting to access this old (6.15) data in a modern system. Unfortunately, I have to have access concurrently with a Btrieve DOS app, meaning that I can't use the new Pervasive engine.

I tried using BTSearch, mentioned elsewhere on this board, but it appears to require the Windows Btrieve driver, although the documentation doesn't seem to mention that.

Any tips would be appreciated.

 

[mirtheil]

What specfically are you trying to do? BUTIL is very limited in what it's designed for. What commands are you trying to use that you don't understand?
You can actually update to a newer engine even for the DOS side of things. The only thing missing would be a newer DOS client engine.

Mirtheil
Certified Pervasive Developer
Certified Pervasive Technician
Custom VB and Btrieve development.

http://www.mirtheil.com

 

[Paul4]

Thank you for your response.

The first thing I'm trying to do is to find out what I CAN do! Someone (you?) mentioned in another post that -SAVE can be used to export to a text file. But you'd never know that from the built-in documentation!

BUTIL -EXPORTTODBF would be nice, but I doubt that I'd be that lucky...


Like I said, I need to access the data in a modern system, while not interrupting the operation of the existing Btrieve DOS application. Read-only will do for now, but read-write may be required in the future.

I'm considering something hacky, like using a simple file copy to copy the btrieve file to some private location, then reading it with an ODBC connection run by the new 8.6 engine. (Fortunately, I do have a set of ddf's.) I could re-copy the btr file whenever I need to refresh the data.

Is there any reason that wouldn't work? Any better ideas?

 

[mirtheil]

BUTIL will only export (or SAVE) to an Unformatted Format. The export basically is the record lenght, a comma, and then a binary image of the record. Any non-text fields will be in the binary format of the field (integer, numeric, date, etc).
THere is no EXPORTTODBF or any other format.
Is the DOS app running on a "pure" DOS machine? If not, download a trial of the V8.6 engine and try it with the DOS application. Most applications will still work with newer versions of Btrieve/Pervasive. Then you can use the ODBC to get real time access to the data. Worst case, do what you consider hacky and copy the files to a machine with the newer engine and work with them there. Here's something I found in the V9 (beta) documentation on BUTIL:
Table 13-7 Command-Line Maintenance Utility Commands Command Description
CLONE Creates a new, empty data file using an existing file's specifications.
CLROWNER Clears the owner name of a data file.
COPY Copies the contents of one data file to another.
CREATE Creates a data file.
DROP Drops an index.
ENDBU Ends continuous operation on data files defined for backup in Win32 and NLM versions only.
INDEX Creates an external index file.
LOAD Loads the contents of an unformatted file into a data file.
RECOVER Reads data sequentially from a data file and writes the results to an unformatted file. (The DOS version does not support ROLLFWD.) Use this command if you have a damaged file.
ROLLFWD Recovers changes made to a data file between the time of the last backup and a system failure.
SAVE Reads data along a key path and writes the results to a sequential file.
SETOWNER Assigns an owner name to a data file.
SINDEX Creates an index.
STARTBU Starts continuous operation on files defined for backup in Win32 and NLM versions only.
STAT Reports statistics about file attributes and current sizes of data files.
STOP (DOS only) Unloads the Btrieve Interface and requester.
VER Displays the version of the MicroKernel Database Engine and Btrieve Interface Module that is loaded at the server



Mirtheil
Certified Pervasive Developer
Certified Pervasive Technician
Custom VB and Btrieve development.

http://www.mirtheil.com

 

[Paul4]

Thank you for the longer description of butil parameters. FWIW, when I use -COPY, I get a "file not found" error. No reason that I can see - the file is right there in the butil directory.

The DOS app is located on a file server. The workstations all run the app from there. All are Windows XP.

I cannot use the Pervasive 8.6 engine (I use it only for the ODBC driver) because it and the DOS engine cannot access the files at the same time. If the DOS app starts first, my app gets some "data not available" error. If the DOS app is not running, my app runs fine, but then the DOS app will get errors when it starts.

There's really only one table I need to access (so far), and it's read only (so far). That's why I thought of the idea of copying the btr file to another location, then accessing it with the 8.6 engine. Kind of brute force and hacky, but it seems like it should work. (I'll find out this afternoon.) I don't know what I'll do when the time comes that I'll need to write to the data...

Perhaps if I had an ODBC driver that uses the 6.15 engine for Windows, then both apps could access the data at the same time. But I don't know where to get that engine and driver. It's all obsolete and unavailable as far as I've been able to tell. Do you have any ideas on that score?

 

[mirtheil]

What's the exact error and command line you are issuing?
You are correct that two engines cannot access the same file at the same time. THis is true going back to the beginning of history (areound 1985 when Btrieve was released). For your DOS app, don't load BREQUEST/BREQNT/BTRIEVE.EXE. The V8 engine has support for DOS applications that will let you run both the DOS app and a Windows App at the same time.
If at all possible stay away from the 6.15 ODBC driver. THe v2.0x was not very thread safe and really wasn't even fully 32 bit. I don't even know if it'll work on WinXP.


Mirtheil
Certified Pervasive Developer
Certified Pervasive Technician
Custom VB and Btrieve development.

http://www.mirtheil.com

 

[Paul4]

> For your DOS app, don't load
> BREQUEST/BREQNT/BTRIEVE.EXE.

Unfortunately, it's not my app and I don't have much control over it. And it's used frequently enough that shutting it down when my app is to run is not an option.



> The V8 engine has support for DOS applications that will
> let you run both the DOS app and a Windows App at the
> same time.

Really? That would fix my problem. But how would I take advantage of that? Like I said, the DOS app is not mine; I don't have the source code and I'm sure I wouldn't be allowed to modify it anyway.

The DOS app is started by a small batch file that first calls btrieve.exe, then calls its own exe.

 

[mirtheil]

In your batch file, rem out the call to BTRIEVE.EXE. Make sure that the V8 engine is installed. That's really all you need to do. You'll have to do that for all workstations that use the app. You can try it on one machine as long as the data is local.


Mirtheil
Certified Pervasive Developer
Certified Pervasive Technician
Custom VB and Btrieve development.

http://www.mirtheil.com

 

[Paul4]

Really?? (You mean the client engine, right? I don't have the server engine.) Wow, that sounds too easy... I'll try it, thanks.

The batch file, the DOS app, and all data are located on the file server. The workstations just run a shortcut to the batch file.

I guess that means I have to install the 8.6 engine on that file server, so that the DOS app can run. And on each workstation too, so I can use ODBC. Is that correct?


Thanks for all your help. If you need any FoxPro tips, let me know.

 

[mirtheil]

Yes. You'll need the 8.6 engine (most likely the server engine depending on the number of users). If you use the server engine, you would need the Pervasive client (rather than the workgroup engine) on each client).
You should do this in a test environment first.

Mirtheil
Certified Pervasive Developer
Certified Pervasive Technician
Custom VB and Btrieve development.

http://www.mirtheil.com

 

[Paul4]

Thank you for all your help. I have tested it and it works, as long as all workstations have the workgroup engine installed. Having it on only one won't do, because it conflicts with the others.

Now if only the client would be willing to pay for all those installations, when he really needs only one per location. There are approximately 80 workstations at 20 locations and growing, and even volume pricing won't be cheap.

If it's not one thing, it's another...

Thanks again! You've been most helpful.

 

[mirtheil]

Make sure you talk to Pervasive (your sales rep). I've heard they will work on volume deals..


Mirtheil
Certified Pervasive Developer
Certified Pervasive Technician
Custom VB and Btrieve development.

http://www.mirtheil.com

 

[Paul4]

I did, thanks. I can get it down to $20/seat, which doesn't sound bad until you realize that that's $2000, kind of a large amount for a small company trying to grow.

It's also annoying to have to buy a copy for every workstation, when they wouldn't need it at all except for my app, which they'd be happy to run only on one computer.

And that's not to mention the hassle of installing the wge on every workstation.

So it looks like I'll end up going back to my original idea of using butil, perhaps copy the table to a text file and parsing it. There doesn't seem to be a more viable solution.

But that won't be easy either, since the fields I'm after are numeric (and those are stored in some binary code that I'll have to interpret, right?)

This is all getting to be a huge hassle and a big expense for the client, all to access data, a task that shouldn't have taken more than a couple hours.

Ah, jeez...

 

[mirtheil]

How many workstations? You might want to look at the server engine if all of the data files are on the server. Then, you only need to install the client on each workstation.

BUTIL output is not for the faint of heart. You will need to interpret the numeric data.
I would look at the Btrieve API rather than BUTIL. You'll still need to know the record structure but when you bring the data back, it'll be in the format you specify. As part of the call you send a buffer. That buffer can have a record structure in it.

Mirtheil
Certified Pervasive Developer
Certified Pervasive Technician
Custom VB and Btrieve development.

http://www.mirtheil.com

 

[Paul4]

I don't think the server route is the way to go in this case. There are approximately 20 independent locations with approximately 4 workstations per location. They would have to buy 20 copies of the server, and that's really getting out there in terms of $.

About the Btrieve API, you mean the one that comes with the 8.6 WGE? I haven't looked at that, but wouldn't that mean I'd have to install the WGE anyway? And if I do that, I might as well use ODBC. Or am I misunderstanding something?

This is getting to be a real headache. (Even more so for the one who has to pay for it!) Maybe I should just copy the functionality of that old DOS app into a modern Windows application, and sell it as a commercial product.

 

[mirtheil]

Actually, the Btrieve API is the same for 8.6 as it was in 6.15. That's the beauty of the API. It hasn't been changed and shows why old DOS apps can still work with newer engines. You might have to build a DOS app to get it to work properly but the API is the same. Take a look at http://www.pervasive.com/library/docs/psql/615/b615prog.pdf. It's the old Btrieve 6.15 programmer's reference.


Mirtheil
Certified Pervasive Developer
Certified Pervasive Technician
Custom VB and Btrieve development.

http://www.mirtheil.com

 

[Paul4]

Thank you.

I am surprised that there is an API to the Btrieve DOS engine. I will read the manual at the link you gave and find how to use it.

Since it appears that because of the cost, I will not be allowed to install the newer engine on all the workstations, I need to have some way to work with the existing DOS engine.

 

[grnelson]

Just to add a note regarding BtSearch. You can purchase BtSearch32 with the Btrieve 6.15 Windows Workstation edition. This will allow you to access the data using BtSearch32 at the same time as your dos applications. While BtSearch32 uses the 6.15 drivers the drivers included with the download also includes the ODBC but as mentioned they were not the best and may have problems on the newer operating systems.

Gil


Gil