(Disclaimer: Analogies between .Net framework and VFP is not one to one match, similarity and unofficial)
In C# when you compile a solution (VFP project - "solution" do not exist) the result is an exe (PE) and even if you delete all the source files it'd run. PE knows the file locations (more precisely it doesn't need locations/files anymore). In VFP files are compiled on the fly and run (but compiled files are not in a single exe unless you build an exe). That means VFP needs to access source or compiled versions if you're not running an EXE (and I assume you're not running an EXE, trying to run it from within IDE with something like "do main.prg").
Like C# IDE's solution explorer, VFP's project keeps track of files' locations. However if you:
and a line refers to a file that's not in current 'search path', project wouldn't help it to locate the file (you're somewhat running it independant from project, project knows the place but it just isn't helpfull). For example at a line:
set procedure to jbprocs
would error if jbprocs.prg is not in 'search path'. And it's not different than you're trying the same line at comman window (VFP is an interpreted and interactive language - you could execute each line in command window, except loops which require to be executed in blocks, simply that's doable too but beyond this message).
To workaround this is fairly easy and can be done in more than one ways:
1) VFP uses 'search paths' to locate files. It's a combination of VFP's own search path and DOS search path. This is generally the easiest and preferred solution.
-Open the project and note the files' locations. Say files are in "c:\my Path\Forms", "d:\my Path\commonProgs" etc.
You can build a search path separating paths with a semicolon and keep it in a prg file to restore on demand. Go to comman window and execute:
_cliptext = set("path") && VFP's current search paths
modify command myPath && create a prg which you can run whenever you want to set paths for testing
Paste in code window opened and after putting a semicolon at the end add yours that you noted above:
...;c:\my path\Forms;d:\my Path\commonProgs
Ctrl+W to save and exit.
would set those search paths. Now you can run your app with do main.
2) You could hardcode the paths (and no need to explain to a developer what a worst choice it would be to hardcode paths but it works and I wanted to note that workaround too:)
set procedure to ("c:\my Path\my Progs\jbProcs") && VFP is case insensitive and for a procedure file .prg is default extension
3) Yet another quick and dirty solution, you could create a test folder and copy all project files to that single folder. Change your current directory to test folder:
set default to ("c:\My Work Path\Test") && or: cd ("c:\My Work Path\Test")
and run do main.prg. VFP wouldn't complain not finding the files this time because due to VFP's behavior even if a file's path were hardcoded, it uses the file it finds in its search path when it cannot find it in hardcoded path.
As you, I think jbprocs is named that way because the developer had initials JB:) I use cb_ similarly in different places (like property names to differentiate from built-in ones). You can think of it as a way to 'invent' namespaces:)
PS: (this is easy to say but not as easy as to do:) Can't you directly do a rewrite with ASP.Net, windows forms and web services in mind from the start Upsizing VFP's data (especially with VFP's own upsizing wizard) to SQL server w/o rearchitecting might be inefficient. I don't know, just thinking, within context of many new features of SQL2005. Even with SQL2000 I was writing my own upsizing with rearchitecting (and own code generators to cut down writing all those .sql). Good luck, you have an hard task.