execution_contexts add a new column

mrbdrm

what need to be done before adding a new column to the execution_contexts table?
if i add the column in the database and try to login i get this MySQL error

Unable to persist process context Column count doesn't match value 1

my idea is to add a TIMESTAMP column and clear records after a specific time passed with no change using triggers.

i can tell you for sure aware dose not like large documents at all or handle viewing them too.

customaware

Whoa! that sounds Spooky.... fiddling with the Execution_Contexts table... Eeekk.

Scares the hell out of me.... 😉

Jaymer

Mark, I don't think Aware handles database tables the same way we're used to Magic handling Btrieve files.
(ie. conditions that would create a File Definition Mismatch Error)
Because you can add fields and indexes to a SQL Server table and AIM isn't aware of it, and I don't think it cares.

For SOME REASON though, it seems that Vlad IS CHECKING that context table (how could he have anticipated someone altering the table and adding a field?) explicitly for 1 field - thats unfortunate, cause I think that was a good idea.

Yet I think Vlad would disagree that its even needed, or he would have put something like in there a long time ago.

BUT, if he IS checking that error condition, and maybe its legacy code thats not really needed anymore, he could easily remove it in the next build. He (Vlad) could even add the timestamp to that file

jaymer...

Jaymer

ok, i just wasted 45 minutes dicking with this.
i installed Sales Portal and ran it and explicitly ran some procedures, and it doesn't even have EXECUTION CONTEXTS as a file.

And I checked another test BSV and it didn't either.
I wasnt going to mess with any production tables.

Also, here's what EXECUTION CONTEXTS looks like.
It has more than 1 column to begin with, so I don't understand that error msg.

mrbdrm

Jaymer wrote
Mark, I don't think Aware handles database tables the same way we're used to Magic handling Btrieve files.
(ie. conditions that would create a File Definition Mismatch Error)
Because you can add fields and indexes to a SQL Server table and AIM isn't aware of it, and I don't think it cares.

For SOME REASON though, it seems that Vlad IS CHECKING that context table (how could he have anticipated someone altering the table and adding a field?) explicitly for 1 field - thats unfortunate, cause I think that was a good idea.

Yet I think Vlad would disagree that its even needed, or he would have put something like in there a long time ago.

BUT, if he IS checking that error condition, and maybe its legacy code thats not really needed anymore, he could easily remove it in the next build. He (Vlad) could even add the timestamp to that file

jaymer...

Vlad isn't checking. its the insert SQL statement that should be like this:

insert into table_name (column_name1, column_name2)
values (1, 3)

guess Vlad never think anyone will touch the table.
but the insert statement SHOULD be like the above, that is the correct why to use INSERT.

Jaymer

ohhh,
i'm not sure I'd add the TimeStamp inside AIM

I thought you'd add it (the timestamp field) via SQL tool,
populate it with Database rules,
and then have SQL stored procedure/trigger monitor it.
Leave AIM out of the loop

mrbdrm

Jaymer wrote
ohhh,
i'm not sure I'd add the TimeStamp inside AIM

I thought you'd add it (the timestamp field) via SQL tool,
populate it with Database rules,
and then have SQL stored procedure/trigger monitor it.
Leave AIM out of the loop

awareim is stooping me from adding the column from MySQL tool that's the issue.
i am trying to do exactly that you have described

Jaymer

Jaymer wrote
ohhh,
i'm not sure I'd add the TimeStamp inside AIM

ok, i guess it was too early in the AM. Cause I don't know how you'd do this anyway.
So, I guess its up to Vlad to chime in at this point.

mrbdrm

i have found a way to clear the table from MySQL, this is how if anyone want to use it.

1- create a Stored procedure with this code:

CREATE DEFINER=`root`@`%` PROCEDURE `live_procedure`()
BEGIN
IF ((SELECT COUNT(id) FROM execution_contexts)>10)
THEN
DELETE FROM execution_contexts ORDER BY id LIMIT 1;
END IF;
END

2- setup an event to run the stored proceduce:

CREATE EVENT myevent
    ON SCHEDULE EVERY 120 SECOND
    DO
      CALL live_procedure();

this will check every 129 seconds and if the table have more than 10 records it will delete the lowest id record.

hope this help.

RLJB

mrbdrm... this is an interesting comment "i can tell you for sure aware dose not like large documents at all or handle viewing them too." ... why do you say that? what is your experience?

fyi - we have noticed some activity that "may" lead me to think the same thing, I would like to hear your reasoning.

Thanks

mrbdrm

not sure how but i know aware insert the file data into the database table every time someone ask for the file.
that is fine for small files and low requests. but not great for large files and high requests number.
when too much requests come aware will leave some rows on the table and not clear them correctly. over time the system slow down.

may not be correct 100% but that my observation over the time.