![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB SQL » View Thread |
Messages 1 to 10 of 26 total |
![]() |
Sat, Mar 21 2015 6:32 PM | Permanent 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 PM | Permanent 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 PM | Permanent Link |
Aaron Christiansen | qryScript.SQL.Add(<query above>);
qryScript.ConvertSQL(); qryScript.ExecScript; |
Sun, Mar 22 2015 4:54 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | 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 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | 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 AM | Permanent 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 AM | Permanent 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 AM | Permanent 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 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | 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 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | 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 3 | Next Page » | |
Jump to Page: 1 2 3 |
This web page was last updated on Wednesday, August 14, 2024 at 07:31 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |