Converting provious foxpro table to VP8 5

[jpower5]

I am in the process of converting an old foxpro system that is a combination for DOS and Windows 2.6
Right now, I when I open a table in VP8, I get the
code page dialog box.

Is there a program/routine with VP8 that I can use to
convert approximately 25 tables in one step instead of
going thru the process individually, one table at a time??

Thank you in advance for any info you can supply

jim

 

[ramani]

Hi

1. SET CPDIALOG ON and OFF sets the display of the options to mark an earlier version as belonging to a codepage.

2. To make the code page to none.. i.e. as in earlier versions..
DO Cpzero [WITH "filename"[, codepage_number]]
[Located in the Visual FoxPro Tools\Cpzero folder, Cpzero.prg removes the code page mark from any file that has a table file structure. After removing the mark, Cpzero applies another mark that you specify.]

3. Now to mark all the tables use the copy command as given below..
SET CPDIAG OFF
USE oldDir\myTable
COPY TO myNewDir\myTable

This will copy the myTable with the current default codepage of VFP

OR
COPY TO myNewDir\myTable AS myNewCodePage

YOu can loop thru all the tables in a given directory and copy them all to a selected new directory.




____________________________________________
ramani - (Subramanian.G)

http://winnersoft.coolfreepages.com/

 

[jpower5]

Thank You...

question when you said..

...After removing the mark, Cpzero applies another mark that you specify

how do you specify the mark and exactly what is a mark that i can specify??

 

[rgbean]

CPZERO is just a .PRG you can see how it's called by opening it. It (and VFP Tables) support the following Code Page values:

437  && MS-DOS, U.S.A.
850  && MS-DOS, International
1252  && Windows, U.S.A & West European
10000 && Macintosh, U.S.A.
852  && MS-DOS, East European
866  && MS-DOS, Russian
865  && MS-DOS, Nordic
861  && MS-DOS, Iceland
895  && MS-DOS, Kamenicky (Czech)
620  && MS-DOS, Mazovia (Polish)
737  && MS-DOS, Greek
857  && MS-DOS, Turkey
863  && MS-DOS, Canada
950  && Windows, Traditional Chinese
949  && Windows, Korean (Hangul)
936  && Windows, Simplified Chinese
932  && Windows, Japanese (Shift-jis)
874  && Windows, Thai
10007 && Macintosh, Russian
10029 && Macintosh, East European
10006 && Macintosh, Greek
1250  && Windows, East European
1251  && Windows, Russian
1253  && Windows, Greek
1254  && Windows, Turkish
1255  && Windows, Hebrew (Only supported on Hebrew OS)
1256  && Windows, Arabic (Only supported on Arabic OS)
1257  && Windows, Baltic
0  && No codepage mark.

Note: Internally a different value is actually stored in the byte that's reserved for this - VFP just maps the internal value to one above. The "observant" will figure out that VFP tables will never be able to support more than 255 different code pages without a change to the header.

Rick

 

[jpower5]

thanks....
i found the prog CPZERO...

So from a programming stance, I can create an array with the table names and then execute the
program do cpzero with "table name from array.dbf","1252"
and that should do the conversion...correct?/

again thanks for your help

 

[rgbean]

Almost. Make that:

do cpzero with "table name from array.dbf", [red]1252[/red]

The code page is a number not a string.

And thanks for the star!

Rick

 

[jpower5]

thank you for all your help...

greatly appreciated..

 

[tondi]

I have a similar scenario. Have converted our application to VFP8 and changed codepages for DBFs to 1252 during upgrade data conversion yo avoid pop up codepage window at end user. Accessing from another WS running FPW26 version of same app produces 'not a database error.' Is the new converted table no longer usable by FPW26 app? Any solution or comments appreciated.
Thanks in advance ...
Tony

 

[rgbean]

Tony,
Changing the code page will not cause the 'not a database error'. However if you have changed the structure of a table in VFP (e.g. ALTER TABLE), then it will become a VFP table and will not be readable in FPW. We've run an application for many years that has data accessed by FPW and VFP versions on the same network, and by carefully handling the data, there aren't any problems. (Note: If you've changed it to a VFP table, use the COPY TO TYPE FOX2X to get it back so both platforms can use it.)

Rick