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 tobefore/during the binding.
Try isolating/resetting the find count to
before/during the binding.
I have done - it's the same value.
Also try SuspendRowSynchronization andResumeRowSynchronization calls on the combo (ratherthan Begin/EndUpdate - see last post).
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;
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:
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 ....
change UseTT to "yes" in demo.cls
note that the form appears instantly, with all records in.
attempt#1run the program above.the number of records read goes to 10707 - thereare 207 records in the tableevery time you drop down the combo-box, note that thenumber of records read increases by over a 100 everytime ....
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
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 promonagainst the db?
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 excessiveamount of reads, as I'd posited earlier!
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 ...
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: