Foxpro for DOS application and issue with Code Page 1

[JamshidNia]

I have an old order entry Foxpro 2.6 for DOS application that uses a few large dbf tables. It currently is in service and runs under Windows 10. It works perfectly fine. But when I create new VFP applications using the old dbf tables, VFP does not use Rushmore at all. Upon further investigation, I realized that the DBFs are using code page 437, and that is the reason why Rushmore is not being used in my VFP apps.

So I executed the following commands:
Use OldTable && this is the one that uses code page 437
Copy to NewTable With CDX as 1252 && this one will have code page 1252

When using NewTable in my VFP apps, Rushmore works like a charm. By the way, the Set Enginebehavior command did not help. Here is my question:

If I replace OldTable (code page 437) with NewTable (code page 1252) in the dbf folder, would my Fox 2.6 for DOS application break in any way? I am mostly concerned about realizing that the DOS application might have broken in not so obvious ways, and caused some sort of damage to the data, and this being discovered after it's too late.

I am not yet familiar with the DOS application, nor have the time to tweak with it. That is why I came to this forum hoping that maybe someone has an answer. Thank you so much in advance.

 

[Chris Miller]

It's news to me Rushmore is codepage-dependent. Rushmore only is not working with CDXes which have a different collation than MACHINE.
So what helped with copying the table likely was just recreating the CDXes, nothing else. Keep the DOS code page for your DOS application.

VFPs most compatible format is Fox2x: COPY TO NewTable TYPE FOX2X With CDX, but I'm not sure if that's fully compatible.
Changing the codepage doesn't actually translate data from the original DBF codepage to the other, so you'll see no difference, but it's not causing Rushmore to work. If that was a condition no Asian, Arabic, or East European developers would use FoxPro. It's hard enough not having Unicode support, but if Rushmore would only work with codepage 1252, that would make it a US/Western Europe exclusive feature, no this isn't the case.




Chriss

 

[JamshidNia]

Thank you for your reply Chris. After reading your answer a couple of times, it led me to the solution. Just in case anyone else might run into this question, I have copied the following from VFP's Help and the solution further below.

Rushmore Optimization and Code Pages
Visual FoxPro does not use existing character indexes for tables created with a non-current code page. Instead, Visual FoxPro builds temporary indexes to ensure correct results. This can result in non-optimization of SQL or other commands. To prevent this, ensure that the current Visual FoxPro code page returned by CPCURRENT( ) Function matches the table's code page returned by CPDBF( ) Function. This requires either changing the current Visual FoxPro code page, or changing the table's code page. For information about specifying the current Visual FoxPro code page, see Understanding Code Pages in Visual FoxPro. For information about specifying the code page for a table, see How to: Specify the Code Page of a .dbf File. If you cannot change either the Visual FoxPro codepage or the table codepage to match, you can force optimization to work as it did in Visual FoxPro 8 and prior versions using the SET ENGINEBEHAVIOR Command with either 80 or 70 as a parameter.

In my case CPCURRENT() returns 1252. CPDBF('OldTable') returns 437. According to the above, Rushmore won't work. I tested it, and in fact Rushmore does not work. Sys(3054,1) reports that Rushmore is not used. Contrary to the Help text, changing Set Enginebehavior to 80 or 70 does not work in VFP9.

There are two solutions.

1. Change the OldTable code page to 1252, which would affect both the Fox2.6 DOS and the newer VFP applications:
[tt]Copy OldTable to NewTable With CDX as 1252[/tt]

2. Change VFP's code page when it is launched, which would affect only the newer VFP applications:
In the VFP shortcut (or in your application's config.fpw file) use[tt] "C:\Program Files\Microsoft Visual FoxPro 9\vfp9.exe" -cC:\Program Files\Microsoft Visual FoxPro 9\ConfigCP.fpw[/tt], where ConfigCP.fpw contains [tt]CODEPAGE=437[/tt]

In both cases, Rushmore works. I opted for the 2nd solution for my VFP applications, which would leave the OldTable's 437 code page as well as the DOS application alone. But I think the 1st option is safe too. One could update the table so that it uses code page 1252. I "think" that this won't affect the DOS application running in Windows, because all the keyboard characters [a-z][A-Z][0-9][`~!@#$...] are compatible for both code page 437 and 1252. But characters such as the 437's Smiley character won't be displayed the same way.

 

[Chris Miller]

Well, what I had in mind was:

Rushmore Query Optimization uses the index created in the machine collate sequence

To check this, create indexes in a collation sequence other than MACHINE and see whether Rushmore uses such indexes.

Anyway, I think it's the better solution to keep the data and codepage as is and adapt the new VFP solution to also use that DOS codepage.


Chriss