Hi,
a customer gets this error message:
ElevateDB Error #600 File Manager error (Cannot create file C:\Users\ADMINI~1\AppData\Local\Temp\2\SERVER1664091762760122865isyControl1.EDBTbl (OS Error: Das System kann den angegebenen Pfad nicht finden.))

(OS Error translated means "Path cannot be found")

This happens when executing this statement:
SELECT * FROM Information.Tables WHERE Name = 'Files'

It happens only with this customer, normally it works fine.

The Folder "2" under C:\Users\ADMINI~1\AppData\Local\Temp did not exists. When I created it manually, the error didn't appear any more and everything worked.

Is there a problem with determining the Temp path or why does EDB here use a non existing temp path?

OS is Windows Server 2003

Burkhard


You haven't said where this is occurring wether its your application or EDBManager. Whichever, I suspect that the answer is the same - someone has altered the temp table path. When an engine / session component is dropped onto a datamodule / form it will pick up the temp table path at the time. EDBManager & EDBsvr both have ini files in which the temp table path can be set. These may have been altered.

If you don't set the temp table path at application start it will stay the same as set when the program was compiled - that's caught me several times.

Roy Lambert

Burkhard,

Roy is correct.  If you have a TEDBEngine component placed on a form or data module, then use this code to fix the issue:

MyDBISAMEngine.TempTablesPath:=MyDBISAMEngine.GetTempTablesPath;

Frankly, I'm probably going to make this property public at some point in the future to avoid this issue.

The same holds true for the TEDBSession.LocalTempTablesPath, which will have the same issue if your engine component's UseLocalSessionEngineSettings property is set to True.

Tim Young
Elevate Software
www.elevatesoft.com

Thank you Roy and Tim.

Some additional information:
It occurs in my application. It's a small tool that is called by my Inno-Setup script and that does some DB related things after installation of my main application. SessionType is stLocal an I use the default EDBEngine, no TEDBEngine component.

So I think, there is no possibility to change the temp path. The user runs the setup and that's it.

Is is possible that a configuration mismatch on the users machine causes this problem? For example that the TEMP environment variable is not set properly or something like that?

Burkhard

>Some additional information:
>It occurs in my application. It's a small tool that is called by my Inno-Setup script and that does some DB related things after installation of my main application. SessionType is stLocal an I use the default EDBEngine, no TEDBEngine component.
>
>So I think, there is no possibility to change the temp path. The user runs the setup and that's it.
>
>Is is possible that a configuration mismatch on the users machine causes this problem? For example that the TEMP environment variable is not set properly or something like that?

Very probable. Mine for example is set to Z:\TEMP. Its done that way because I have an SSD and this moves the temp writes over to a spinning rust drive. I've done much the same with the pagefile.

You basically need an extra line in your script. If you haven't an engine component on a form then

Engine.TempTablesPath := Engine.GetTempTablesPath

should do it.

Roy Lambert

Tim

>MyDBISAMEngine.TempTablesPath:=MyDBISAMEngine.GetTempTablesPath;

<giggle>
DBISAMEngine in an ElevateDB discussion
</giggle>

Roy

Roy,

> You basically need an extra line in your script. If you haven't an engine component on a form then
>
> Engine.TempTablesPath := Engine.GetTempTablesPath

OK, but what I don't understand is the following:

The documentation says:

>-----
property TempTablesPath: String
Usage
...
By default, the TempTablesPath property is set to the user-specific temporary tables path for the operating system.

and

function GetTempTablesPath: String
Usage

Call the GetTempTablesPath method to return a string with the location of the operating system's default temporary files path for the current user.

>------------

This should be the same. So when TempTablesPath is already set to the user-specific temporary tables path by default, what effect has Engine.TempTablesPath := Engine.GetTempTablesPath?

Or when I look at the Sourcecode of EDB I see that FHandle.Environment.TempDirectory is both used in the initialisation of TEDBEngine an in the function GetTempTablesPath. So what is the difference?

I just had a look at the source of GetTempDirectory.
It uses the windows function GetTempPathW or GetTempPathA. I suppose this function returns that incorrect value on this particular machine for what reason ever.
I'll try to check that, if the customer lets me do so.

Burkhard Schneider wrote:

> This should be the same. So when TempTablesPath is already set to the user-specific temporary tables path by default, what effect has Engine.TempTablesPath := Engine.GetTempTablesPath?

The key, as Tim has alluded to, is that because this is a published property, when it is in your IDE, it gets the default of the temp location on your computer. And it then remembers it. So when your application is moved to a computer with different temp location, it is now wrong. By making it public instead of published, it will pick up the new system's default, unless you want to put it somewhere specific.

Me, I set it to a sub-directory of the database files (e.g. C:\MyData\Temp ) so that I can delete everything in it at the start of execution, thus ensuring my application is nice and tidy and doesn't leave temp files around forever, which you cannot do in the system temp location.

--

Matthew Jones

Burkhard

>I just had a look at the source of GetTempDirectory.
>It uses the windows function GetTempPathW or GetTempPathA. I suppose this function returns that incorrect value on this particular machine for what reason ever.
>I'll try to check that, if the customer lets me do so.

Waste of time -T he routine I have used for ages goes back to

function GetTempPath; external kernel32 name 'GetTempPathA';

and over 20 years, at least as many different PCs, networks and stand alone I've never had a problem with it.


Roy Lambert