Hi Al,

>Yes, I Googled the table alias requirement but it didn't address my situation. I probably should have explained better - I needed direct access to the values, not to use it in another query (e.g. IF @OldData.Column = SomeValue).

That's was my first thought but than I decide that you know better ... :)

>
>This was a CVL (cerebral vapour lock) on my part. Even though the table variable as I coded it returns exactly one row, it is still basically a SQL Server table, which has no concept of a "current row" - Fox thinking strikes again. So, attempt #2:

-- SELECT directly into local variables:
>DECLARE <some regular (non-table) variables>
>
>SELECT
>  @variable1 = <column1>,
>  @variable2 = <column2>,
>  ...
>
>-- Troubles with this approach:
>-- 1. Some of the variables are TEXT, which is not allowed
>-- 2. Since some values may be NULL, comparisons used later have to be wrapped in ISNULL()
>--  which is a nuisance.

>So, on to attempt #3 (which works fine):

-- SELECT to see if old and new values are the same:
>
>SELECT
>  ...
>  FROM <table>
>  WHERE pkey = @pkey
>    AND columnvalue = @newcolumnvalue
>
>-- no special handling needed for NULLs, just a regular SELECT
>-- need "AND columnvalue LIKE @newcolumnvalue" for TEXT comparisons
>
>IF @@ROWCOUNT = 0
>-- New value is different from current one in table
>-- IF @@ROWCOUNT = 1, new value is the same as current one in table

Yes, it's a nuisance to work with text fields. Fortunatelly, MS in SQL 2005 we can use varchar columns w/o 8000 limit.

> Funny, this code looks a lot like default VFP view update and RI code.
> I think I just managed to re-invent a 10+ year old wheel ;)

My thought when I saw your post was that you're trying to reinvent RV update conflict detection. :)