This can result in non-optimization of SQL or other commands. Instead, Visual FoxPro builds temporary indexes to ensure correct results.
#Microsoft foxpro 26 for ms dos code
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.
#Microsoft foxpro 26 for ms dos windows
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)
