![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 7 of 7 total |
![]() |
Wed, Oct 12 2011 5:31 AM | Permanent Link |
gordon | I have a problem using filters over a LAN in a multi-user file server setup. I have a log table that is being constantly written to by an event handling exe (BCB6), 150+ records per second when logging is heavy.
Table structure is 'autoinc:string(20):date:time:string(128)' with primary index 'autoinc:string(20)' and secondary index 'string(20)'. A second exe (D7) displays the logs using a simple TDBISAMDatabase - TDBISAMTable - TDataSource - TDbGrid arrangement. The user can apply up to 8 filter conditions, in the form " string(20) = 'xxx' OR string(20) = 'yyy' " depending on which log messages they want to examine. ( the string(20) field is a simple ascii identifier of what the log message refers to, such as 'System' or 'Database' ). When I run the second exe on the local PC it appears to work perfectly well, but, if I run the second exe on a remote pc, applying filters will invariably lead to the exe crashing, either with an access violation or 'invalid pointer operation' errors. Although I can't be sure, it seems to me that the crash occurs mainly when I apply a filter at a moment when I know lots of log messages are being written to the table. Is there a particular reason why I can't apply filters remotely to a table that is being written to heavily? Is there any documentation or example code for how best to use filters with DBISAM in this regard? |
Wed, Oct 12 2011 7:00 AM | Permanent Link |
Adam Brett Orixa Systems | I am not answering your question, just saying that I had similar-ish problems to this in the past (not exactly the same) and I moved to using TDBISAMQuery with flexible WHERE String rather than TDBISAMTable with FILTER statement & this solved the problem for me.
I use the form: QuerySQL := ' SELECT Somefields FROM Sometables % '; RefreshData(aWhereStr: String); begin Query.Close; Query.SQL:= FORMAT(QuerySQL, [aWhereStr]); Query.Open; end; The query is CANNED (ResultIsLive := false) ... I get the results back really fast even if there is a lot of action on the table. It might be that ensuring your TDBISAMTable.ReadyOnly is TRUE might help things?? -- Another obvious problem I can see is that with such complex & varied FILTER statements DBISAM is unlikely to be able to optimize the query, so getting the result back is bound to be a bit slow. That doesn't explain the AVs you are complaining about though. Adam |
Wed, Oct 12 2011 10:22 AM | Permanent Link |
Robert Kaplan | <Adam Brett> wrote in message news:3DB5418F-2BF6-4E66-B377-F49D0902E467@news.elevatesoft.com... >I am not answering your question, just saying that I had similar-ish >problems to this in the past (not exactly the same) and I moved to using >TDBISAMQuery with flexible WHERE String rather than TDBISAMTable with >FILTER statement & this solved the problem for me. > > I use the form: > > QuerySQL := ' SELECT Somefields FROM Sometables % '; > > RefreshData(aWhereStr: String); > begin > > Query.Close; > Query.SQL:= FORMAT(QuerySQL, [aWhereStr]); > Query.Open; > > end; > That would be the equivalent to closing and reopening the table, which I suspect would also cure the symptom. Still not answers why this is happening in the first place. Robert |
Tue, Oct 18 2011 5:20 AM | Permanent Link |
gordon | Thanks for the response.
I haven't had time to replace the table with an SQL query component yet. I made the table component read only but it made little difference. I did get a new error, 'DBISAM Engine Error #11047 Unknown operating system error 0' but eventually the program crashed with an AV. This still only happens when the program is accessing the table over a LAN. Gordon |
Tue, Oct 18 2011 8:23 AM | Permanent Link |
Robert Kaplan | <gordon> wrote in message news:83237EE1-7CC0-4044-81CC-D7C441808E01@news.elevatesoft.com... > Thanks for the response. > > I haven't had time to replace the table with an SQL query component yet. I > made the table component read only but it made little difference. I did > get a new error, > > 'DBISAM Engine Error #11047 Unknown operating system error 0' > > but eventually the program crashed with an AV. This still only happens > when the program is accessing the table over a LAN. > Is the filter an SQL statement or is it processed in OnFilterRecord? Robert |
Tue, Oct 18 2011 12:06 PM | Permanent Link |
gordon | I'm using the filter property of the TDBISAMTable component. A typical filter string is shown below,
dbSource1.dataSet.Filter := '(tag = ''Agent'') OR (tag = ''System'') OR (tag = ''Database'')'; Gordon |
Fri, Oct 21 2011 2:12 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | Gordon,
<< I haven't had time to replace the table with an SQL query component yet. I made the table component read only but it made little difference. I did get a new error, 'DBISAM Engine Error #11047 Unknown operating system error 0' but eventually the program crashed with an AV. This still only happens when the program is accessing the table over a LAN. >> Something external is not behaving correctly. You should not be seeing an AV or 11047 error during a filtering process, regardless of the amount of update activity by other users/sessions. Have you tried replicating the issue on a single machine ? That is always the first step that I take in such a situation. If the problem cannot be replicated on a single machine, then the issue is not with DBISAM, locking, amount of activity, etc., but rather with the LAN or the network services. Another option is to use the DBISAM Database Server, which will help by eliminating the LAN and network services from the equation. -- Tim Young Elevate Software www.elevatesoft.com |
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 ? ![]() |