Jump to content


Photo
- - - - -

Slow SQL execution


25 replies to this topic

#16 Vol Yip

Vol Yip

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 393 posts
  • Gender:Male
  • Location:Hong Kong

Posted 07 February 2005 - 03:27 PM

I totally agree with Dan's comment about Scratch varaible.

Once upon a time I had debugged a report function which printed unreasonable result. Everything looked fine until I finally found that programmer used #RECONGIZE_COST as field variable but used #RECONGIZED_COST during the calculation :)

#17 Mike Nicholson

Mike Nicholson

    Expert

  • Members
  • PipPipPipPip
  • 196 posts
  • Gender:Male
  • Location:Stockholm, Sweden

Posted 07 February 2005 - 04:14 PM

Good for some things though - e.g. global interfaces. For which I refer you back to the wonderful 1=0 discussion some time back ;-)

I've got a routine which will check a function for all scratch usage and count up the number of times they are used (all usage - fields, interface, logic etc.) Anything only used once gets closer investigation and zapped if no longer required.

Cheers

Mike

#18 Donald Miller

Donald Miller

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 205 posts
  • Gender:Male
  • Location:Cupar, Fife, Scotland
  • Interests:Motorcycling, Running, Cooking

Posted 08 February 2005 - 08:03 AM

Mike - I know how you feel about VIP but change is good. Once you have entered a scratch variable into a function you shouldn't need to enter it again as it is available to be selected. That should root out all those typos - epsecailly for those who can't type and for those that can't remember what they're doing...
Half of what he said meant something else, and the other half didn't mean anytthing at all

#19 Rob Donovan

Rob Donovan

    rob@proivrc.com

  • Admin
  • 1,640 posts
  • Gender:Male
  • Location:Spain

Posted 08 February 2005 - 08:08 AM

Hi,

I too hate the people who have to put every file variable into a scratch var.

Our system is full of them.

I think the reason people do it is because they dont unserstand the timing cycle correctly, and therefor are worried that the variables will be overwritten.

Our system is also full of alternate file reads (ie _1,_A or Q files) because again people dont understand the timing cycle correctly.

It just makes the code much harder to read. :p

Rob.

#20 Mike Nicholson

Mike Nicholson

    Expert

  • Members
  • PipPipPipPip
  • 196 posts
  • Gender:Male
  • Location:Stockholm, Sweden

Posted 08 February 2005 - 08:30 AM

But Donnie - I've got a routine for that so I don't need VIP ;-)

I'm actually not massively VIP-averse these days but it's still much quicker to code in pro-aide for the moment, especially on a green- screen system.

BTW Rob - just to back up your statement (for a function you'll recognise you sad man you ;-) - removed about 10 unused scratches from MD.TRCV1 the other day . . .

There are all to many problems fixed by setting a value into a scratch and resetting the file var later - instead of finding out what the problem actually is and fixing it...

Cheers

Mike

#21 Rob Donovan

Rob Donovan

    rob@proivrc.com

  • Admin
  • 1,640 posts
  • Gender:Male
  • Location:Spain

Posted 08 February 2005 - 10:36 AM

BTW Rob - just to back up your statement (for a function you'll recognise you sad man you ;-) - removed about 10 unused scratches from MD.TRCV1 the other day . . .


Oh dear oh dear... I cant belive you've managed to get MD.TRCV1 into a post :p

Rob.

#22 Joseph Bove

Joseph Bove

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 756 posts
  • Gender:Male
  • Location:Ramsey, United States

Posted 08 February 2005 - 06:59 PM

Dan,

My advice to one and all is *NEVER* *EVER* use scratch variables


I think that some the issues you listed, like obfusicating code have a lot more to do with design than anything else. A scratch variable called $PARM is just plain hideous. However, if the person putting together the database suffers from the same poor naming skills, your files could be equally obscure.

Going the route of using only file variables has its own drawbacks as well. For example, the file variable may be set in LS 1, and written in LS 3. This presents its own challenges for debugging.

One thing that we did in-house was to develop a scratch variable assessment tool. It's quite useful for figuring out when scratch variables are being used in an unbalanced fashion. (example: set, but never inquired)

#23 Dan Shannon

Dan Shannon

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 374 posts
  • Gender:Male
  • Location:Australia

Posted 08 February 2005 - 11:07 PM

My advice to one and all is *NEVER* *EVER* use scratch variables


Joseph

Of course when I give that advice, it's only advice - the real point is to try and get people to think about why they need to use a scratch variable, indeed if they need to use one at all. Many people just do it as a matter of course, and that's plain slack programming. Obviously sometimes you really do need to use them!

Cheers

Dan

#24 Joseph Bove

Joseph Bove

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 756 posts
  • Gender:Male
  • Location:Ramsey, United States

Posted 09 February 2005 - 02:41 PM

Dan,

Many people just do it as a matter of course, and that's plain slack programming


Point taken.

I think that all programmers probably loathe having to look at someone's code and not understand it... or worse yet, look at our code several months later and not understand it. :p

Regards,

Joseph

#25 Sindre Solem

Sindre Solem

    Member

  • Members
  • PipPip
  • 46 posts
  • Gender:Male
  • Location:Trondheim, Norway

Posted 10 February 2005 - 01:33 PM

"Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live."

#26 Joseph Bove

Joseph Bove

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 756 posts
  • Gender:Male
  • Location:Ramsey, United States

Posted 10 February 2005 - 02:32 PM

"Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live."


I like that quote. However, if a good chunk of the time, I will end up maintaining my own code, wouldn't I end up with a pretty negative view of myself? :p



Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users