Change VFP's code page when it is launched, which would affect only the newer VFP applications: Change the OldTable code page to 1252, which would affect both the Fox2.6 DOS and the newer VFP applications:Ĭopy OldTable to NewTable With CDX as 1252Ģ. Contrary to the Help text, changing Set Enginebehavior to 80 or 70 does not work in VFP9.ġ. Sys(3054,1) reports that Rushmore is not used. I tested it, and in fact Rushmore does not work. According to the above, Rushmore won't work. 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. For information about specifying the code page for a table, see How to: Specify the Code Page of a.
For information about specifying the current Visual FoxPro code page, see Understanding Code Pages in Visual FoxPro. This requires either changing the current Visual FoxPro code page, or changing the table's code page. 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 can result in non-optimization of SQL or other commands. Instead, Visual FoxPro builds temporary indexes to ensure correct results. Visual FoxPro does not use existing character indexes for tables created with a non-current code page. Just in case anyone else might run into this question, I have copied the following from VFP's Help and the solution further below. After reading your answer a couple of times, it led me to the solution. RE: Foxpro for DOS application and issue with Code Page That is why I came to this forum hoping that maybe someone has an answer. I am not yet familiar with the DOS application, nor have the time to tweak with it. 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. By the way, the Set Enginebehavior command did not help.
When using NewTable in my VFP apps, Rushmore works like a charm. Use OldTable & this is the one that uses code page 437Ĭopy to NewTable With CDX as 1252 & this one will have code page 1252 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. But when I create new VFP applications using the old dbf tables, VFP does not use Rushmore at all. It currently is in service and runs under Windows 10.
I have an old order entry Foxpro 2.6 for DOS application that uses a few large dbf tables.
0 kommentar(er)
