Your sample trigger appears to be T-SQL so I'm assuming you're using ASE (as opposed to IQ, SQLAnywhere or Advantage), so fwiw ...
You've stated ... "update query with old data (no changes)" ... which is contradictory in ASE since any update does perform a change of data (yes, even if the old and new values are the same).
Suppose you run the following:
update tableA
set col1 = 5
where col1 = 5
Logically we might say the column has not been updated/changed.
But technically the column has been updated, ie, Sybase ASE will perform an update of the column. This in turn means the if update(col1)...
will always return true if col1
shows up as the target of a 'set' clause.
Sybase ASE does not compare the old and new values and then, if the same value is being referenced, 'ignore' the update. And no, this is not a case of a piece of stupid/dumb software but rather the software doing what you tell it to do.
I've seen on a few occasions where this kind of update is used to force some sort of downstream activity; one simple example would be the forcing of an update of a 'last updated' flag in a display program (think of a stock/forex ticker that periodically updates the 'last updated' date/time stamp even though the price may not have changed, thus signalling to the user that the display hasn't frozen/hung).
I've also seen on more than a few occasions where the (T-SQL) programmer wasn't paying attention and therefore wasted some cpu cycles with an unnecessary update. [It gets really noticeable if the updated column is part of an index as the index entry must be deleted and then (re)inserted ... thus causing a (slow/poorly-performing) deferred update.]
Short of not performing the update, you would need to code your trigger to compare the old/deleted and new/inserted values of the column and then take what you deem is the appropriate action.