(Disclaimer: I'm not only a fan of FlagShip but a developer of FlagShip add-ons and a reseller of WGS's Linux package. But they honestly do have a great product.)
The most popular tool to perform such a task is FlagShip, distributed in the US by
<url name="WorkGroup Solutions, Inc." url="http://www.wgs.com"> Post Office Box 460190 Aurora, Colorado 80046-0190 Sales: +1 303 699 7470 Email: email@example.com
FlagShip claims to be "NOT a porting tool" but "in fact a full Unix implemetation of CA-Clipper through version 5.2e." A spokesman goes on to say that "the fact that C intermediate code exists is useful for some, but safe to ignore for most users."
There is also a freeware portable translator for Clipper called X2c. This used to be a commercial product but the publisher decided to redirect its resources to other projects.
C Libraries for using .DBF and index files include:
herCules APIS Software Frankfurt/Main, Germany Includes source code, understands NDX, MDX, NTX, and IDX files. Supports DOS, Windows, OS/2, and UNIX/XENIX. SoftC Database Library SoftC, Ltd. Anoka, Minnesota USA Source code and Windows DLL included. Supports DOS, Windows, OS/2, and UNIX/XENIX. <url name="Sequiter Software" url="http://www.supernet.ab.ca/Mall/Computer/Sequiter/sequiter.htm"> CodeBase and CodeBase++
Contributions by Mark Bolzern (WGS), Barry Mavin (Recital), Guenter Schwaninger, and Rich Roth
Last updated 1 January 1994; contributions by Brad H. Codd of Aladdin.
A product from Aladdin allows your CA-Clipper application to access native AS400 data files at the record level. Call Aladdin at +27 11 642-4588. Technical support was promised to be available in Los Angeles, California USA beginning January 1992, but I have not verified this.
As of July 1993 I have been informed that this can also be done with CAS400 by T.L. Creates at +1 209 946 0105, and with Clip2 by Dabiwa, Ltd., at +1 215 692 8130.
An RDD called Win/400 does the same. I don't have contact info for this product though.
Rushmore is not an index type, nor is it magic as the Fox people would have you believe. It is simply a FoxPro feature that automatically figures out the most efficient way to use existing indexes in a query (LOCATE, LIST, anything with a FOR clause, etc.).
Rushmore is handy for interactive queries, but most application developers can know ahead of time what lookups need to be done on their database files and can arrange for an optimized lookup the old-fashioned way with little effort.
That's why the Rushmore test results look so good but are not very relevant to what many application developers really do. If you are trying to write a very open-ended reporting program, on the other hand, it may be just the ticket.
Third-party database drivers (RDDs) for Clipper can perform similar query optimization. Two that I know of are Mach Six (included in The SIx Driver package) and ClipMore (an add-in to COMIX).
First off, there are several advantages to using a FoxPro-like index scheme.
*.CDX files can contain more than one "tag," each of which relates
to an index key. Therefore you can drop all your many CA-Clipper
*.NTX files by converting each to a "tag" within a single .CDX file.
This also lets you always open a file with
with assurance that you got all the tags. Better still, when
you perform a plain
the driver will automatically
find and open a corresponding .CDX file with the same base name
as the datafile.
Replaceable Database Drivers which support FoxPro-like files are:
SIx itself does not give you Rushmore lookups, but it is shipped with an add-in called MACH which does. Likewise Comix has an accompanying library called ClipMore which does the same thing.
The modem on a serial port can be looked at as just another file as far as output is concerned. (This is a useful oversimplification.) You just need to open the serial port as a file and write a string such as "ATDT123-4567" followed by a carriage return and line feed to send a Hayes-compatible dial command to the modem. A function like this would do the job nicely:
FUNCTION dialphone (nPort, cNumber) LOCAL nFile := FCREATE ("COM" + STR (nPort, 1)) // Open port FWRITE (nFile, "ATDT"+cNumber+CHR(13)+CHR(10)) // Write ATDT command FCLOSE (nFile) // Close it RETURN NIL
Microsoft is attempting to increase network speeds in Windows 9x and their server software, Windows NT, by cacheing network data. While this can effectively reduce network traffic and speed up access, it also means that confirmed data can sit unwritten in your outbound network buffers. Prior to this recent development by Microsoft, no other operating system Client/NOS would cache write data simply because of the possibility of the loss of unwritten data.
Client/Server software does not appear to be impacted by this overcaching.
How can we work around this problem?
Currently, two causes are identified:
1. The early Microsoft Windows 95 OSR2 Client redirector has some bugs. Microsoft has released several redirector patches. Two of them are available on The Oasis. You may have to try them both. Try the old one first. The older one is named VRDR2UPD.ZIP and the newer one, VRDRUPD.ZIP. You might find an even newer one on the Microsoft site.
2. There are some registry settings that change the way caching is implemented in the Microsoft network client. There is a registry patch which the Lotus Corporation provides for their cc:Mail customers which will automate the change to the registry settings. This patch turns off network caching and causing writes to be immediate. Be certain to back up your registry before you run this patch.
If you can't get the Microsoft client to stop corrupting your data, you might want to try the Novell IntraNetWare Client. It seems to have much less of this bad behaviour and also has registry entries which will turn of write cacheing and turn on immediate writes. You can download it from the Netware web site.