What issues arise when converting code from dBase to Visual FoxPro?

In particular this explanation applies to dBase 5 conversion to Visual FoxPro, but no doubt would be similar for other dBase versions. While not an exhaustive list, this gives a general idea of the differences between the two languages when they have identically named commands or functions.

Surely there are many conversion utilities available, but this FAQ does not attempt to evaluate them.

For much of the code, you can port it right over into VFP. Even the @ SAYs and GETs will work, though officially it is strongly discouraged as outdated and visually awkward. The display may look weird since VFP uses proportional fonts by default, but it will work.

dBase SQL modes and VFP SELECT-SQL commands are incompatible.

Screens .SCR and reports .FRM are incompatible of course.

A dBase tokenized pseudo-compiled .DBO is different from VFP's .FXP of course.

A dBase REPORT FORM does not include any printer-specific code. VFP saves the printer driver and other details in the first record of the REPORT FORM (.FRX table). To clear this data, open the .FRX as a table, and clear the first record's fields TAG and TAG2. You may also want to delete the lines referring to driver, device and output in the EXPR memo field.

A dBase UDF (user defined function) cannot close a table or workarea that was open when the UDF began. View it as entering and exiting a special environment. Not an issue with VFP.

A table created by dBase can be read by VFP, but one created by VFP cannot be read by dBase 5. VFP has a special COPY TO <tablename> TYPE FOX2X command which creates the table using the old FoxPro table structures and dBase should be able to open it. My tests resulted in a warning message "Mismatched language driver for database: <tablename> Okay to use with your current language driver?" but then let me open the table.

Both dBase and VFP can use the same indexed table, but since they use different indexing schemes, .MDX versus .CDX, the other's index does not get updated. In this situation, tables shared between the two environments during conversion probably should not be indexed because in order to reindex (to ensure being up-to-date) you need exclusive access, and that means everyone else gets bumped out.

VFP can append from a dBase table just fine, with one strange exception. (Disclaimer: Months later I was not able to duplicate this problem!) If you want to append just some of the source records by using a FOR/WHILE filter, then the source and destination table must have identical field order, though fields can be missing or added in either one. For example, if the dBase table has Name, Age and Address, the VFP table cannot change the order to Name, Address, Age, though Name, Email, Address, Age or Name, Nickname, Age should be just fine.

dBase can always append from another table even if in use by another, but VFP cannot if in EXCLUSIVE environment.

dBase and VFP handle too-small or too-large numbers differently when being input into table fields. Here is an example of their differences for a table field created with a size of 4 with 2 decimals (9.99):
[code Text]
0.005 - VFP rounds up to 0.01
0.005 - dB. rounds up to 0.01

0.0049 - VFP rounds down to 0.00, no error
0.0049 - dB. writes it as scientific notation, no error, displays message "Numeric overflow (data may have been lost)"

99 - VFP writes it as 99.0
99 - dB. writes it as 99.0

999 - VFP writes it as 999
999 - dB. writes it as 999

9999.5 - VFP rounds up, writes it as ****, generates error 39, displays message window with "Numeric overflow. Data was lost."
9999.5 - dB. rounds up, writes it as ****, no error, displays message "Numeric overflow (data may have been lost)"[/code]
dBase and VFP have different concepts of how tables are opened:

- dBase lacks the VFP SHARED argument, depending instead upon the setting of the EXCLUSIVE environment variable.

- Using dBase NOUPDATE in an EXCLUSIVE environment will not open it EXCLUSIVE as it will in VFP. Think of dBase NOUPDATE as identical to VFP SHARED NOUPDATE.

- dBase AGAIN works only if EXCLUSIVE is off (table-status-based detection). In VFP AGAIN always works (user-based detection).

- dBase table access will run faster with EXCLUSIVE NOUPDATE than with SET EXCLUSIVE OFF and using NOUPDATE.

Date comparisons - VFP properly compares empty dates.

Avoid {date} since that format expects datetime input. Okay for {} to generate an empty date value.

Some settings, though named identically, behave differently, and sometimes depending on other environment settings. One simple example is concerning the == operator. dBase always ignores trailing blanks with that operator, but VFP does not.

ACTIVATE SCREEN line is needed before "@ nn,nn SAY... GET..." Be aware this is allowed but does not take advantage of advanced display/edit behaviors.

READ ... if using multiple reads then you may need to add CLEAR line.

BROWSE LOCK 1 ... use BROWSE LOCK -1 (a positive value creates vertically split window.)

DEFINE POPUP cMenuName FROM nn,nn ... add "IN SCREEN".

DEFINE WINDOW - Change "FROM" & "TO" to "AT" & "SIZE"

DEFINE WINDOW - Include "FONT cName, nSize"

ACTIVATE WINDOW - Include the "TOP" keyword.

PACK has additional parameters to review.

ACOPY(...) ... VFP does not use the last parameter used by dBase.

AFILL(...) ... Pass the first parameter by reference using "@" prefix.

APPEND FROM cFile TYPE BLANK ... must use "SDF" rather than "BLANK".

CREATE cTable FROM cStructure ... redesign this logic.

INDEX ON cExpr TO cFile ... Don't specify extension since dBase is NDX and VFP is IDX.

SET("ORDER") ... try ORDER([cAlias|nWorkarea]) if need FullPath then add 2nd parameter.

SELECT SELECT() ... VFP changes to SELECT 0