|
Ah, learned something new, should have known that being Dutch:
Quote: In matters of commerce the fault of the Dutch Is offering too little and asking too much
|
|
|
|
|
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....
|
|
|
|
|
Saša Ćetković wrote: as any VB6 programmer would prefer
Remind me why. I have not touched VB6 since 2008.
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
I noticed a pattern that they really like string manipulation - using magic strings, concatenating HTML as strings in ASP Classic, concatenating SQL...
|
|
|
|
|
This looks like VB6 to VB.Net automated code converter generated code. I tried these when VS 2005 came out and discovered it was faster, easier, and less error prone to simply copy/paste my VB6 code into the IDE and then fix it. I also ended up with faster code as a result.
|
|
|
|
|
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.
|
|
|
|