|
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...
|
|
|
|
|
anything special? sorry I am not good at VB...
diligent hands rule....
|
|
|
|
|
It would be almost the same in C#. He could have already gotten everything at Assembly.GetExecutingAssembly().GetName().Version, but he continued to get a string and split it, as any VB6 programmer would prefer. And then, in the next line, he joined the strings with the same character on which he split them, meaning he already had the same result on ToString().
|
|
|
|
|
thanks for explaining it to me
diligent hands rule....
|
|
|
|
|
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.
|
|
|
|
|
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] 
|
|
|
|