>> I know this is illegal with a MERGE, but is there a way to update the same row twice with a regular UPDATE statement? <<

The short answer is that when you use the old, non-relational, non-standard Sybase UPDATE..FROM.. syntax you are updating the same rows twice! The problem is that only the last update actually gets put in the table, if there is a cardinality error (which the MERGE statement would catch), this syntax will grab whatever value is physically last in the physical storage; so much for logical data model!

It would also help if you didn’t use reserved words for column names (year, sequence, size, etc.) or uselessly vague words, so this table would make some sense. I did a quick edit, following ISO 11179 rules, and added, “_something” or “something_” to your improper or vague data element names. You really ought to go back and correct your data dictionary.

I’m also trying to figure out why the data hasn’t been scrubbed before it’s staged. You have more NULLs in one table than I have had in entire database systems for major corporations.

CREATE TABLE Foobar
(something_year INTEGER NOT NULL, –- reserved word
parcel_something CHAR (14) NOT NULL,
prop_code CHAR (4),
something_sequence INTEGER,
vg_rin INTEGER,
district_something INTEGER,
district_rate DECIMAL(8, 6),
district_acreage DECIMAL(9, 2),
market_something INTEGER,
market_diff INTEGER,
taxable_something INTEGER,
built_year INTEGER,
something_size INTEGER,
row_type INTEGER,
something_zone INTEGER,
gb_code CHAR (4),
change_type CHAR(1),
review_timestamp DATETIME2(0)
PRIMARY KEY (something_year, parcel_something, prop_code, change_type);

Your real problem is that you don’t understand how a set oriented language works. You expected the updates to come in sequentially, as if you were using a deck of punch cards or magnetic tape. But in a set oriented language, everything how things “all at once”, which is why the merge statement would find out that you tried to update the same row twice. This is called cardinality violation.

Please consider the following CASE deck of punch cards or magnetic tape. In 1950 expression:
CASE WHEN T.built_year > 0 THEN T.built_year ELSE V.built_year END

If you could use the NULL, then we would have used more natural COALESCE () expression. But the case expression looks like the if–then–else control flow that you are used to from procedural languages.

>> I know it is being skipped because the last 2 rows have the same vg_rin. But they have different change_types and the individual change_types with their corresponding value need to be logged separately. <<

in SQL, most of the work is done in the DDL and not kludged in the DML. Just as a guess, I think we need to redesign the schema and consider using ETL to scrub the data before it gets into the schema. Are you in a position to do this sort of stuff, or are you screwed?