Showstopping performance issue with a TwwDBLookupCombo

Follow

Columbus Systems

• May 02, 2021 22:05
• Edited

This performance issue is similar to one I had with with a CustomEdit control embedded in a TwwDBGrid that I posted here some weeks back  (regarding a migration from Delphi 5 with InfoPower 3K to Delphi 10, InfoPower 4K); but the lookup combo isn't embedded in a grid, just displayed regularly as part of the form it's in.

When I click on the drop-down, the dreaded spinning circle appears, and the machine chokes - for maybe five minutes at a minimum - with the CPU usage spiking substantially.  The drop-down eventually appears, but I don't think the user would want to touch the lookup again.

I did a certain amount of trace-through of the code, and it seems to pass kidney stones when the LookupTable dataset gets opened.  Beyond that I'm not sure what the snare is.  As with the previous problem I reported, the corresponding code in the Delphi 5 version manifests no such performance issue.  Any reports of this sort of behavior?  Not including my previous post, that is?

0

• 

  Roy Woll

  • May 06, 2021 00:10

  Most likely you have OrderByDisplay set to true, and it is changing the index of the lookuptabla.   Changing the index name should be a fast operation, but perhaps it is slow with your driver. Try setting OrderByDisplay to false.

  0

  Comment actions Permalink
• 

  Columbus Systems

  • May 06, 2021 16:24

  Giving it a try.  I'll let you know.

  0

  Comment actions Permalink
• 

  Columbus Systems

  • May 06, 2021 17:27

  OK, I set the OrderByDisplay property to false for the control, did a full rebuild, and tested the dropdown.  I allowed the process to chew its cud for about a half an hour, at which point it finally unfroze.  Long story short, no dice.  Hindsight is 20/20, though - after our application had been staring at the sun for long enough, I recalled that the LookupTable dataset was just a heap table, and so since it has no indexes OrderByDisplay wasn't really applicable.  Thanks for the idea at least.  Anything else I might try?

  0

  Comment actions Permalink
• 

  Roy Woll

  • May 07, 2021 16:19

  How many records in your lookuptable? If there is no index, it would have to sequentially search through to find the looked up record.  Unless you have a small lookup result, I would not do this.

  0

  Comment actions Permalink
• 

  Columbus Systems

  • May 07, 2021 16:29

  Certainly the size of the table in question is contributing to the problem.  I've coded a workaround that seems to suffice in this case - a special filtering mechanism that reduces the rows the dataset returns down to a relatively small number, which seems to result in some tolerable performance.  It's kind of elaborate though, and I don't know how well the technique would serve in other instances.  Too bad OrderByDisplay didn't work - that would certainly have been a simple enough fix.

  0

  Comment actions Permalink

Please sign in to leave a comment.