Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 26 total
Thread Empty SUB SELECT result causes "Cannot create file" error #600
Sat, Mar 21 2015 6:32 PMPermanent Link

Aaron Christiansen

I am running the following query:

DELETE FROM ChildTable WHERE ParentID IN (SELECT ParentID FROM Parent WHERE GrandParentID = 75);

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.


---------------------------
Debugger Exception Notification
---------------------------
Project fssm.exe raised exception class EEDBException with message 'ElevateDB Error #600 File manager error (Cannot create file C:\Users\ATOMIC~1\AppData\Local\Temp\AARON-MSI30082523350709797lob sensor app2.EDBTbl (OS Error: The system cannot find the path specified.
))'.
---------------------------
Break   Continue   Help   
---------------------------


Any suggestions on why this is borked?
Sat, Mar 21 2015 6:33 PMPermanent Link

Aaron Christiansen

PS. I only ever have these sorts of weird anomalies when time crunched and work due the following day :-/
Sat, Mar 21 2015 7:53 PMPermanent Link

Aaron Christiansen

qryScript.SQL.Add(<query above>);
qryScript.ConvertSQL();
qryScript.ExecScript;
Sun, Mar 22 2015 4:54 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Aaron


What happens if you run this as a query in EDBManager?

I just tried an equivalent query and it was fine.

Roy Lambert
Sun, Mar 22 2015 4:59 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Aaron

>qryScript.SQL.Add(<query above>);
>qryScript.ConvertSQL();
>qryScript.ExecScript;

Not sure of the point of this post but why are you converting a single line query to a script? All you're achieving is to make it a little more inefficient.

Roy Lambert

Sun, Mar 22 2015 6:27 AMPermanent Link

Uli Becker

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.

<<
Project fssm.exe raised exception class EEDBException with message
'ElevateDB Error #600 File manager error (Cannot create file
C:\Users\ATOMIC~1\AppData\Local\Temp\AARON-MSI30082523350709797lob
sensor app2.EDBTbl (OS Error: The system cannot find the path specified.
>>

If the path "C:\Users\ATOMIC~1\AppData\Local\Temp\" does exist, there is
maybe a problem with the blanks in the filename.

I don't know exactly how the temp files are named in EDB, but this e.g.
is a temp file from my computer( the computer's name is "VAIO-MOBIL",
the database nam is "Easymail"):

VAIO-MOBIL123925564181903781Easymail1054.EDBTbl

vs.

AARON-MSI30082523350709797lob sensor app2.EDBTbl

Does that help?

Uli
Sun, Mar 22 2015 9:48 AMPermanent Link

Aaron Christiansen

I hate this forum software and its lack of functionality like proper quoting, but thank you for the responses.

Uli, I get what you are saying, but consider that exactly the same query is run with exactly the same setup in every single regard.

The only difference between the error being produced or not is whether the sub select returns records or not.

So your point about spaces, or temp paths not existing, etc, seems to be irrelevant?
Sun, Mar 22 2015 9:53 AMPermanent Link

Aaron Christiansen

Roy Lambert wrote:

Aaron

>qryScript.SQL.Add(<query above>);
>qryScript.ConvertSQL();
>qryScript.ExecScript;

1. Not sure of the point of this post but
2. why are you converting a single line query to a script?
3. All you're achieving is to make it a little more inefficient.

Roy Lambert

1. To clarify what I meant by "running this query".
2. I'm not. When discussing bugs or issues, it pays to focus in on the single item that is causing problems. In this case there were numerous queries being run, but none of them had issues and were all working fine. Not a lot of point in posting 400,000 lines of code when the issue can be described in 4, correct?
3. Even if I was, it's irrelevant. But I am not. I did expect someone to avoid the issue at hand and complain about how I appear to be coding something. I did expect it to be you :D Thanks. I just earnt myself a milkshake :D

Yes, I did run it in DBManager. It ran fine.
Sun, Mar 22 2015 10:49 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Aaron


I do hope you enjoyed your milkshake. A small point about this newsgroup - we try to help, sometimes we get it wrong, sometimes we make fun of each other, but your post does nothing to encourage help.

>1. To clarify what I meant by "running this query".
>2. I'm not. When discussing bugs or issues, it pays to focus in on the single item that is causing problems. In this case there were numerous queries being run, but none of them had issues and were all working fine. Not a lot of point in posting 400,000 lines of code when the issue can be described in 4, correct?

You are certainly correct when you are absolutely positive that you have identified the actual cause of the problem and that you simply need help finding the solution. However, I doubt that you would need to post even 400 lines of code, BUT if a query is going wrong it reduces the probability of a correct solution being suggested if you don't post the query in its entirety.

>3. Even if I was, it's irrelevant. But I am not. I did expect someone to avoid the issue at hand and complain about how I appear to be coding something. I did expect it to be you :D Thanks. I just earnt myself a milkshake :D

Sorry you feel that way about a suggestion trying to make your coding more efficient.

>Yes, I did run it in DBManager. It ran fine.

In that case ITS NOT THAT LINE. I'm shouting deliberately. EDBManager is simply a Delphi application if it runs that sql code without problem then the cause is elsewhere. Please post the who of the query.

Roy Lambert
Sun, Mar 22 2015 11:10 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Uli


As you say its a temporary file name so the temp directory would have been a good guess.

Just after making my post above I had another couple of thoughts - it could be that ElevateDB isn't finding the path because it has spaces in it. However, if that was the case I'd expect a lot of complaints since I know there a quite a few people out there who will have spaces in table names.

My other thought, following Aaron's reply to me was this statement is one line in an old DBISAM style script and it could be that its relying on the existence of a temporary  table that is removed before the script tries to EXECUTE IMMEDIATE to the line needing it.

Roy Lambert
Page 1 of 3Next Page »
Jump to Page:  1 2 3
Image