Save() me

[barrymavin]

Hi Simon,

Rebuilding the database has nothing to do with triggers.

I cannot see any issues with table triggers. They are all working for me. Records are only updated if they contents have been changed.

[SpringBox]

Hi Barry

Run out of ideas now regarding the illusive onafterupdate trigger. Spent days on this & done everything we can think of - rebuilt database & tables from scratch again. ZAPped all the records, reindexed & started again. There are NO dbc triggers now, just table triggers.

We can get the table onbeforeupdate trigger to fire every time from either the console or the UI but we can NEVER get the table onafterupdate trigger to fire from either the console or UI.

Obviously we cannot use the onbeforeupdate trigger to call server side routines as the data has not yet changed and issuing a SKIP 0 in the onbeforeupdate trigger will just put us in a loop.

Have just sent you the small sample data in a ticket. Can we please find out why the onafterupdate trigger won't fire. Is there something extra we need to do to make the onafterupdate fire?

We are so nearly there...

Cheers



Simon

[SpringBox]

Thanks Yvonne for pointing out that the onafterupdate trigger was out of synch / not connected properly to the table.

We assumed that the interactive trigger setting would always match but now we know that it is safest to use command lines

ie

open database test
use cust excl
disp dict
alter table cust drop cust_onafterdelete
alter table cust modify onafterupdate "cust_onafterupdate"
alter table cust modify OnBeforeUpdate "cust_onbeforeupdate"
disp dict

etc.

Now works brilliantly - so simple when you get your head round it. Coupled with virtual tables it makes keeping in sych with legacy systems so much easier.

Thank you

[SpringBox]

Hi guys

The BeforeUpdate and AfterUupdate normal table triggers work great in desktop in both dev and runtime - thanks for the pointers.

However we cannot get them to fire in web. Is there something extra we have to do in web to get them to fire?

No errors are reported in browser - they just don't seem to fire and we have checked that the trigger .prgs have been deployed.

Our code creates the VT in server side proc called from the AfterUpdate table trigger - we can't see any reason whey this should be any different in web.

We call :

DO ExportDataVT WITH cust.cust_id

In desktop the value of cust.id passed as a parameter makes sense. Would that still be the case in web ie in web would the current value of cust.cust_id be in scope and correct?


Thanks in advance

Simon

[HankFay]

Hi Simon,

In what directory do you have the trigger prgs? On desktop they should be in c:\lianja\data\<your database>\
-- you will see the prg and fxp for your trigger prg's.

In cloud they would be in c:\lianja\cloudserver\tenants\public\data\<your database>\
-- you will see the fxp's for your trigger prg's.

Hank

[SpringBox]

Hi Hank

Thanks for the response.

Yes - our cloudserver triggers are in the correct place.

Any thoughts as to how we can get the triggers to fire?

Cheers



Simon

[HankFay]

"Deploy" your system database as well. I'm not sure it's required, but at least on one occasion it seemed to make a difference.

Hank

[SpringBox]

Hi Hank

Good suggestion but unfortunately makes no difference.

Have a ticket in at the moment as we cannot edit blank fields in browser. Insert/delete and amend value of non blank field works fine. Hope once that is done the reason for triggers not firing will become evident.

Not sure if the field values will be available (we use cust_id guid as a parameter) in the BeforeUpdate trigger to pass on to our server side routine.

Cheers


Simon

[SpringBox]

Thanks Yvonne who helped to solve the edit issue - it was an index tag that was somehow getting in the way. Tag removed - now edits can be saved.

Unfortunately the triggers still will not fire in web though in dev they are perfect.

Really hope someone can shine some light on why.

Thanks in advance

Simon

[barrymavin]

Triggers when executed on the server in non desktop apps for virtual tables have no context. In other words there is no active record buffer, so you cannot access fields in it. Why? Because the UPDATE, INSERT or DELETE operation is going to be executed on the native table using ODBC or OLEDB.

I suspect your expectations to be able to access fields in an active record are incorrect in a client/server application.