I suspect that the amount of time that you are experiencing is due to the time for the data to be shown on the screen, not the time for SQL...

pgAdmin appears to be some sort of PostGreSQL tool

Perhaps yo would get better answers from a PostGreSQL forum.

So, you are expecting the value to be truncated and not rounded.

Try this

DECLARE @id numeric(17, 2) = ROUND('123.456', 2, 1)

SELECT  @id;

Your use of the RIGHT function is incorrect.

Here are 3 different ways to achieve the format you are looking for

Using SUBSTRING

            
November 22, 2021 at 6:52 am
            
#3955457

            
            
                                                
        

The display that you are seeing is the format of the time data type.  You should not be formatting the data in SQL - That is the job of the...

You have not provided the format that you need the time difference in, so I am providing it as [time].

However, this will not cater for values greater than 24 hours.

Below are 2 alternative ways to write the same query, but without the LEFT JOIN.  They may have an improvement in performance, so test, test, test.

SELECT ...

This will work with the sample data that you provided

WITH cteData AS (
SELECT t.Id
     , t.CarID
     , t.CarStatus
 ...

Option2 is going to give you terrible performance because the @Name = '', @zip = '' and @colors = '' in the WHERE clause will force a table scan every...

With no readily available test data, I would try to edit the 1st CTE as follows

;with ClockIn as
(select [Initial],[RFID],[Time] as ClockInTime from Data where Type=1 and [Time]...

Thank you DesNorton,

I got that, my question was how can I incorporate that in this single statement, that null values update always need to check for all columns, if...

You could use ISNULL for your update, so that it does not replace existing values with NULL.

Something like this ....

UPDATE dest
SET dest.Value = ISNULL(src.Value, Dest.Value)
FROM SourceTable AS...

Brief tangent into real SQL stuff...

Has anyone ever heard of table triggers not firing for every row if you do set-based updates to records?

Our vendor sent us code for...

I would change the data types in the #SourceTable.  Or at least create another intermediate process that cleans/types the data.  Otherwise, you are asking for a world of hurt

Please read this article on upserts and concurrency  http://source.entelect.co.za/why-is-this-upsert-code-broken

From the above, you should end up with code that looks like this

UPDATE     ...