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 bkrike on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

FoxPro 2.6 and Windows 2000 Compatibility

Status
Not open for further replies.

carbide

Programmer
Dec 1, 2000
1
US
We run several standalone executable programs built with FoxPro 2.6. These gather data via netdde and save data to dbf files.

Since I upgraded my PC (733 Pentium, 128 mb) to Windows 2000, have been getting errors not seen under Win 98:

1. When I open FoxPro and, from the command window, try to use (shared) a dbf that is in use by a dde application on a remote network computer, I get the error "Not a Table/DBF" from FoxPro. When the dde application is closed down, I can open the remote dbf.

2. When I run a FoxPro standalone executable program on my local Windows 2000 computer, large listboxes cause an "Insufficient Memory" error from FoxPro.

This seems like some sort of 16-bit issue. Any Windows 2000 setup requirements needed to clear up these glitches with FoxPro?

 
Previously, I would have recommended you to read "Insufficient Memory in FoxPro for Windows on Fast Computers", at - unfortunately MS killed this article off earlier this year (they really don't want to support FPW any more). If you or someone you know has a TechNet CD with the MS Knowledgebase on it from last year, do a search on
Q171047. While some of the problems can't be fixed (Filer e.g.), there are workarounds for most of the others. e.g. The listbox problem can be fixed, in some cases, by using the ideas in Paul Lee's FPWListBox file at
Rick
 
I do not know of any incompatibility issues with running
Foxpro DOS under Windows 2000, but a couple of suggestions
may throw some more light upon your problems.

1. When opening the DBF in the Command Window and you get
the Error Message 'Not a Table/DBF' are you able to trap
the Error Number. Error 15: Not a Database File is usually the Header File Info being corrupted, but the fact that you can access this file later would seem to negate that.

Try trapping the error with the following:-
Go into Command Window
Type Command: Acti Wind Debug
With LHS of Debug Window type Error()
Now go back to Command Window and try to open the DBF
file. You should see a number (Error Number) appear opposite Error() within Debug Window.

2. Try opening the same DBF under a different Alias:-

I.E At Command prompt Type:-

use <myfile> again alias <new_file>

does the same error result??

3. Finally, can you verify the following:-
3.1 The DDE applicaton does not use the file you are trying to open exclusively.

3.2 Can you try the reverse.
i.e. Close down the DDE application
Open DBF through Command Window setting exclusive off
Within Foxpro session minimised, can you now run DDE
application OK?

Keep in Touch...
 
foxpro 2.6 seems to be running slower in windows 2000 than on other OS's - it also sometimes crashes. Does anyone know of a solution to this problem??


Thanks

Chris
 
I have also experienced problems with the performance of FPW 2.6 applications running on Windows 2000/XP. The applications are running much slower than on 95/98.

I managed to make the applications speed up by about 2-3 times by moving the processor scheduling to background tasks and giving the VDM Real Time processor allocation. However even with this increase in performance the applications are pretyy much unusable.

I checked how the system runs the applications and strangely it appears to be in exactly the same way as NT4. It runs a 16 bit VDM with all components as seperate threads off the VDM. The only difference seems to be in processor time allocation. If you watch the threads in task manager on an NT4 box, they regularly shoot up to about 80% and the application runs fine. On NT5 (XP/2K) there is a delay before the processor time gets allocated to the thread and then it appears to be limited to about 35%.

I have also tried running the applications in seperate VDM's and this makes no difference at all, as does changing system memory allocations etc.

Any info on why or how to get 'round the problem would be greatly appreciated.

Thanks

Rog
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top