'Morning all.

Morning

Location:	 Sql\Ntdbms\storeng\include\xdesimp.h:629
Expression:	 !"Method not supported encountered."
Msg 3624, Level 20, State 1
A system assertion check has failed.
Msg 596, Level 21, State 1
Cannot continue the execution because the session is in the kill state.
Msg 0, Level 20, State 0
A severe error occurred on the current command.  The results, if any, should be discarded.

feedback.azure.com/d365community/idea/…

More rows means I'm winning right

Yep

@PaulWhite that’s different from the one you found before right?

Yes

They always seem to neglect table variables

Nevermind checked

Thanks mobile site

That’s funny, just calling table variables victims of neglect from now on

Msg 13535, Level 16, State 0,
Data modification failed on system-versioned table 'dbo.Thing' because transaction time was earlier than period start time for affected records.
The statement has been terminated.

Temporal is so stupid

session 1: begin tran
session 2: insert a new row (auto-commit txn)
session 1: update (or delete) that row -> error

Should have gotten it right the first time I suppose

Indeed. But it's not like databases don't ever update or delete data.

There's absolutely no good reason for those operations to fail on a temporal table.

Yeah that is a pretty big failing for temporal in a single transaction

I wonder how many projects have abandoned temporal tables because of that

It’s not like inserting and updating a row in a batch is unheard of

Plenty of times I’ve had to do it when the updates relied on lookup tables that made the insert logic all wonky

@ErikDarling There are two separate sessions there

🔬

Thanks mobile

Mobile was a mistake

I just cannot wrap my head around this design at all

Since when does it make sense to treat all the data changes occurring in a transaction as if they had happened at the start of the transaction instead of when the transaction commits?

And of course it's only a statement-terminating error, so unless you're handling errors correctly, your transaction will just continue on its merry way making only some of the changes you requested. Good grief.

Even with xact_abort?

That counts as handling errors correcctly

Minimally

I wonder if EF sets XACT_ABORT

People using EF have given up on doing things correctly

Hey I finally did something minimally right!

This is crazy. You can't even get an accurate picture of history with temporal tables.

What is the literal point of this feature

session 1: begin tran
session 2: delete a row (auto-commit txn)
session 1: insert a row with the same key as just deleted, and commit

An AS OF query will show two rows with the same key active concurrently!

Results of:

SELECT
    ThingID,
    ThingData,
    ModifiedBy,
    ValidFrom,
    ValidTo
FROM dbo.Thing
    FOR SYSTEM_TIME
        AS OF '2023-05-27 16:51:13';

ThingID is a primary key!

Why does it go to the history table before it’s committed

Well, I did commit the tranaction

Let me edit that in...done

🫠🫠🫠

Just another feature that is minimally implemented without any real care or consideration

I can't believe anyone uses it seriously

Doesn't work for auditing, doesn't work for viewing data as it was, introduces illogical error conditions...

You dodged a bullet there

Well seriously is open to interpretation

I’m sure many people find it ~good enough~

I've yet to have issues, but I only use it for auditing. I don't care for the AS OF syntax. Interesting scenario with the explicit transaction though. Going to look into that.