Using dBase III+ within Win98

[Biggs]

I have a number of DOS-based dBase III+ programs that I wrote years ago for use in portfolio (investments) management. I was able to run these under Win95 from the START\RUN (path) mode without a hitch.

Recently, I have upgraded my computer OS to Win98SE. On attempting to run these dBase programs, I am coming up with error messages like "Cannot Access File" when the coding calls for a "USE xyz" do open a dBase file. (It does not say "cannot find file.&quot I would think that this is a system response, not a dBase response.

Some have told me that I cannot run DOS-based programs in a FAT32 environment. Others say that it's not a problem, if one isn't using disk utilities, or exceeding the 2mb limitation (which I am not).

Are there changes that are required for dBase III+ coding in order for it to run under Win98, if in fact it can run under Win98? Can the coding be upgraded (easily) to a later, more contemporary language? Or would this require an entire re-write of the coding?

Thanks for any assistance that one may be able to offer!

Gordon Biggar
Houston, Texas

 

[MiggyD]

Biggs:

First suggestion:
In your main PRG set the path to point to the specific directory. This would be the easiest solution--hopefully it'll work and you wouldn't need to recode much of anything.

Second suggestion: (If first didn't work)
If you have a shortcut in your START menu, edit the LNK/PIF so that the working directory is pointing to the actual directory of your PRGs and DBFs (hopefully, they in the same directory as that of your dbase.exe app--it would make it somewhat simpler if they were).

Last suggestion: (when all else fails)
Locate all you USE statements and put in a full path to file(s). This is more troublesome but should do the trick, as a last resort.

Hopefully, one of these steps helps you. If they do, please let us know by clicking below.

--MiggyD "The world shrinks more and more with every new user online."

 

[Biggs]

Sir Mig:

Good leads! As you can surmise, I am one of those "after hours" programmers, and we can be quite dangerous.

The fact that dBase opens up and executes seems to me to be a good omen. Under DOS and Win95, we had the dBase.exe file in one directory, and a host of sub-directories underneath with the specific dBase applications. I would then place an SCWD.exe file (residing in the root directory) in batch statements, before executing the specific dBase applications, that would permit the dBase programs in the lower-level directories to execute the dBase.exe routine without having to have it in each of the application directories, if you understand what I am saying. I have found that this concept has not worked for me in Win98. I have to copy the dBase.exe routine into each of the sub-directories for me to be able to bring up the dBase software. Seems inefficient, especially since the concept worked under Win95.

You mention about setting a path in the .prg programs, pointing to the specific directories in which the .prg and .dbf files reside. (All files for a specific application do reside in the same directory.) I'm not sure I understand the coding to which you are referring. Is it somewhat similar to the concept of a SET PATH statement in the autoexec.bat file?

If I have to use path names for each file statement (e.g., USE...) in the code, I will run into problems in later programs that were compiled in Clipper, and where I am executing the compiled code, and not the original source code (which has since disappeared). Hopefully, your path concept will obviate this problem!

Appreciate your inputs.

Regards,

Gordon

 

[MiggyD]

Yes, it's similar to the Autoexec's Set Path. I do not have any experience with Clipper, but I do have DB III+.

But, since you have DBASE.exe: Run DBASE.exe, press ESC to shut off "assistance" menues, at dot prompt type HELP SET PATH and it should give you the answers.

The proper syntax is:

SET PATH TO c:\MyDBase\MySubd~1\, <another search path>, et cetera.

If you still have problems or you need some more help with understanding the Help information, post here again.

--MiggyD
&quot;The world shrinks more and more with every new user online.&quot;

 

[Biggs]

MiggyD:

Some progress. Inserting the SET PATH TO statement has enabled the main application program to move among directories, calling in subroutines. (For example, I moved the main application up into the dbase.exe directory, and the application module that calls in sub-modules from lower directories works just fine.)

Having said that, all halts on the first USE statement (I am using a SELECT statement in front of it, followed by: USE xyz alias xyz). &quot;Cannot access file.&quot; I have tried inserting .dbf's into the coding, and I have even opened the dbase.exe routine by itself to see if I can access the .dbf file from the prompt; same message. I will try replacing the .dbf file, called in the USE statement, with a known good file, but I don't think that that's the problem, since the routine works fine within Win95.

Have you actually run dBase III+ programs under Win98 without having to change any of the coding? some changes? Maybe it's me!

Thanks.

Gordon

 

[MiggyD]

Question:

If you are using:

SET PATH TO C:\MYDBASE, C:\MYDBASE\DBFS, C:\MYDBASE\PRGS
SELECT A
USE Clients.dbf

Then, why are you using an ALIAS in the USE statement if it is already called with the SELECT function?

In the example above, I am instructing DBASE to create a workarea named &quot;A&quot; (the letter &quot;A&quot; is the ALIAS), then &quot;USE&quot; and store the &quot;Clients.dbf&quot; file in this workarea/alias. Essientially it turns out to be:

USE Clients.dbf INDEX FullName ALIAS A

The only difference is that the SELECT (x) is more pronounced and catches your eye faster than would USE. You may have to remove the ALIAS in the USE function --OR-- remove the SELECT function.

To see the Help files on this, use the procedure I mentioned above, and instead type HELP USE and/or HELP SELECT at the dot prompt.

--MiggyD

Hope this helps you some. &quot;The world shrinks more and more with every new user online.&quot;

 

[Biggs]

The coding that I have been using is as follows:

Select 1
**** Use stk_data.dbf alias stk_data.dbf
Use stk_data.dbf
Delete all
Pack
****Select stk_data.dbf
Select 1

Although it's been a number of years, I believe the reason that I used &quot;aliases&quot; was that when accessing some ten different data files, it was easier to refer to the name of the file than its number when doing the coding/debugging. It has obviously worked all these years, so the coding itself cannot be at fault, although it may be cumbersome to a professional.

As you can see from the above, I stripped out my coding and just used the Select statement without the alias. Progam stops at the same Use statement with the same error message. It is not a &quot;File Not Found&quot; message, but &quot;Cannot Access File.&quot;

Gordon

 

[MiggyD]

Well Biggs,

I'm at a loss. My only recommendation is that you try tracing the program (I don't know if Clipper lets you do it, though), using the following syntax a few lines before you acutally have the USE statement.

[using DBASE.EXE]
SET ECHO ON
SET TALK ON
SET STEP ON
.
.
SELECT CLIENT
USE Client.dbf
.
SET STEP OFF
SET TALK OFF
SET ECHO OFF

That's the best I can offer.

--MiggyD &quot;The world shrinks more and more with every new user online.&quot;

 

[Biggs]

MiggyD --

Many thanks for trying. Program does stop on the USE statement. Some are telling me that it's a FAT32 type of error message, particularly since it flies right through under Win95.

Back to DOS...

Gordon

 

[MiggyD]

Biggs,

You mentioned an interesting point I hadn't considered. Are you using the 16bit pathnames versions like:

USE C:\MyDocu~1\DataFi~1\Client.dbf

-[red]or[/red] are you using the 32bit version-

USE C:\My Documents\DataFiles\Client.dbf

That may be the problem. Or at least &quot;A&quot; problem.

-MiggyD &quot;The world shrinks more and more with every new user online.&quot;

 

[DaveGoTech]

We had similar problems with dbaseIII+ programs running under Windows 98. After much troubleshooting and, as a last resort, a call to MS Tech Supt, the tech finally admitted Win 98 is getting distant from DOS and could not be easily fixed. Converting to a more contemporary language will need a complete rewrite. You can upgrade to version IV, which has a compiler, or, better yet version 5 for Windows.