|
Pete O`Hanlon wrote: ungodly code is held up to the sunlight of derision where it bursts into flames
PMFSL... that's all kinds of funny...
-------------------------------------------
Don't walk in front of me, I may not follow;
Don't walk behind me, I may not lead;
Just bugger off and leave me alone!!
|
|
|
|
|
try breaking it into many subprograms.
wont make u lost
-
|
|
|
|
|
jglim1994 wrote: breaking it into many subprograms
Divide and Rule?
Vasudevan Deepak Kumar
Personal Homepage
Tech Gossips
Yesterday is a canceled check. Tomorrow is a promissory note. Today is the ready cash. USE IT.
|
|
|
|
|
sort of- at least you dont get lost in a huge pile of code
-
|
|
|
|
|
Sounds like you are on your way to creating a coding horror of your own!!
-------------------------------------------
Don't walk in front of me, I may not follow;
Don't walk behind me, I may not lead;
Just bugger off and leave me alone!!
|
|
|
|
|
Use the fast C++ in a dll and watch out for precision details. And better disable optimization until you proof that there isnt going something wrong. Use 64bit values int64 and double. Check that the values dont go near 0 or get really big, because it harms precision. First multiply than divide.
Greetings from Germany
|
|
|
|
|
You forgot to tell him to stiffen his sinews and gird his loins. I know that you would expect him to be using the Manly macros, but I suspect that he's actually using the Wimpy ones. But good catch on the first multiply then divide. It's a mistake that people often make.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Pete O`Hanlon wrote: tell him to stiffen his sinews and gird his loins.
Because:
"Its fun to charter an accountant, and sail the wide accountan-see!
Its all tax deductible, we're fairly incorruptible
and sailing on the wide accountan-see!"
Please excuse these attack by our introductory film
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
KarstenK wrote: First multiply than divide
That happens all too often nowadays.  People should work harder at fulfilling their commitment.
Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
|
|
|
|
|
Phil J Pearson wrote: KarstenK wrote:
First multiply than divide
That happens all too often nowadays. People should work harder at fulfilling their commitment.
Or require a licence prior to multiplication
|
|
|
|
|
Just Copy&Paste them from Excel into VisualStudio and assign the result to a variable.
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
This isn't really a place to ask questions. Its for posting some of the most horrific coding solutions you may have come across.
My current favourite word is: PIE!
Good ol' pie, it's been a while.
|
|
|
|
|
Pie is good. I like pie.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
I agree with Pete, I like Pie too. Preferrably Apple.
|
|
|
|
|
These two queries return the same result set(different results as different fields).
A colleague wrote the first query and I wrote the second.
Now I think the first one looks just plain ugly, however the execution plan is not too dissimilar to the second query, which I wrote.
Is there any rationality to my response of Urghhhh?
My colleague's version:
select
sat.salesnumber,
pjq.pickjobnumber
from
(select salesnumber, rownumber, invoiceaccount
from salestable
where dataset = 'wtl'
and ltrim(salesnumber) = '331299') as sat
join
(select * from
pickjobtrans) as pjt
on sat.rownumber = pjt.picksalesrecid
join
(select * from
pickjobqueue) as pjq
on pjt.pickjobnumber = pjq.pickjobnumber
group by sat.salesnumber, pjq.pickjobnumber
</code>
My version:
select distinct pjq.accountnumber,pjq.status
from pickjobqueue pjq
right join pickjobtrans pjt
on pjq.pickjobnumber = pjt.pickjobnumber
right join salestable sal
on pjt.picksalesrecid = sal.rownumber
where ltrim(sal.salesnumber) = '331299'
</code>
You always pass failure on the way to success.
|
|
|
|
|
The one that runs faster 
|
|
|
|
|
I think having a column called salesnumber which is actually a char datatype is a bit of a db design coding horror too
|
|
|
|
|
Yes - it's a Mircosoft XAL database.
It would make more sense space-wise as well as a varchar, in this case, will take more space than an int type which only takes 4 bytes.
Microsoft bought the database from Navision who bought it from Daamgard before it was a SQL database.
Let that be a warning to database design - get it wrong at the beginning and you can be left with problems for the life of the product.
You always pass failure on the way to success.
|
|
|
|
|
I am not a fan of SELECT *, It returns too much data, taking up resources along the way. That being said, my only other complaint is the lack of formatting, but that is just code style. I find the extra formatting makes it easier to find the part I want to work on.
SELECT DISTINCT pjq.accountnumber,
pjq.status
FROM pickjobqueue pjq
RIGHT JOIN pickjobtrans pjt
ON (pjq.pickjobnumber = pjt.pickjobnumber)
RIGHT JOIN salestable sal
ON (pjt.picksalesrecid = sal.rownumber)
WHERE LTRIM(sal.salesnumber) = '331299'
Hogan
|
|
|
|
|
I take your point on formatting.
snorkie wrote: I am not a fan of SELECT *, It returns too much data, taking up resources along the way
I am in the same camp as you here, however when I looked at the execution plan both queries have very similar execution plans.
In the end neither was faster.
My position is more that it just looks lazy using those select* statements.
I also find a beauty in being able to write code that is short and concise.
Maybe I am being pedantic and need to let go...
-- modified at 15:28 Tuesday 6th November, 2007
You always pass failure on the way to success.
|
|
|
|
|
GuyThiebaut wrote: I am in the same camp as you here, however when I looked at the execution plan both queries have very similar execution plans.
In the end neither was faster.
To a large extent, the execution plan is immaterial here. What matters more is the amount of data that is returned over the network. If you only need one column, why put more load on what may already be a busy network by returning 20?
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Select *....just say no. It is a lazy approach and as Pete points out you can end up creating a lot of network traffic for no benefit.
|
|
|
|
|
not to mention the possibility of some adding a big field to the end of the table (blob for instance) and your code suddenly grinding to a halt.
I won't use select * even if i want every field as you have no idea what changes may come later
Russ
|
|
|
|
|
snorkie wrote: I am not a fan of SELECT *,
I support you. Even in the case of selecting all the columns of the table (only remote combinations of applications), I prefer having them enumerated instead of *. I feel it is more readable and friendly too not to mention about the significant gains in terms of performance.
For that matter, I think, even C# takes that stand. Like Java, where java.lang.* no longer works for namespace inclusions in managed code. Isn't it?
Vasudevan Deepak Kumar
Personal Homepage
Tech Gossips
Yesterday is a canceled check. Tomorrow is a promissory note. Today is the ready cash. USE IT.
|
|
|
|
|
Spent about 45 min trying to figure out why title was lost after returning at the end of the function .
DoSomething(Text *text_store, int seven)<br />
{<br />
char *text;<br />
text = (char*) malloc(sizeof(char) * seven);<br />
text_store.title = text;<br />
free(text);<br />
} <br />
-- modified at 15:05 Monday 5th November, 2007
And yes text_store.title is a pointer
this thing looks like it was written by an epileptic ferret
Dave Kreskowiak
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
