For the curious, a MGA is a type of entity that writes insurance based of a pool of capital managed by a third party. It's different from a broker in that it can write its own insurance products, whereas a broker resells insurance products underwritten by a third party. Brokers can sell insurance written by MGAs.
I've been reading about compression in SQL Server editions for a particular use case we have. My understanding is that ROW and PAGE compression are not like a binary compression like zip - columns like xml, nvarchar(max), varbinary are not even affected, so if we want to compress large XML objects we would need to really use COMPRESS/DECOMPRESS and these are only available starting in 2016. That seem accurate summary?
@CadeRoux if you're not querying the data as xml, e.g. just store/retrieve then it's less space-consuming to store as nvarchar max and apply some other form of compression.
you can also bypass the XML validation checks on insert
@ErikDarling I think the particular data is varbinary because I think it can vary by source, and yes, it's really just archival from my understanding, but is also kept in case of need to reimport.
So in this case, in SQL 2012, customers are out of luck completely, and in SQL 2016, we could use COMPRESS/DECOMPRESS.
And then when we get people onto newer and newer versions of SQL Server, more options open up
So the idea would be to start keeping more data on site, until we can go through the varying data and figure out how to deidentify it and remove the PII/PHI
Then we will have a large enough set to give to the ML people to do their analysis.
But we can't keep more data without the space being reduced.
@PaulWhite Yes, I think ideally this wouldn't be in the cardiac database but some other independent data management system.
Some of the varbinary are I assume PDF and images from the carts
I don't care much about it because it's a system before my three systems!
Especially when I don't have that much confidence in the ML people doing a better job dealing with the analysis than the existing devices team. But :shrug:
> The request failed to run because the batch is aborted, this can be caused by abort signal sent from client, or another request is running in the same session, which makes the session busy.
it happened for multiple clients, against multiple databases
@ErikDarling I could secretly recruit the device mapping team to generate awkward data to sabotage the ML team to preserve their jobs but I think the current plan is to have the ML actually generate a tool for the devices team.
These errors indicate that the CommandTimeout is reached (default is 30 seconds) before the server returns results. This does not indicate any bug and no SP can solve it. This is a performance problem (most likely missing indexes) and must be investigated as a performance problem. Try following t...
@PaulWhite yah after looking at it more indepth, I imagine there is a client-side error at that time around timeouts - I'll confirm with the dev team. No MARS as far as I know. I doubt they are using any kind of asynchronous calls, but since I am only new to this dev environment, I can't say for sure.
I have a strange query like this:
SELECT T1.*
FROM Table1 T1
INNER JOIN #TEMP an ON an.Id = T1.AccNum
LEFT OUTER JOIN Table2 T2
ON CAST(T2.Ref_tranID as bigint)= T1.Table1ID
AND CAST(T2.Ref_TranLineID as int) = T1.ItmSeq
...
I have a strange query like this:
SELECT T1.*
FROM Table1 T1
INNER JOIN #TEMP an ON an.Id = T1.AccNum
LEFT OUTER JOIN Table2 T2
ON CAST(T2.Ref_tranID as bigint)= T1.Table1ID
AND CAST(T2.Ref_TranLineID as int) = T1.ItmSeq
...
