Akina

Пример возможной реализации. Демонстрация логики.

1. Создание тестовой таблицы

CREATE TABLE PDIndicatorsHistory 
(
	RecId int PRIMARY KEY IDENTITY(1,1),
	ItemId int,
	ReportDate datetime,
	PD int
);
  
INSERT INTO PDIndicatorsHistory (ItemId,ReportDate,PD) VALUES
(1, '2025-07-06', 2), (1, '2025-07-07', NULL), (1, '2025-07-08', NULL);

SELECT * FROM PDIndicatorsHistory;

2. Создание функции

CREATE FUNCTION dbo.GetPD 
(
    @prev_RecId INT,  -- идентификатор предыдущей записи, её исходное состояние
    @next_RecId int,  -- идентификатор текущей записи, её исходное состояние
    @prev_PD INT      -- значения отдельных полей обновлённой предыдущей записи
)
RETURNS int
AS

BEGIN
-- требуемая сложная логика, опирающаяся на идентификаторы текущей и предыдущей записей
-- что позволяет получить значения полей записей ДО запуска SELECT или там UPDATE,
-- а также на значения полей модифицированного состояния предыдущей записи, переданных по отдельности
    RETURN @prev_PD * 2;
END;

3. Обновление

WITH
-- первый CTE, просто нумерует записи по возрастанию даты для каждого ItemId отдельно
cte1 AS (
    SELECT *, ROW_NUMBER() OVER (PARTITION BY ItemId ORDER BY ReportDate ASC) rn
    FROM PDIndicatorsHistory
    ),
-- рекурсивно обрабатываем записи в порядке возрастания номера
cte2 AS (
    SELECT RecId, ItemId, ReportDate, PD, rn
    FROM cte1
    WHERE rn = 1 -- начинаем с первой
    UNION ALL
    SELECT cte1.RecId,
           cte1.ItemId,
           cte1.ReportDate,
           dbo.GetPD(cte2.RecId, cte1.RecId, cte2.PD),
           cte1.rn
    FROM cte1
    JOIN cte2 ON cte1.ItemId = cte2.ItemId
             AND cte1.rn = cte2.rn + 1 -- а потом вторая, третья... пока не кончатся
    )
-- посчитав значения, которые нужно использовать при обновлении, выполняем само обновление
UPDATE PDIndicatorsHistory
SET PD = cte2.PD
FROM cte2
WHERE PDIndicatorsHistory.RecID = cte2.RecId;

fiddle

PS. Почему так сложно? Такова логика UPDATE (транзакции, роллбэки - по-другому никак). Сначала подготовить новое состояние для ВСЕХ модифицируемых записей, а потом выполнить их фактическое обновление. И соответственно SELECT к таблице внутри функции обращается к исходному состоянию таблицы, ему пофиг, что запись, к которой ты обращаешься, ПОДГОТОВЛЕНА к модификации. Она ещё не модифицирована.

SELECT CASE WHEN [column] IS NULL
            THEN 'sale'
            WHEN CHARINDEX([column], '.') > 0
            THEN LEFT([column], CHARINDEX([column], '.') - 1)
            ELSE [column] 
            END AS [column] 
FROM source_table;

как есть 2-я таблица с такимеже значениями только без .0 и без NULL . А мне в дальнейшем нужно сравнить эти 2 таблицы

Соответственно

SELECT *
FROM table1
JOIN table2 ON table1.[column] = CASE WHEN table2.[column] IS NULL
                                      THEN 'sale'
                                      WHEN CHARINDEX(table2.[column], '.') > 0
                                      THEN LEFT(table2.[column], CHARINDEX(table2.[column], '.') - 1)
                                      ELSE table2.[column] 
                                      END;

Во-первых, практически все версии SQL Server обратно совместимы. Т.е. всё, что было в предыдущей версии, поддерживается последующей. Если какие-то фичи удалены или изменены - это явно описано в соответствующем документе (который What's new).

Во-вторых, поддерживаемые фичи определяются не только версией сервера, но и уровнем совместимости БД (compatibility level). Если уровень совместимости не поддерживал фичу - она не будет использоваться, даже если версия сервера позволяет. А если фича изменила поведение - её поведение будет определяться именно уровнем совместимости БД, а не версией СУБД. Любая версия сервера поддерживает определённый диапазон уровней совместимости - а потому изменение версии на 1-2 поколения вполне может производиться без длительного перелопачивания БД в новый формат (правда, и новые фичи могут быть недоступны).

Но это такое убожество что я толком ничерта не понимаю

Не надо путать причину и следствие. Причина - это что ты ни хрена не понимаешь. А следствие - оно тебе кажется убожеством.

отличаются ли запросы sql MSSQL от Mysql

Да. Точнее, самые простейшие базовые запросы могут выглядеть одинаково. Но не более, чуть только хоть какая-то сложность, и одинаковость заканчивается. Синтаксис различается, и весьма сильно. А кое-где даже подходы к решению задачи различаются, и код с одной СУБД на другую не адаптируется совсем - только полное переписывание.

возможно ли сменить БД без нарушения функциональности софта.

Если запросы хардкодом - крайне маловероятно. Если тексты запросов - ресурс, вероятность несколько выше. Если вся лигика находится на сервере, общение с ним выполняется исключительно обращением к представлениям и вызовом процедур, а само приложение является чистым интерфейсом - скорее всего возможно.

CREATE TRIGGER tr
ON routes
AFTER INSERT 
AS 
UPDATE [user]
SET [update] = 1
FROM INSERTED
WHERE id = INSERTED.user_id;

fiddle