Shockingly slow form realisation - Forum - OpenEdge Development - Progress Community
 Forum

Shockingly slow form realisation

  • Bit of cross posting creeping in.

    no direct correlation between the number of records and the number of find triggers>> did you change the count (or add a second) so that we know how many finds are a result of the QUERY-OPEN v's the assign of the datasource?

    Try with TT >> wont be as lucky, no find trigger with TT's (me thinks?!?)

  • Try isolating/resetting the find count to

    before/during the binding.

    I have done - it's the same value.

    Also try SuspendRowSynchronization and

    ResumeRowSynchronization calls on the combo (rather

    than Begin/EndUpdate - see last post).

    tried that - no effect

  • May not help, but you may not be alone;

    http://devcenter.infragistics.com/Support/KnowledgeBaseArticle.aspx?ArticleID=9280

    Again with the currency manager trying to stay in sync with the control during the load of data.

    Came across this from point 6 of http://forums.infragistics.com/forums/p/15306/57637.aspx. However you may get away with the sync manager changes from bottom of point 1 (basically do both of my prior suggestions - ie BeginUpdate & SuspendRowSynchronization

  • You should be able to build a sportsdb test example for your report - not sure how easy it will be to solve though, as what you are seeing is correct when the user picks an item (ie you want the select Orders recorded to be loaded/positioned), just not desired when loading data.

    Perhaps in the 'next release' the probinding can have a begindataload/enddataload to indicate if it should ignore currency position requests (and only position to the last request at the enddataload invoke).

    The equiv in pure .Net would be the dataset/datatable, which is disconnected much like your TT observation. Came across a few posts like yours related to both the grid & combo ultra controls - so you may need to keep a watch on these as well.

  • I did write some code against the sports database : See demo.cls attached to an earlier posting.

    This all came about because I was trying to load 100 records into a combo for a user to choose, and the delay was really noticeable.

    Unless I can find something to "fix" this, I will need to move to another control like the radcombo - there is no performance problem with this one. Again, see the earlier posts.

  • This has got really interesting now. This is a simplified demo program now - with a find trigger built into the class, and an option to use a TT instead.

    To run, use the following code:

    attempt#1

    run the program above.

    the number of records read goes to 10707 - there are 207 records in the table

    every time you drop down the combo-box, note that the number of records read increases by over a 100 every time ....

    attempt#2

    change UseTT to "yes" in demo.cls

    run the program above.

    note that the form appears instantly, with all records in.

  • attempt#1

    run the program above.

    the number of records read goes to 10707 - there

    are 207 records in the table

    every time you drop down the combo-box, note that the

    number of records read increases by over a 100 every

    time ....

    I'm curious if this shows up when running promon against the db?

    This also confirms that the problem was an excessive amount of reads, as I'd posited earlier!

  • I'm curious if this shows up when running promon

    against the db?

    It does indeed.

    Record Reads: 11171 385/2 per seconds

    This also confirms that the problem was an excessive

    amount of reads, as I'd posited earlier!

    Hail! Hail! All hail Tim !

  • when I use the radcombo control instead of the IG, promon only gives 465 reads ...

  • Hail! Hail! All hail Tim !

    LOL - let's not get too silly. I'd prefer tweaking TMH on the nose for dismissing this as a possible cause (or effect, if the problem's actually in the control)...

  •  * jmls tweaks TMH's nose ...

  • I would like to say thanks to all for looking at this and suggesting various things. It's actually a very nice "trail" for Tech Support to follow and hopefully identify the problem.

    Thanks again to everyone.

  • Woot! Psc Tech support have reproduced the problem .. yay ..

  • Logged has bug#OE00180488

    speeelin is niot my strung poitn

    Message was edited by:

    Julian Lyndon-Smith