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?

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

<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

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

<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

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

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