« first day (2362 days earlier)   

12:01 AM
@JoeObbish what happened?
 
12:29 AM
@sp_BlitzErik you asked about the SUM() OVER () query yesterday
I tried to be helpful but didn't hear back, so I'm wondering if you got the explanation that you were looking for
 
12:46 AM
@JoeObbish I don't think I saw your response. I know why the row store query didn't go parallel. I was surprised that the column store one did.
 
you can go to the top and hit "load older messages" to see it
 
@JoeObbish watching last episode of Fargo. Will check tomorrow.
 
enjoy
got some baking to do this evening
 
What's on the menu?
 
strawberry shortcake for a friend's birthday tomorrow
 
1:05 AM
Sounds delightful
 
 
4 hours later…
5:30 AM
min-ga-la-ba (Burmese)
-1
Q: Login failed ,login is from untrusted domain

shamim Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. Error: 18452, Severity: 14, State: 1. SSPI handshake failed with error code 0x8009030c, state 14 while establishing a connection with integrated security; the connection has been close...

RTFM IMHO FWI
 
 
2 hours later…
7:34 AM
Added brief summary . — Prasad 2 mins ago
Clear as mud
 
I think I can see what they want. I'll see if I can rewrite it after the OP replies to me.
 
8:04 AM
Gave it a shot. Is it better?
 
 
1 hour later…
9:14 AM
morning
 
9:33 AM
Morning
 
 
2 hours later…
11:04 AM
Weird issue of the day
as I understand it, the audit logout in profiler shows the total of IO/duration whatever of all queries executed during the connection
On this server the audit logout duration is consistently around 10 seconds higher than the sum of everything it did
Connection pooling issues maybe
 
11:53 AM
@giò very good. Now you can follow my other suggestion about trying it for yourself ;) — dezso 19 secs ago
 
12:38 PM
@TomV Amount of time taken by the event. Although the server measures duration in microseconds, SQL Server Profiler can display the value in milliseconds, depending on the setting in the Tools>Options dialog.
 
Yeah, the actual issue was elsewhere
I was probably confused
 
:-)
 
 
2 hours later…
2:34 PM
good morning
 
o/
 
3:14 PM
@dezso you around?
 
3:26 PM
@ypercubeᵀᴹ yes
 
@dezso I have a weird case, I get a "could not serialize due to concurrent update"
while my query has SELECT * FROM s WHERE EXISTS (...correlated) LIMIT 1 FOR UPDATE;
Do yo have any idea how this might happen/
isolation level = REPEATABLE READ
 
3:50 PM
@ypercubeᵀᴹ is it conflicting with itself?
 
@dezso I have to dig more
There might be other open transactions
But even if that's the case, it shouldn't raise this error, should it?
 
@ypercubeᵀᴹ TBH I could never fully understand when an UPDATE causes serialization errors and when not, even after some experimenting
what is pretty sure that no SELECT FOR UPDATE will run into it when running alone :D
but I can reproduce this easily
I'd guess the FOR UPDATE is a hint that the row will change, and then the violation is clear
 
4:07 PM
@dezso yes, when I try to reproduce with 2 transactions, I don't get it.
One transaction locks the rows, the 2nd just waits
for the first to commit and then gets unblocked
My app must be doing something else.
 
4:21 PM
when you first update (but don't commit yet), and then try to lock the row in another transaction, this latter will fail but only upon ending the other transaction
that is consistent with your error message
 
 
1 hour later…
5:26 PM
Oh thnx, let me check that scenario
 
5:38 PM
@dezso No, I can't get this.
When a transaction issues FOR UPDATE or just UPDATE, then the 2nd transaction trying to do FOR UPDATE just blocks
 
 
3 hours later…
8:52 PM
2
Q: Update/fix or recreate old database

megruder79My employer is currently using a database build in Borland Visual dBase 5.5 that has been running on a Windows 95 machine for the last 20 years. I am trying to figure out my best course of action to bring this database into the 21st century, but my knowledge of databases is beginner at best and I...

Gets the Oscar for the latest technology: Win 95
 

« first day (2362 days earlier)