-> Uli Becker wrote:
->
-> Aaron,

-> I know this error from applications where the engine's "TempTablesPath"
-> was automatically set at design time, but not existent on another
-> computer where the application was executed.
-> Maybe you ran into the same problem. If so, just use this:

-> procedure Tdm.MyEngineBeforeStart(Sender: TObject);
-> begin
->    MyEngine.TempTablesPath := Engine.GetTempTablesPath;
-> end;

-> to avoid the problem.
--------------    --------------    --------------    --------------    --------------    --------------    --------------    --------------    
What was confusing to me is the database and the session temp table paths were pointing to

'C:\Users\Aaron\AppData\Local\Temp\'

in the object inspector. I was under the impression that the value set there was the value being used. Now that I am awake and have caught up on some sleep debt, it appears that the value when running the app is different to the value viewed in the object inspector. Namely:

'C:\Users\ATOMIC~1\AppData\Local\Temp\'

Which does not exist, and therefore generates an error.

Why one query required a temp table and not the other would be nice to know, but not necessary. Running the bit of code suggested by Uli above worked, and forces the db component to use the path that is in fact set at design time correctly, but then ignored at run time.

Do you think it's ok to have that initialisation code in the DataModule create event? I have all my other initialisation code in there and like to keep similar things all in one place.

Thanks for your help Uli.

Aaron

>What was confusing to me is the database and the session temp table paths were pointing to
>
>'C:\Users\Aaron\AppData\Local\Temp\'

I assume you're referring to the engine and the session because as far as I know the database does not have a TempTablesPath

>in the object inspector. I was under the impression that the value set there was the value being used. Now that I am awake and have caught up on some sleep debt, it appears that the value when running the app is different to the value viewed in the object inspector. Namely:
>
>'C:\Users\ATOMIC~1\AppData\Local\Temp\'
>
>Which does not exist, and therefore generates an error.

I only have the standard version so only limited source but looking in there I can see no reason for what you're experiencing. I've been caught a few times by setting the TempTablesPath for one PC then moving to another where that path doesn't exist. I've also forgotten that I need to set it in the EDBSession when I
have UseLocalSessionEngineSettings set to True.

>Why one query required a temp table and not the other would be nice to know, but not necessary. Running the bit of code suggested by Uli above worked, and forces the db component to use the path that is in fact set at design time correctly, but then ignored at run time.

Roughly speaking if a query produces a sensitive result its equivalent to setting a filter on a table and it won't generate a temporary table otherwise it will.


>Do you think it's ok to have that initialisation code in the DataModule create event? I have all my other initialisation code in there and like to keep similar things all in one place.

I do.

Roy Lambert

Aaron Christiansen wrote:

> Are you speaking for elevate?

These are peer support newsgroups. I'm a happy user of the Elevate
Software products, and try to help out other users when I can. I also
appreciate whatever help others give me. But I do not speak for Elevate
Software, no.

--

Matthew Jones

Aaron


Just a thought - you should report this to Tim as a bug. Its inconsistent behaviour and may well affect others.

Roy Lambert

Roy,

there is no bug to report. Just for you:

<<
.... it appears that the value when running the app is different to the
value viewed in the object inspector. Namely:
>>

That is simply wrong.

When the engine is initialized in Delphi (after creating it on a form
e.g.), the default Windows Temp-path is used for the engine's
TempFilePath. If you run the application on another computer where this
path does not exist, you'll get an error. That's what our friend
experienced. A simple double check would have shown him where to find
the culprit.

If you use the function GetTempTablesPath of the Engine, this code is
executed in the edbenv.pas:

function TEDBEnvironment.GetTempDirectory: String;
var
   TempBuffer: array[0..MAX_PATH] of Char;
   ResultLength: Integer;
begin
   FillChar(TempBuffer,((MAX_PATH+1)*SizeOf(Char)),0);
   {$IFDEF UNICODE}
   ResultLength:=Windows.GetTempPathW(MAX_PATH,@TempBuffer);
   {$ELSE}
   ResultLength:=Windows.GetTempPathA(MAX_PATH,@TempBuffer);
   {$ENDIF}
   SetLength(Result,ResultLength);
   Move(TempBuffer[0],pChar(Result)^,(ResultLength*SizeOf(Char)));
end;

As you see it's the same default Windows Temp-path as before except that
it's always valid for the computer on which you are running the application.

The only question is, whether or not the path should be "corrected" by
the engine if it's not valid at runtime. That was discussed earlier.

Regards Uli

Uli


>there is no bug to report. Just for you:

Unless I missed something, or am miss-interpreting something I think there is a bug

<<If the subselect returns records, it executes fine.

If the subselect returns no records, it generates the following error, which was incredibly frustrating to track down as to cause and I am clueless as to why this is the case.>>

Which I took  to mean as running on the same PC and working in one case but not the other. Hence creating a temporary table when there is no result from the subselect and not when records are returned.

Roy Lambert