|
There is some code that builds a dynamic Class name to load a different class as needed.
The are multiple other places where this code was copied, but there is only a single, fixed class that is needed.
Replace 10-20 lines of unnecessary code with
“new Fixed()”
|
|
|
|
|
For giggles I programmatically created a query that had a huge number of unions. The full message from SQL Server was:
Quote: The query processor ran out of internal resources and could not produce a query plan. This is a rare event and only expected for extremely complex queries or queries that reference a very large number of tables or partitions.
|
|
|
|
|
I believe SQL Server has a maximum query memory of 2 gigs. You obviously surpassed that with all the unions. I believe all unions are read into memory.
I am guessing here, I could be wrong.
|
|
|
|
|
|
There are also only 100 levels of recursion in a cursor. Found that out in the poast two weeks when a client's process failed on a stored procedure that was last edited a decade ago.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
|
|
|
|
|
Or a recursive CTE, but you can increase that I think.
|
|
|
|
|
I never make a large JOIN , I split it up:
A JOIN B JOIN C JOIN D
becomes:
( ( A JOIN B ) JOIN C ) JOIN D
|
|
|
|
|
Oh that's interesting! I'll have to try that!
|
|
|
|
|
For inner joins the optimizer will disregard any order of the joins, or any parentheses for that matter.
If you want to force a specific order there's a hint for that: OPTION (FORCE ORDER)
For outer joins this is not the case, they will happen in the relative order specified.
|
|
|
|
|
Question for you?
Can you verify this 1) uses less memory and/or 2) improves performance time?
Thanks! Craig
|
|
|
|
|
It has significantly reduced execution time in many cases.
Your mileage will vary.
|
|
|
|
|
This message is only shown to the SELECT few...
|
|
|
|
|
That's bang out of ORDER
Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
|
|
|
|
|
What version of SQL was that?
What was the count of unions that caused this?
Thank you.
|
|
|
|
|
Which means "Stop doing this to us in here!"
Just for more gig-gles, sent it over and over and see is the "rare event" message changes.
|
|
|
|
|
struct Record
{
unsigned short Length;
unsigned long ObjectId;
LevelType Level;
unsigned long SendBlock;
struct
{
unsigned long SendBlock : 31;
unsigned long SendBlockMarker : 1;
};
__time32_t SendTime;
struct
{
Type SendType : 16;
unsigned SendVersion : 16;
};
unsigned long SendNumber;
union
{
struct
{
char Message[1];
} Version0;
struct
{
__int64 EventTime;
char Message[1];
} Version1;
};
};
:face-palm:
Software Zen: delete this;
|
|
|
|
|
What's wrong isn't obvious to me.
It looks like SendVersion tells you which union to look at.
If sent interprocessor, it will pack differently on 32-bit and 64-bit CPUs, ignoring endianism problems. The fact that there's a version number suggests that this could be the case.
|
|
|
|
|
There's a #pragma pack around the declaration.
I'll give you a couple hints: it's before SendVersion . This compiles successfully under VS2008 (don't ask), and I've not tried compiling it under VS2019. It should trigger a compile error.
Software Zen: delete this;
|
|
|
|
|
The two SendBlock fields? Maybe VS2008 accepted it because the second one was inside an unnamed struct .
|
|
|
|
|
BINGO!
Software Zen: delete this;
|
|
|
|
|
In short: everything!
Where should I start? The unsigned long of 1 bit? The SendBlock doubly defined? The version union with members in wrong order? The complete lack of comments?
I hope they pay you well to put up with this pile of manure
Mircea
|
|
|
|
|
The union with members in the wrong order is likely correct. In Version1 , EventTime was added to timestamp messages. It's followed by the Message contents, which are at the end of the message and claim to be of type char[1] , but which will actually be indexed from 0 to Length - 1 .
Writing types for message byte buckets is fun, especially when you add protocol version control!
|
|
|
|
|
Greg Utas wrote: type char[1], but which will actually be indexed from 0 to Length - 1 My instincts are telling me that it's a placeholder for variable-length data.
With MSVC you cannot use a zero-length array unless the following conditions are true:
1.) It must be the last field in the union or struct.
2.) Option /Za must be enabled.
3.) Option /permissive- must be unset/disabled
Or you can just do char[1]
|
|
|
|
|
And then you receive a zero-length message (header only), and someone does a memset using the size of this type, trampling over the char[1] that isn't there.
|
|
|
|
|
Heh,
I'm not advocating the technique, I am just pointing out what I see in the struct.
|
|
|
|