Tim

I'm testing an external function in EDBManager and to try and figure out what's wrong I added some showmessage's in. First time I press F9 I get a display for each record (still don't know what's going wrong mind you) but when I press F9 again NOTHING happens. Its as if EDBManager recognises I haven't changed the sql and decides not to bother. Alter the sql and I get my output again.

If this is intentional I have to say I do not like it. If I'm daft enough to run the exact same sql again I think I should be allowed to. Don't you?

Roy Lambert

Roy,

<< I'm testing an external function in EDBManager and to try and figure out
what's wrong I added some showmessage's in. First time I press F9 I get a
display for each record (still don't know what's going wrong mind you) but
when I press F9 again NOTHING happens. Its as if EDBManager recognises I
haven't changed the sql and decides not to bother. Alter the sql and I get
my output again.

If this is intentional I have to say I do not like it. If I'm daft enough
to run the exact same sql again I think I should be allowed to. Don't you?
>>

Well, EDB knows that the source data has not changed, so the results should
be the same.  If they aren't, then you're relying on functions returning
variable data with the same inputs, and that really violates what EDB
expects from a scalar UDF.  If you need to force it to run the query again,
just close the query window and then open/execute it again.  With 2.0 you'll
simply be able to UnPrepare the query and then run it again.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>Well, EDB knows that the source data has not changed, so the results should
>be the same. If they aren't, then you're relying on functions returning
>variable data with the same inputs, and that really violates what EDB
>expects from a scalar UDF.

Your assumption is incorrect. I'm trying to debug an external function into which showmessage has been added at strategic points. The other alternative could well be the base data has changed and I want to rerun the query to check on that being incorporated.

>If you need to force it to run the query again,
>just close the query window and then open/execute it again. With 2.0 you'll
>simply be able to UnPrepare the query and then run it again.

There's an easier method - just add/delete a meaningless space. But I think the point is you're trying to be to helpful and make a decision that's best left to the idiot pressing the buttons. Please please don't head down that MS route even this little bit.

Roy Lambert

Tim
And another one - I often want to compare speed of a couple of approaches and I generally run the sql until caching effects are maximised (ie 3 - 4 times) so I can compare as near to like as possible.


Roy Lambert

Roy,

<< Your assumption is incorrect. I'm trying to debug an external function
into which showmessage has been added at strategic points. >>

In that case, you'll have to force the query to be re-run.

<< The other alternative could well be the base data has changed and I want
to rerun the query to check on that being incorporated. >>

If the base data changes, then the query will re-execute.  EDB knows when
this occurs.

<< There's an easier method - just add/delete a meaningless space. But I
think the point is you're trying to be to helpful and make a decision that's
best left to the idiot pressing the buttons. Please please don't head down
that MS route even this little bit. >>

You're missing a lot of background here, but I'll just say that:

a) Forcing users to close/re-open a query in order to refresh it was a major
issue with DBISAM, and this EDB feature solves it

b) The way EDB works is required due to the fact that the underlying query
architecture is used for views also, and views need a) or else they simply
don't work.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>In that case, you'll have to force the query to be re-run.

Which is what I wanted to do but your suggestion "just close the query window and then open/execute it again" means either saving the query and reopening it or retyping. All I wanted to do was bash a key/click on a button.

>If the base data changes, then the query will re-execute. EDB knows when
>this occurs.

That explains why pressing F9 seems to work sometimes.

>You're missing a lot of background here, but I'll just say that:

Probably and it sounds as though I've hit a sore point - sorry.

>a) Forcing users to close/re-open a query in order to refresh it was a major
>issue with DBISAM, and this EDB feature solves it

Since I was never a big query user in DBISAM I never noticed

>b) The way EDB works is required due to the fact that the underlying query
>architecture is used for views also, and views need a) or else they simply
>don't work.

I'll take your word for that - haven't even looked at views yet.

What about an extra button - RERUN which will just close and open the query?

Roy Lambert

Roy,

<< Probably and it sounds as though I've hit a sore point - sorry. >>

No, not at all.  It's just that there's a lot of "internal engine" reasons
for the way that it works, and it's hard to explain entirely with reasons
that would be applicable to your needs.

<< I'll take your word for that - haven't even looked at views yet. >>

<< What about an extra button - RERUN which will just close and open the
query? >>

That's possible also, but it will also have to UnPrepare the query, so a
single UnPrepare button might be more feasible.

--
Tim Young
Elevate Software
www.elevatesoft.com