FiveTech Support Forums

It seems ACE 12 is installed and working.

Can you please let us know:
1. Does the file locations.dbf exist on local disk of network drive?
2. Do both the exe file and locations.dbf reside in the same folder on local disk?
3. Try ? oDbfP:cFile and let us know the result.

c:\temp should not be used to store dbf files and I don't think you really placed it there.

Please keep the dbf in some normal folder and in the USE command please give the full path and try.

Instead of
USE locations ALIAS Locations SHARED NEW

USE C:\<yourfolder>\locations ALIAS locations SHARED NEW

OK. The folder was just a phony, it is installed in a correct path.

Changed for USE (GetcurDir()+"\Location") ALIAS Location SHARED NEW as per your suggestion.

For me did not change anything: still working correctly and as before. Need to consult with the client.

Thanks for your time. Will report back

Changed for USE (GetcurDir()+"\Location") ALIAS Location SHARED NEW as per your

No.
This much work TDatabase itself does automatically.
I have some doubts on this.

ADO connection is to be created with datapath.

For now, kindly hard code the real folder with absolute path. Not even relative path.

cFile := "<fullabsolutepathwithdrive>\locations.dbf"

example: "c:\fwh\samples\customer.dbf"

if File( cFile )
USE ( cFile ) ............etc ...........
<other code>
else
? 'file not found'
endif

The problem here is that I do not know in advance where is the client installing it.

I can always ask him to install the application in a fixed, and known, path to test it and then use that to open the DB as you suggest.

What is also very strange is that I have 3 instances of the command SqlQuery in that piece of code and only 2 of them are returning the error in the client's machine.

Also try "SELECT [LOCATION]"

Here are my findings:
1. Installed on 8 different computers in Europe ranging from Windows XP, Vista, 7, and 8 32 and 64 bit working without a hitch using the following syntax:
USE (GetcurDir()+"\test.dbf") ALIAS test SHARED NEW
USE ("c:\test\test.dbf") ALIAS test SHARED NEW
or
USE test ALIAS test SHARED NEW
and then
DATABASE oDbfP
oDbfP:LOAD() // ? oDbfP:cFile
aCondic := oDbfP:SqlQuery( "SELECT Location") //or "SELECT [Location]" or even "SELECT [Location] FROM test"
oBrwD:aCols := {}
oBrwD:SetArray( aCondic )

1. Installed in America on 2 computers with Windows 8 64 bit will ONLY work using
   USE (GetcurDir()+"\test.dbf") ALIAS Test SHARED NEW
   or
   USE ("c:\test\test.dbf") ALIAS Test SHARED NEW
   or even
   USE (GetcurDir()+"\test") ALIAS Test SHARED NEW

Cannot use the 2nd syntax since I cannot force the user to install the program on c:\test

So if you use SqlQuery and have this strange problem now (thanks to Mr. Nages suggestions ) you know the answer.

Since I have to do tests that traverse the Atlantic Ocean I will have to settle with:

SET DEFAULT TO (cFilePath( ExeName() ) ) //taken either from an ini file or directly as an instruction

or just plainly

USE (GetcurDir()+"\test.dbf") ALIAS Test SHARED NEW

until I find out what's going on

Mr Ellano

1. cFilePath( ExeName() ) --> Fullpath where the exe resides
2. GetCurDir() --> Present directory.

Both can be different.

Important point:

For using SqlQuery, ADO connection needs to be established to the "folder" where the DBF resides.

If you want to use SqlQuery you better not use SET DEFAULT TO.
RDD can search SET DEFAULT path and open DBFs but TDatabase clas has to know what is the exact folder name to obtain a valid ADO connection.

Whichever folder you keep DBF files, keep that folder name in a global variable and open
USE ( cPath + "\MYDATA.DBF" ) ................

TDataBase class tries to obtain the folder name by calling
DBINFO( DBI_FULLPATH )
If a DBF is opened without building the correct path info while opening the DBF, there is no way TDataBase can establish a valid ADO connection.

After a 3 hour debugging session with my client using TeamViewer we finally understood what is going on with SqlQuery:

My client was using path structures such as “c:\my folder 2003\my version 4\program.exe” in such cases the program did not work at all.

If you changed the path to: c:\my_folder_2003\my_version_4\program.exe SqlQuery did not gave an error but did not fill the array, in the other hand if you simply changed the path to only one level to: “c:\my_version 4\program.exe” then SqlQuery suddenly started working, giving no errors and filling arrays correctly.

So there you are. Now I am forced to install the program in paths without spaces (no c:\program files\blah blah) and directly to the root until I (you) find the cause of this mischief .