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

Poll #1: What versions of FoxPro/XBase languages did you use?

What versions of FoxPro/XBase languages did you use?

  • FoxBase, FP1-FPW2.6 (any versions by Fox Software)

    Votes: 24 57.1%
  • VFP3

    Votes: 16 38.1%
  • VFP5

    Votes: 12 28.6%
  • VFP6

    Votes: 24 57.1%
  • VFP7

    Votes: 19 45.2%
  • VFP8

    Votes: 16 38.1%
  • VFP9

    Votes: 37 88.1%
  • VFPA

    Votes: 7 16.7%
  • DBase (any version)

    Votes: 16 38.1%
  • Clipper, Harbour, Alaska XBase++, other clones (name it)

    Votes: 12 28.6%

  • Total voters
    42
  • Poll closed .
Status
Not open for further replies.

Chris Miller

Programmer
Oct 28, 2020
4,756
DE
I'm just interested. Also see other polls about current and planned versions.
 
Jumped from FoxPro 2.6 for Dos straight to VFP9... had a lot to learn. Still has.
 
I started with dBase II on CP/M, then DOS, then every major update of dBase, FoxBase and Clipper while they were all pretty much identical languages.

At first I was so deeply into dBase III that I ordered DBASE IV as my license plate in anticipation for what I thought would be the winner.

1726137333478.jpeg

When dBase IV finally came out, that's when the languages started to split and FoxPro proved to be a better choice, mainly because of speed. Rushmore was absolutely a game changer and that made the choice easier, but I still kept my code as neutral as possible. After Microsoft saw the potential of Rushmore for future versions of SQL Server and purchased Fox for the patents and people, I knew for sure I made the right choice and I went all in.

For many years I had preprocessor commands with #IF _DOS sections so that customers who were still running DOS would have @ SAY/GET screens running the same exact source code, so the transition to Windows versions was seamless and reinforced my choice.

I support VFPA with donations mainly because I like the idea that somebody is still fixing old Microsoft bugs and removed the 2GB limit (which I've never hit, but have come close to), but I've never delivered anything that uses it yet. The biggest bug I hoped he would address was the dreaded optimistic lock SMB bugs that corrupted indexes, but he said it wasn't a priority, and by now I've already worked out ways to avoid SMB entirely by running everything via remote desktops.
 
I started with dBase II on CP/M, then DOS, then every major update of dBase, FoxBase and Clipper while they were all pretty much identical languages.

At first I was so deeply into dBase III that I ordered DBASE IV as my license plate in anticipation for what I thought would be the winner.

View attachment 308

When dBase IV finally came out, that's when the languages started to split and FoxPro proved to be a better choice, mainly because of speed. Rushmore was absolutely a game changer and that made the choice easier, but I still kept my code as neutral as possible. After Microsoft saw the potential of Rushmore for future versions of SQL Server and purchased Fox for the patents and people, I knew for sure I made the right choice and I went all in.

For many years I had preprocessor commands with #IF _DOS sections so that customers who were still running DOS would have @ SAY/GET screens running the same exact source code, so the transition to Windows versions was seamless and reinforced my choice.

I support VFPA with donations mainly because I like the idea that somebody is still fixing old Microsoft bugs and removed the 2GB limit (which I've never hit, but have come close to), but I've never delivered anything that uses it yet. The biggest bug I hoped he would address was the dreaded optimistic lock SMB bugs that corrupted indexes, but he said it wasn't a priority, and by now I've already worked out ways to avoid SMB entirely by running everything via remote desktops.
What is an SMB bug? Guess I never ran into it................................................................ love the license plate!!
 
I started with Enable (anyone ever even heard of it, let alone remember it?).
I think DbaseIII was next for me, OH, then Paradox! I knew I was missing (some) from the other languages, and then Visual PAL (nightmare). Then FPD1.(something) and FPD2, moving to FPD2.6 and FPW2.6. (Loved these by the way).
I was at the launch of VFP3 and VFP5 (there was no VFP4, but you all knew that, right? ;))
Lots of weird stuff back in the day.
 
What is an SMB bug? Guess I never ran into it................................................................ love the license plate!!
When sharing files on a File Server that's based on newer versions of SMB have a feature called Optimistic Locking (aka OpLocks) that improves speed of accessing files, by trusting local cached versions of files rather than forcing the local client to re-read them, which often conflicts with the updated values. This leads to corruption of data, especially indexes.

It's not just a FoxPro problem. Access and other file based databases have the same potential problem. The more users accessing the same parts of any given file you have, the more likely the files will become corrupt.

I've used all sorts of ways to avoid the problem, but eventually the most effective thing was to not open files over a network share, especially as a mapped drive, and to require my users to use Remote Desktop / Terminal Services. It not only avoids the network sharing issues, but works at amazingly faster speeds.
 
I jumped into VFP9, but use FP2.6 to support an old DOS application that runs in one department, have been trying for years to get them to give it up, have it on my list to re-write in VFP just to get rid of it and the old XP machine that run a DOS emulator so they can use it !
 
Good luck with that D-Ward. I've converted many FPD/FPW2.6 apps to VFP. Never regretted any. FPW tends to be a bit easier to convert because of its visual/graphical nature, but if you have a good project created using the FP tools (Screens) and code is already in snippets (and not just a long .prg), then it's pretty easy to do. I've converted big apps in only a couple of days that way even. Just open them both in side-by-side screens, and makes it very easy to move the business logic from FP app to VFP app.

The biggest leap I had was the "Object Oriented" nature, and admittedly, that was a difficult leap that I only was able to make when I had about 2 months off after losing my job following September 11, so I had the time to invest in it, and I had a series of VFP training course on CD (that was for the "new" VFP6 at the time). I had used VFP3 and VFP5 on a limited basis mostly as a "better FPW", but my real leap to OO was around VFP6. If you've made that hurtle already, you're in a better position.

Can't remember the name of that course, and I know I still have it packed in a box in storage for about... 20 years now. ><
But it was awesome. Couldn't have done it without it.
 
Started with DBase III. Got introduced to FP 2.0 and started using that going forward. All versions of VFP except 8.0.
 
I started with MS Basic. I was programming for 8 bit microcomputers about 40 KB RAM, two floppy drives (8") and a printer. Atari 800 XL children's computer had better parameters.:)

In end of 80's Dbase II,III, Clipper DOS. A few years break for other systems (Turbo Pascal). In halv of 90's back to databases - FoxPro2.5, 6, 9.
 
Last edited:
Started with DBase III and Clipper in 1989, then FoxBASE 2.x, FoxPro 2.5/2.6, VFP 3.0 in 1997, ended with VFP 9.0 in 2019.
Now working in VB .NET (VS 2022).
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top