I'm not finding any existing threads covering this, other than that related to anti-virus which is not an issue.

The above error happens when running the "dbsys" utility connected to a database using the "Internet" option trying to execute "select * from cost". When connected to the same database using the "Local" option, the SELECT statement succeeds. I can open the "cost" table without issue regardless of "Local" or "Internet" option selection.

I've tried changing the FROM clause to use double quotes, square brackets, remote DB path, and absolute path getting the same error.

Executing "select * from dummy" I get "DBISAM Engine Error #11010 Table 'dummy' does not exist". There are a large number of tables in the database, and using any "valid" table name produces the subject error, while an invalid table name yields the expected message.

Dbsvr, version 3.30, is running on Windows 2008 R2 64-bit system as an NT Service using the local SYSTEM account. The SYSTEM account has full access to the database folder and private folder and basically any folder anywhere near the database.

Thanks for any help.

William


Unfortunately you seem to have ruled out the easier options (antivirus & permissions). You specify DBSys having the problem so I assume that your application doesn't, add in the fact that its a temporary table causing the problem (ie you're selecting fom costs but its 56400 giving  the error) suggests that there is something different between DBSys and you application - assuming that both are being handled by the same server.

Bit waffly, and I'm probably insulting you because you seem to know what you're doing but my plan of attack would be:

1. make sure DBSys and your program are pointing at the same data
2. try the query but ask for a live/sensitive result set (that should eliminate the need for the temporary table
3. run DBSys on the server with the query asking for a canned result set
4. look for any differences between server/program & DBSys for permissions etc

Roy Lambert

Roy Lambert wrote:

> add in the fact that its a temporary table causing the problem

I wonder if that is the problem - the temporary directory not having
the proper permissions. And the temporary directory default changed a
while back didn't it? Certainly worth a check.

--

Matthew Jones

Matthew

>I wonder if that is the problem - the temporary directory not having
>the proper permissions. And the temporary directory default changed a
>while back didn't it? Certainly worth a check.

Its possible which is why one of my suggestions is to run DBSys on the server machine. Its also possible that rather than "permissions" its "sharing" (and yes I know they are both the same but I think of them differently

Roy Lambert

Thank you both for the quick replies.

The live result request was able to perform the select. I checked dbsrvr options and found that it was configured to use C:\WINNT\Temp. I changed this to a valid folder, and everything is now working. I never even thought about the temp folder option setting used by dbsrvr. Duh!

Thanks again.

William


On my work machine I have ab SSD and an HHD. The HHD is set as Z, the SSD has 4 partitions C,D,E,F

If you think you've just had fun try creating a VM from C when the Windows temp file is set to Z:\Temp

Roy Lambert