Board index » delphi » data changed by trigger

data changed by trigger

In a before Insert trigger, I change the data that the user entered if it
doesn't match some criteria.  I've already done this and it works well.  The
code that works was only setting the new.field1 to upper(new.field1).  As
soon as you post, the data is shown in upper case.
Now,my trigger works (data is changed), but I do not see the change until I
close-open the TIBDataSet...  The trigger actually change almost every
integer field, including the field that is order by.
Any idea or workaround?  The user must see that his data has been changed by
the server...

--
Frederic Gelinas
Programmeur-Analyste
Si Informatique

 

Re:data changed by trigger


I think you need to call IBDataSet.Refresh to see the new values. If a field
is changed, that is used in "order by" clause you will have to close and
reopen the IBDataSet.
Remember that Refresh only will work if property RefreshSQL contains a
select statement that will select one (and only one) record.

I hope this will be the answer Jeff would give you.

Michael Adamovic

"Frederic Gelinas" <fgeli...@si.qc.ca> schrieb im Newsbeitrag
news:3b4c446f$1_1@dnews...

Quote
> In a before Insert trigger, I change the data that the user entered if it
> doesn't match some criteria.  I've already done this and it works well.
The
> code that works was only setting the new.field1 to upper(new.field1).  As
> soon as you post, the data is shown in upper case.
> Now,my trigger works (data is changed), but I do not see the change until
I
> close-open the TIBDataSet...  The trigger actually change almost every
> integer field, including the field that is order by.
> Any idea or workaround?  The user must see that his data has been changed
by
> the server...

> --
> Frederic Gelinas
> Programmeur-Analyste
> Si Informatique

Re:data changed by trigger


Quote
Michael Adamovic wrote:

> I think you need to call IBDataSet.Refresh to see the new values. If a field
> is changed, that is used in "order by" clause you will have to close and
> reopen the IBDataSet.
> Remember that Refresh only will work if property RefreshSQL contains a
> select statement that will select one (and only one) record.

> I hope this will be the answer Jeff would give you.

Not quite.  You are right about the RefreshSQL, but all you have to do is set
FrocedRefresh to true and IBX will refresh the record after the insert and show
the changes without any coding.  The only caveat is that you must have a unique
set of values (primary or secondary key) that are known on the client side that
won't be changed on the server side so IBX can re lookup that record.

--
Jeff Overcash (TeamB)   I don't think there are any Russians
(Please do not email    And there ain't no Yanks
 me directly unless     Just corporate criminals
 asked.  Thank You)     Playing with tanks.  (Michael Been)

Re:data changed by trigger


"Jeff Overcash (TeamB)" <overc...@onramp.net> a crit dans le message news:
3B4C682A.C5A0D...@onramp.net...

Quote
> Not quite.  You are right about the RefreshSQL, but all you have to do is
set
> FrocedRefresh to true and IBX will refresh the record after the insert and
show
> the changes without any coding.  The only caveat is that you must have a
unique
> set of values (primary or secondary key) that are known on the client side
that
> won't be changed on the server side so IBX can re lookup that record.

Thanks Jeff,
Well, I think you point out the problem: I am changing the unique key in the
trigger.  The trigger can even change all fields if it match all criteria...
Will I need to add an auto-inc field just to take care of the refresh?  Is
there any other (better) way?

--
Frederic Gelinas
Programmeur-Analyste
Si Informatique

Re:data changed by trigger


Quote
Frederic Gelinas wrote:

> Thanks Jeff,
> Well, I think you point out the problem: I am changing the unique key in the
> trigger.  The trigger can even change all fields if it match all criteria...
> Will I need to add an auto-inc field just to take care of the refresh?  Is
> there any other (better) way?

What follows is IMO.  Primary keys should never change from the moment they are
created until the day the record is deleted.  If your key can change then that
should be a secondary key and you should create an incrementing column and all
foreign tables should reference this column and not the secondary key that can
change.  The user shouldn't really even know the primary key value, if they have
a unique value they know make it a secondary key because users are infamous for
wanting to change these values a year from now.

--
Jeff Overcash (TeamB)   I don't think there are any Russians
(Please do not email    And there ain't no Yanks
 me directly unless     Just corporate criminals
 asked.  Thank You)     Playing with tanks.  (Michael Been)

Other Threads