Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Creating tables for backward compatibility

Status
Not open for further replies.

brigmar

Programmer
Mar 21, 2006
414
US
Some developers in house are using VFP, and some FPW 2.6, and still one using FPDOS 2.5, all writing tables for use with a FPDOS2.5 app.

So, a simple question, one which has probably been answered before:

I want to create a table in VFP, and have FPDOS/FPW able to use the table (so no autoincrementing fields etc).

My proposed 'solution' right now is to hack the dbf file... converting the 0x30 (VFP) file type byte to 0x03(no memos) or 0x83(with memos), stripping the 263 bytes of the 'database container', and re-setting the data pointer.

1) Did I miss something spectacularly simple ?
2) Is this 'solution' workable ?
3) Has anybody tried it on their own systems ?
 
Why not just:
Code:
USE MyVFPTable
COPY TO MyFPDOSTable FOX2X

Borislav Borissov
 

Brigmar,

Yes, it is spectacularly simple. Borislav has given you the solution.

Be aware that, once you have copied the table to FOX2X format, you must not change its structure in VFP (or, if you do, you must repeat the COPY TO ... FOX2X). Also, the table can't contain any of the "new" VFP data types (such as DateTime or Integer), nor can it have a code page, nor any nullable fields. Also, you will lose the compatibility if you place it in a DBC.

But apart from those restrictions, it's simple -- and has certainly been done many times before.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk
 
Thanks for the quick responses.

Borislav:
Why not indeed ?
I had this suspicion that it would be something overlooked. Hence question (1).

Mike:
I am able to modify the table structure (add columns) using an SQL 'alter table' command. The resultant table is still readable and usable in FPW. Does your caveat only apply to "new" data types(which we'll be steering clear of anyway) or to modifying the structure using the 'modify structure' dialog ?
 

Brigmar,

I am able to modify the table structure (add columns) using an SQL 'alter table' command. The resultant table is still readable and usable in FPW. Does your caveat only apply to "new" data types(which we'll be steering clear of anyway) or to modifying the structure using the 'modify structure' dialog ?

I might have mis-phrased that. It's not so much the fact of altering the table structure, but rather the use of the new data types (and the nullabilitly and other issues). Sorry if that wasn't clear.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top