Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 9 of 9 total |
TDBISamtable slow when closing |
Mon, Jan 28 2008 10:59 PM | Permanent Link |
"Adam H." | Hi Tim,
Found an interesting one today I was hoping you could help with. I have the following code. (Admitidally the LOG table is rather large), however things run quite fast until we hit the close command for the table. (Just to make sure the table wasn't doing anything else, I've tried putting in a .open and ..close again, and trapped the 2nd close, which also takes about a second to accomplish). The code I'm using is as follows: LogT.disablecontrols; LogT.Open; LogT.Insert; LogTDateTime.value := now; LogTUser.value := _Username; LogT.Post; LogT.Close; //Why does it run slow here?!!? LogT.open; LogT.close; // It also runs slow here (nearly a second to accomplish) LogT.enablecontrols; The table in question is a local table (ie, not using the DBISam C/S setup). Are you able to shed some light on this? Thanks & Regards Adam. |
Tue, Jan 29 2008 3:41 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Adam,
<< Found an interesting one today I was hoping you could help with. I have the following code. (Admitidally the LOG table is rather large), however things run quite fast until we hit the close command for the table. (Just to make sure the table wasn't doing anything else, I've tried putting in a ..open and .close again, and trapped the 2nd close, which also takes about a second to accomplish). >> The first place to look is always any table events attached to the TDBISAMTable component. After that, the rest is probably down to the OS trying to flush buffers during the close, etc. -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Jan 29 2008 6:03 PM | Permanent Link |
"Adam H." | Hi Tim,
Thanks for your reply... > The first place to look is always any table events attached to the > TDBISAMTable component. After that, the rest is probably down to the OS > trying to flush buffers during the close, etc. No events on the dataset. Guess it must be the OS flushing buffers. Will try changing the script to SQL to see if this will make things run any faster. Best Regards Adam. |
Wed, Jan 30 2008 2:29 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Adam,
<< No events on the dataset. Guess it must be the OS flushing buffers. Will try changing the script to SQL to see if this will make things run any faster. >> How about lookup fields, calculated fields, etc. ? Also, you might want to rule out an external cause like AV software, etc. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Jan 30 2008 9:50 PM | Permanent Link |
"Adam H." | Hi Tim,
Thanks for the reply. > How about lookup fields, calculated fields, etc. ? Also, you might want > to rule out an external cause like AV software, etc. No on all accounts (except I didn't test for AV and will do). As for converting to SQL, it didn't speed up as fast as I thought it might. Maybe I'm expecting too much speed out of a 30mb table. Cheers Adam. |
Thu, Jan 31 2008 6:02 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Adam,
<< As for converting to SQL, it didn't speed up as fast as I thought it might. Maybe I'm expecting too much speed out of a 30mb table. >> A 30MB table is small. These newsgroups that you're posting on include a 872MB article.blb, a 157MB article.idx, and a 118MB article.dat, and they must be opened and closed for every single NNTP operation in addition to every web request via our web-based newsgroups. -- Tim Young Elevate Software www.elevatesoft.com |
Fri, Feb 1 2008 10:25 AM | Permanent Link |
"Robert" | "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message news:630C130C-413A-47B6-9970-A14F7CD696EB@news.elevatesoft.com... > Adam, > > << As for converting to SQL, it didn't speed up as fast as I thought it > might. Maybe I'm expecting too much speed out of a 30mb table. >> > > A 30MB table is small. These newsgroups that you're posting on include a > 872MB article.blb, a 157MB article.idx, and a 118MB article.dat, and they > must be opened and closed for every single NNTP operation in addition to > every web request via our web-based newsgroups. > I use tables much larger than that, and they open and close almost instanty. You have something there - a control requesting tons of dta, a lookup, an event handler, something - that is causing the problem. Robert |
Mon, Feb 4 2008 7:47 PM | Permanent Link |
"Adam H." | Hi Tim and Robert,
Sorry for the delayed reply - chaotic is the best description for my work load at the moment... >> A 30MB table is small. These newsgroups that you're posting on include a >> 872MB article.blb, a 157MB article.idx, and a 118MB article.dat, and they >> must be opened and closed for every single NNTP operation in addition to >> every web request via our web-based newsgroups. > > I use tables much larger than that, and they open and close almost > instanty. You have something there - a control requesting tons of dta, a > lookup, an event handler, something - that is causing the problem. The dataset was there by itself, no lookups, no event handlers, zippo. However, I haven't had a chance to see yet if there's another program/service that's causing the problem, and I'm becomming suspicious that this may be the case. Thanks for your help! Adam. |
Tue, Feb 5 2008 7:35 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Adam,
<< However, I haven't had a chance to see yet if there's another program/service that's causing the problem, and I'm becomming suspicious that this may be the case. >> If it's not internal to your application, then it is almost always down to some external software mucking around with the file I/O. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Sunday, May 5, 2024 at 07:30 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |