Roy Lambert wrote:

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.
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----

Been here more than a few times, and knew you'd
1. have a go about the code, for whatever reason, despite what ever you have to say being irrelevant
2. be all defensive about my knowledge of your posting style and response when I express displeasure at your attitude.

It's a struggle for me to post for help here because I just know you're going to post about irrelevant things that have absolutely nothing to do with the issue I am having? Talk to me like I am some kind of idiot. And by the time I am posting here, I am already frustrated and worn out, and have no patience for it. So respond. Stupid, I realise, but it is what it is.

If you do not want to help, that's fine by me. Saves me having to defend snippets of code that exemplify a potential bug or anomaly as if my entire app is programmed like that.

I am sorry you do not understand the issue at hand, but I cannot make it any clearer or simpler.

Hopefully Tim or someone can chime in at some stage.

> 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?

Possibly there is no temporary table created when there are no records
returned by the subselect.

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.
------------------ ------------------ ------------------ ------------------ ------------------ ------------------

I am not sure how the temp table names are generated, looks like they use the signature? The temp path is the same for the 2 queries with identical format and settings that run, where one generates the error and the other does not.

Good to know about this GetTempTablesPath; function - I have not had any such issues (this current issue is occurring on my dev machine btw) but will keep it in mind if it crops up in the future.

Uli Becker wrote:

> 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?

Possibly there is no temporary table created when there are no records
returned by the subselect.
--------- --------- --------- --------- --------- --------- --------- --------- ---------
Yeah I am not sure. Doing more investigation now, and it's even more curious.

I have 2 queries with the exact same format from OP.
1 query generates the error whether the subquery has records or not.
The other query runs fine, whether it has records or not.

3:20am now and time to go to bed. Luckily I can ignore the bad query and rely on the parent records being deleted to take care of the display of the child records (mwuahahahaha ahem) but obviously long-term I need to reconcile the issue and solve it.

Thanks for your help.

>>Yes, I did run it in DBManager. It ran fine.
> In that case ITS NOT THAT LINE. I'm shouting deliberately.

You're shouting because you are very confident and somewhat arrogantly assuming you know everything there is to know about ElevateDB. It is that line. I am not an idiot. Stop treating me like one.

Thank you.

Aaron Christiansen wrote:

> It's a struggle for me to post for help here because I just know
> you're going to post about irrelevant things that have absolutely
> nothing to do with the issue I am having?

If I may say, that is all quite unfair. Sure, we understand the
frustration of code not working, and of people putting forward ideas
that don't seem relevant. But please remember we don't have anything
like the understanding of your code that you do. You have it in the
debugger, the full data, and everything you could possibly want to
know. We have a snippet of the details of a problem. Of course we are
going to have only possibly relevant suggestions. Feel free to ignore
those. But often these things trigger a thought that brings the
solution.

If you want some consultancy, I'm sure there are a few people willing
to charge the appropriate amounts to dig deep and help out. But
complaining about free help given in our spare time is not the way to
go about getting more.

--

Matthew Jones

Aaron,

> I am not an idiot.

What else?

Aaron

>>>Yes, I did run it in DBManager. It ran fine.
>> In that case ITS NOT THAT LINE. I'm shouting deliberately.
>
>You're shouting because you are very confident and somewhat arrogantly assuming you know everything there is to know about ElevateDB. It is that line. I am not an idiot. Stop treating me like one.

ElevateDB is simply an application written in Delphi. If a piece of SQL runs in ElevateDB, and doesn't run in your application there's a very good chance that your application is wrong.

Try capturing the sql after running ConvertSQL and running the full script in ElevateDB and see if it gives you a better idea where the problem lies. If that runs correctly the problem lies outside of ElevateDB.

Roy Lambert

>Uli Becker wrote:
>Aaron,
>> I am not an idiot.
>What else?


I am not understanding you. What else what?

"Matthew Jones" wrote:

Aaron Christiansen wrote:

> It's a struggle for me to post for help here because I just know
> you're going to post about irrelevant things that have absolutely
>> nothing to do with the issue I am having?

>If I may say, that is all quite unfair.


Are you speaking for elevate?