Hi Team,
   Having a play with this new LoggedStatements and perhaps I don't understand what is supposed to happen.
   
   Working in EDBMger v 2.30 and in Local mode I did the following..
      1.   I ran the following SQL - "Enable statement logging".
      2.   I then ran - "Select * from Jobtickets".
      3.   I then ran - "SELECT * FROM Configuration.Loggedstatements"

   And got an empty result set.

   OK.  Happy to acknowledge I don't now what I am doing...

   What sort of Statement will produce a result set in the Loggedstatements?

Regards & TIA,
Ian

I also discovered you need Administrator privilages.

Most of my Apps don't have Administrator Privilages and therefore something like

{sql}
EDBDatabase.Execute('Enable Statement Logging');
{sql}

isn't accepted.

Don't really want to give the Apps Admin Privilages.

And Yes, I know the Doc says..

"Required Privileges
The current user must be granted the system-defined Administrators role in order to execute this statement. Please see the User Security topic for more information."

I really want to give the Apps Admin Privileges.  I am currently talking 15 Apps with, att, 18 Users able to use any of them at any point in time..  Again, all in Local mode.

Is there a way to give EDBDatabase a temporary Admin Privilege just for this purpose?.

Perhaps this setting could be made persistent somewhere/somehow?

On 1/5/2019 4:22 PM, Ian Branch wrote:
>    Having a play with this new LoggedStatements and perhaps I don't understand what is supposed to happen.
>    
>    Working in EDBMger v 2.30 and in Local mode I did the following..
>       1.   I ran the following SQL - "Enable statement logging".
>       2.   I then ran - "Select * from Jobtickets".
>       3.   I then ran - "SELECT * FROM Configuration.Loggedstatements"
>
>    And got an empty result set.
>
>    OK.  Happy to acknowledge I don't now what I am doing...

By default it only logs statements longer than 30 seconds so unless your
select took that long it would not be logged.

Try something like "ENABLE STATEMENT LOGGING MINIMUM EXECUTION 1" and
then run something that takes few seconds

Reference:
https://www.elevatesoft.com/manual?action=viewtopic&id=edb2sql&topic=ENABLE_STATEMENT_LOGGING

Raul

On 1/5/2019 4:33 PM, Ian Branch wrote:
> I also discovered you need Administrator privilages.
> Most of my Apps don't have Administrator Privilages and therefore something like
> Don't really want to give the Apps Admin Privilages.

IMHO this is more of an admin level capability anyways so you enable it
when  troubleshooting performance issues (and on edbsrvr). If you have
just local sessions then yes it's trickier.

Default execution time is long enough that you'd then see if anything of
worthy got logged after maybe a day or few.

Raul

Raul wrote:

> By default it only logs statements longer than 30 seconds

Ahhhh.  Doh! on me.

Made one and it works.
Tks Raul.

Hmm.  OK, it is working in EDBMger. I created a query that takes 14secs and it shows when I run "SELECT * FROM
Configuration.Loggedstatements"

Given that it is there I had expected to be able to see it in the App viewing Configuration.LoggedStatements but no.

Both the App and EDBMger aure using the standard Admin user ID & Password.

When I run the App it shows the fields in the browser OK but no records.

I am still missing some aspect.

Does the App need to specify the enable logging in and of itself?

On 1/5/2019 9:14 PM, Ian Branch wrote:
> Given that it is there I had expected to be able to see it in the App viewing Configuration.LoggedStatements but no.

I have not used this so speculation only at htis point but ...

Looks like this data is stored is stored by engine and likely runtime
only and not persistent.


> Does the App need to specify the enable logging in and of itself?

Looks like 2 questions actually

1. How is it stored - based on your test above using EDBMgr is per
engine and what looks like runtime only so if your app uses local
session it would only see it's own logged statements

2. Again for local sessions the engine is embedded in app so each of
your apps has separate engine and thus would need this enabled in the
app (to enable it for engine)

It looks to me that this would be really useful for C/S but local
sessions are lot more limited on what you can get and do.

Raul

Raul wrote:
>
> I have not used this so speculation only at htis point but ...
>
> Looks like this data is stored is stored by engine and likely runtime only and not persistent.
>
I.B. - This would make debugging a User's issue problematic I feel.

>
> > Does the App need to specify the enable logging in and of itself?
>
> Looks like 2 questions actually
>
> 1. How is it stored - based on your test above using EDBMgr is per engine and what looks like runtime only so if your
> app uses local session it would only see it's own logged statements
>
I.B.  I was hoping it would be stored like the Events Log, so it could be reviewed/analysed later.  I just exited
EDBMger from my previous testing and restarted it, did the "SELECT * FROM Configuration.Loggedstatements" and no
results.   Looks like it isn't persistent.

> 2. Again for local sessions the engine is embedded in app so each of your apps has separate engine and thus would
> need this enabled in the app (to enable it for engine)
>
I.B. - I had EDBMgr open when I ran the App, that is why I expected to be able to see the entry.

> It looks to me that this would be really useful for C/S but local sessions are lot more limited on what you can get
> and do.
>
I.B.  I hope not.

On 1/5/2019 11:40 PM, Ian Branch wrote:
>>
> I.B. - This would make debugging a User's issue problematic I feel.

Yes not local but not for C/S.

> I.B.  I was hoping it would be stored like the Events Log, so it could be reviewed/analysed later.  I just exited
> EDBMger from my previous testing and restarted it, did the "SELECT * FROM Configuration.Loggedstatements" and no
> results.   Looks like it isn't persistent.

Thanks for checking and looks that way.


> I.B. - I had EDBMgr open when I ran the App, that is why I expected to be able to see the entry.

Yes but IF both are using local sessions then they are completely
separate engines so you would see across using local sessions.

Engine is the EDB code embedded in the app and not the config database.

In case of C/S i assume the edbsrvr engine is the one storing this so
you could query across - would need to confirm though.

Raul