![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Client/Server » View Thread |
Messages 1 to 8 of 8 total |
![]() |
Wed, Jul 12 2006 8:54 PM | Permanent Link |
"Johnnie Norsworthy" | Howdy all!
My application works great on a local area network, but less than desirable when running across the internet. I have done all the tricks I can think of and I have read about here to speed things up. The first thing I do is run a query and use Query.SaveToStream and then Table.LoadFromStream with the table saved as a local memory table. This makes the DevExpress quantum grids in "Load All Records" mode work great. I get a few hundred records in the grid in about 10 seconds across the internet which is completely acceptable. But the problem I have now that is bogging me down is that the grid table functions like a master table and when a selection in the grid changes, I change some filters for a few detail tables. I am using a TTimer to start the detail synchronization about .5 seconds after a master record focus changes. The problem is, the changing of the detail table filters is taking a very long time (5 seconds or more each time) and the program seems very unresponsive. Does anyone have similar circumstances and have come up with a solution? Threads? Application.OnIdle? I don't know where to start for testing what will work best. On a local area network the application screams along at what I like to call "keyboard repeat rate" responsive. (That is you can hold down the arrow key and it never hiccups). I am hoping on borrowing some superior wisdom of the DBISAM Community. -Johnnie |
Thu, Jul 13 2006 12:43 PM | Permanent Link |
"David Farrell-Garcia" | I use ClientDataSets to cache all the data on the local machine. I
then have no latency when scrolling grids with Detail Records. Lookup tables are saved to local .cds tables so even lookup fields work great. |
Thu, Jul 13 2006 2:13 PM | Permanent Link |
"Johnnie Norsworthy" | "David Farrell-Garcia" <davidF@WhidbeyIslandSoftware.com> wrote in message
news:D993A5CB-1412-48B2-9DA2-FD8EBB828CE0@news.elevatesoft.com... >I use ClientDataSets to cache all the data on the local machine. I > then have no latency when scrolling grids with Detail Records. Lookup > tables are saved to local .cds tables so even lookup fields work great. I cache the grid data and lookups, but I can't cache all of the detail data because there is too much, and I'd like the detail data to reflect changes made by others. -Johnnie |
Thu, Jul 13 2006 10:39 PM | Permanent Link |
"David Farrell-Garcia" | Johnnie Norsworthy wrote:
> I cache the grid data and lookups, but I can't cache all of the > detail data because there is too much, and I'd like the detail data > to reflect changes made by others. How much detail per master record are we talking about? In my case I have work orders that may have several to hundreds of detail line items. When viewing a selected list of work orders (Master) the details are only fetched when the user chooses to do so by clicking on a detail tab. Then all detail records for that master record are fetched and cached. This is a better user experience then fetching the details automatiaclly when a user scrolls a grid. |
Thu, Jul 13 2006 10:42 PM | Permanent Link |
"David Farrell-Garcia" | Johnnie, I forgot to ask:
I assume that you are using a higher compression level for Internet connections, right? |
Fri, Jul 14 2006 3:19 PM | Permanent Link |
"Johnnie Norsworthy" | "David Farrell-Garcia" <davidF@WhidbeyIslandSoftware.com> wrote in message
news:EB71341B-FA43-4F6D-AAF7-FDC97D110DE7@news.elevatesoft.com... > Johnnie Norsworthy wrote: > >> I cache the grid data and lookups, but I can't cache all of the >> detail data because there is too much, and I'd like the detail data >> to reflect changes made by others. > > How much detail per master record are we talking about? In my case I > have work orders that may have several to hundreds of detail line > items. When viewing a selected list of work orders (Master) the > details are only fetched when the user chooses to do so by clicking on > a detail tab. Then all detail records for that master record are > fetched and cached. This is a better user experience then fetching the > details automatiaclly when a user scrolls a grid. They are just used to the details appearing as they scroll, and there are a bunch of DB-Aware visual controls being displayed including a second detail grid, but I might make a UI change only when connected remotely to not give all the details. I haven't tried the compression yet (slaps head). I'll have to do some timings with different compression settings and see what I get. Thanks, Johnnie |
Sun, Jul 23 2006 3:50 PM | Permanent Link |
"Rob Frye" | Hi Johnnie
I have the same problem (ie. multiple detail tables that have to stay in sync with the master). Have you had any luck resolving it? Rob "Johnnie Norsworthy" <jln206@verizon.net> wrote in message news:9AFAD573-FFAC-45BE-88C1-09E93A0BE6A6@news.elevatesoft.com... > But the problem I have now that is bogging me down is that the grid table > functions like a master table and when a selection in the grid changes, I > change some filters for a few detail tables. I am using a TTimer to start > the detail synchronization about .5 seconds after a master record focus > changes. The problem is, the changing of the detail table filters is > taking a very long time (5 seconds or more each time) and the program > seems very unresponsive. |
Sun, Jul 23 2006 4:00 PM | Permanent Link |
"Johnnie Norsworthy" | "Rob Frye" <rfrye@telus.net> wrote in message
news:096C482D-7F3A-45E6-8F20-B045A69482B7@news.elevatesoft.com... > Hi Johnnie > > I have the same problem (ie. multiple detail tables that have to stay > in sync with the master). Have you had any luck resolving it? Not really solved yet. I have a couple of ideas in mind: I was thinking about doing was creating a low priority thread which would update the detail information. I have not figured out all the necessities of that because the thread would be an observer and would have to be able to immedietly restart if the master record changed, as in fast grid scrolling. I like this idea, but haven't tried the implementation yet. The other option I have considered is detaching all detail tables until the user wants to view them, but only for internet connections since LAN connections are fast. In my case the details are displayed on a page control, so I could set it up to only request the data for the currently displayed page. Lots of complexity here too. I already have cached all my grid data from the server into a local memory table, which seems to help a tiny bit. -Johnnie > "Johnnie Norsworthy" <jln206@verizon.net> wrote in message > news:9AFAD573-FFAC-45BE-88C1-09E93A0BE6A6@news.elevatesoft.com... >> But the problem I have now that is bogging me down is that the grid table >> functions like a master table and when a selection in the grid changes, I >> change some filters for a few detail tables. I am using a TTimer to start >> the detail synchronization about .5 seconds after a master record focus >> changes. The problem is, the changing of the detail table filters is >> taking a very long time (5 seconds or more each time) and the program >> seems very unresponsive. > > |
This web page was last updated on Wednesday, August 14, 2024 at 07:31 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |