When reading the news, I read about an experimental trial (for the very same diagnosis Hugo shared in his post) which saved the patients life
I'm not sure whether to share it now that he's undergoing chemo. Because for the patient in the article, the chemo didn't work out, and they were considered terminal.
Tough call. On the one hand, it's one way to show you're concerned enough to care to mention it. OTOH, you're sort of assuming his medical team wouldn't be aware of such things (and perhaps more besides).
People understandably tend to overthink such things. I don't think it matters much which way you go on this. Either action would be reasonable.
I think it's probably best to wait until after the chemo. If chemo works out, then no need to mention it. If it doesn't it's probably better to share even if the medical team know
@Zikato By the way, would you be prepared to be a room owner here?
Not there's ever much to do, but I do like to maintain the room owner list of active users with vaguely sensible ideas of acceptable chat behaviour, just in case.
There's no rule that select statements must return one or more columns.
If the select returns zero columns in several rows you will get rows inserted with all default values.
INSERT INTO table_name
SELECT FROM generate_series(1,10);
> As an aside, Chris Date has defined two tables, Dee and Dum, in his Tutorial D language. His Dum table is empty and contains no rows at all; Dee has a single row, But this row has no values in its column (This makes keys a bit difficult to define). He uses them to model TRUE and FALSE, respectively. It might be worth remarking that tutorial D has no concept of NULL.
it's weird that people find a column-less table weird but have no problem with tables without any unique constraint or result sets with duplicate rows.
I guess the only thing you can store in a table with no columns is the number of rows, and for that you might as well just store a single row single column of NumRows
> Msg 8665, Level 16, State 0, Line 8 Cannot create the clustered index "cuq" on view "dbo.NoRow" because no row can satisfy the view definition. Consider eliminating contradictions from the view definition.
(I did index my first versions of those views, but ultimately didn't see the point)
@PaulWhite That's a cool error, so someone actually special-cased such a view to prevent it being indexed? One wonders whether they have better things to do with their time
CREATE OR ALTER VIEW dbo.NoRow WITH SCHEMABINDING AS
SELECT Zero = COUNT_BIG(*)
WHERE LEN(CONVERT(varchar(max), '')) < 0
GROUP BY ();
GO
CREATE UNIQUE CLUSTERED INDEX cuq ON dbo.NoRow (Zero);
My whole point was, while using 90 proof alcohol to run your car might work for a little bit, don't complain when it kills your engine and expect it not to when it's not supported
We have a Windows Service that uses the ACE driver, and the number of times this service crashes due to ACECORE.dll throwing an access violation makes me really appreciate Microsoft's position on not supporting that thing being loaded into SQL Server permanently.
Please I need help optimizing my database performance. I have done some profiling to see seek queries using BlitzCache script created by Brent Ozar. After executing the script, some number of queries was listed which I generated an execution plan which can be found on the following link. https://...
Hmmm, poor formatting, poor use of subqueries rather than APPLY, use of top 1 1 in an EXISTS, use of system functions instead of joining system tables. Definitely an MS internal query.
> When you create or rebuild a UNIQUE index online, the index builder and a concurrent user transaction may try to insert the same key, therefore violating uniqueness. If a row entered by a user is inserted into the new index (target) before the original row from the source table is moved to the new index, the online index operation will fail.
I have a query I need to modify to bring in another translation from a code to a text field in a translation table (Code_Desc) It currently works with a single translation, I get errors when trying to add the second. Code Below.
SELECT DISTINCT T1.*
, C1.TX_DESC_LRG AS CASETYPE
,C2.TX_DESC_LRG ...
actually i don't think it's an issue with the CU just yet. the secondary replica is going into not-sync/recovery pending in (i think) the script line just before we apply the patch
so i'm gonna repair the replica and see if i can repro the break real quick
Stuart: Oh, Sheldon, I'm afraid you couldn't be more wrong. Sheldon: More wrong? Wrong is an absolute state and not subject to gradation. Stuart: Of course it is. It's a little wrong to say a tomato is a vegetable, it's very wrong to say it's a suspension bridge.
"generous application of DISTINCT" reminded me of that haha.
blerg, working theory is something something resource governor something something but I can't repro it and i'm not sure I'm willing to spend time rolling back windows patching in further attempts :\
@ErikDarling "The Swiss invented time" - No, they didn't. As everyone who knows their classics will tell you - it was Stephen Hawking - and that's straight from the horse's mouth - Penny from the Big Bang Theory!
I'm trying to solve a particularly difficult problem. I am storing some telemetry data from some sensors in an SQL table (PostgreSQL) and I want to know how I can I write a query that will group the telemetry data using relational information from two other tables.
I have one table which stores t...
Now that was cool - I'd gotten that far myself - didn't think of LEAST/GREATEST though - was kicking myself - but my solution(s) are kinda cool - make use of another deadly PostgreSQL feature - range types!
I've one decent answer which has 1 subquery and the correct one which has 2 - it's just that bit clunky though. Might offer a bonus or something and see if the great EB can be tempted to answer!
I'm on fire - I got the correct answer with only 1 subquery and no use of range types! I'm knackered though - I'll post the answer tomorrow - do you have any further thoughts on tackling it?
I don't want to show me my own answer lest it influence yours - just give me a broad idea of how you'd tackle it - using PostgreSQL (as per question) or SQL Server?
There's no rule that select statements must return one or more columns.
If the select returns zero columns in several rows you will get rows inserted with all default values.
INSERT INTO table_name
SELECT FROM generate_series(1,10);
