Export Foxpro 9 DBF to Dbase 5 File 1

[gbcpastor]

I have a client with proprietary software that requires dBase 5 files. I need to export a file in DBF format that is compatible with their system. I don't know what's different about the files but they have to be dBase 5 format.

 

[Chris Miller]

By the way, regardnig what DBF formats ACCESS supports, the most "comprehensive" list I found is here:

Link to or import from dBASE - Microsoft Support

Learn how to link to or import from dBASE into Access databases.

support.microsoft.com

dBASE III, dBASE IV, dBASE 5, and dBASE 7

Well, to be honest, other info I found was not even concrete about dBASE versions, just dBASE.

So the FOXPLUS DBF you generate now with COPY TO might be imported as dBASE III or dBASE IV formats by ACCESS, even if they choose dBASE 5.

They even say

The default file format is dBASE III.

Well, at least it means they didn't need a dBASE 5 file, specifically, it can be dBASE III or IV, too.

 

[mjcmkrsr]

Hi

fwiw

form Hacker's Guide 7


Set Compatible, Set("Compatible")

A SET command that toggles the behavior of many other commands and functions from their "normal" way to those more like dBASE IV's behavior. This is a dangerous command.

Usage

SET COMPATIBLE ON | DB4 | OFF | FOXPLUS [ PROMPT | NOPROMPT ] lcCompSet = SET("COMPATIBLE") && Returns "ON" or OFF"

ON and DB4 are identical, as are OFF and FOXPLUS. The PROMPT | NOPROMPT option is kind of like a SET SAFETY for dBASE IV memo files.

When Fox Software first came on the scene with FoxBASE, its goal was to emulate dBASE II, only faster. As time went on, Fox began to add new features to the language. There was always the danger that a new feature added by Fox would conflict with a command of the same name in the next release from Ashton-Tate, and in fact, this happened several times. SET COMPATIBLE was an attempt by Fox Software to maintain its goal of 100% compatibility with dBASE, while still innovating within the Xbase language. The manuals and help files supplied with Visual FoxPro cover the scope of this command pretty thoroughly, and we haven't found any funny behaviors beyond those described in "Commands and Functions Affected by SET COMPATIBLE" in the help file.

Hardly anyone remembers off the top of their heads all the things that get funky if you flip the compatibility toggle. Although this function can be used as a stopgap measure by developers while converting a system from dBASE to Fox, we strongly urge all developers to use the native functionality of FoxPro, and to maintain COMPATIBLE FOXPLUS.

The PROMPT option is to determine whether a confirming dialog appears before a dBASE IV table with memo fields is converted to a VFP table. VFP lacks the ability to work with dBASE IV tables natively, although it does fine with dBASE III tables. We suspect that this is a marketing, and not a technological, limitation.

The PROMPT dialog that comes up is a bit confused. First, pressing the Help key is the same as the No key. Second, the dialog states that "This can later be reversed with COPY TO … TYPE FOXPLUS." This is not exactly true—that command will create a dBASE III, not dBASE IV, memo field. Finally, clicking on No errors the system with "Not a table."

If you choose to convert the dBASE IV file, a follow-up dialog prompts you to strip the "soft returns" from the memo fields. Soft returns are CHR(141)'s that dBASE added into a file to do word wrap. Select Yes only in those cases where text is stored in this field—always answer No if the memo field contains binary data. In addition, the table must be open exclusive or you get an error message. In case all that isn't enough, the memo file is changed from a DBT to VFP's FPT format, and you can't open the table in dBase IV any more. Yuk. We sure wish they'd give VFP the ability to read dBASE IV files natively (not that we run into a lot of them these days).

hth

MarK