|
Public Shared Function GetAssemblyVersion() As String
Dim version() As String = Assembly.GetExecutingAssembly().GetName().Version.ToString().Split("."c)
Return version(0) & "." & version(1) & "." & version(2) & "." & version(3)
End Function
Dijkstra was right...
|
|
|
|
|
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
|
|
|
|
|
This message is only shown to the SELECT few...
|
|
|
|
|
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. 
|
|
|
|
|
Randor wrote: My instincts are telling me that it's a placeholder for variable-length data. Exactly right. The struct is actually header for the information content which follows.
Software Zen: delete this;
|
|
|
|
|
Mircea Neacsu wrote: The unsigned long of 1 bit? An unsigned value 1 bit in width is slightly more useful than a signed value 1 bit in width, if you think about it.Mircea Neacsu wrote: The SendBlock doubly defined? That's the error I was referring to. IMO the compiler should issue an error, since the identifier SendBlock is ambiguous when referencing fields in the struct . This code is compiled using VS2008 which does not issue a diagnostic.Mircea Neacsu wrote: The version union with members in wrong order? They're in the correct order. The Message value must be at the end of the structure, since it is a placeholder for the beginning of the variable-length data that's included in the message.Mircea Neacsu wrote: The complete lack of comments? This is a code fragment, extracted from a header file that provides more context.Mircea Neacsu wrote: hope they pay you well to put up with this pile of manure They do pay me well, in the coin that really matters: appreciation. I've worked for the same company for over 30 years, and have survived numerous "workforce reduction" actions during the last period of financial instability.
As to its fecal quality, I didn't create this originally but I have maintained it over the last 20 years. This 'weird & wonderful' came up during some refactoring I'm doing while adding a new feature.
Software Zen: delete this;
|
|
|
|
|
Gary R. Wheeler wrote: An unsigned value 1 bit in width is slightly more useful than a signed value 1 bit in width, if you think about it.
Yes, but long...
Gary R. Wheeler wrote: They do pay me well, in the coin that really matters: appreciation. I've worked for the same company for over 30 years,
I understand. I've worked for the same company for 22 years and enjoyed every minute of it... well, at least most minutes
Mircea
|
|
|
|
|
Mircea Neacsu wrote: Yes, but long In this environment, 32 bits. The original value was an unsigned long .
Software Zen: delete this;
|
|
|
|