Hi Tim,

I was just wondering how DBISam communicated between the client and server?

Does it use internal protocols, or is every command sent via a SQL
statement, and if the latter how difficult would it be for someone like
myself to create a log file of every command received by the server?

Cheers mate

Adam.

Adam,

<< I was just wondering how DBISam communicated between the client and
server? >>

It uses its own binary message protocol in a request/response pattern
initiated by the client's remote session.

<< Does it use internal protocols, or is every command sent via a SQL
statement, and if the latter how difficult would it be for someone like
myself to create a log file of every command received by the server? >>

You can do so quite easily on the client via the OnRemoteTrace event
handler.  If there's a particular reason why you need each request on the
server, I can certainly consider adding this.  It's not especially hard to
do.

--
Tim Young
Elevate Software
www.elevatesoft.com

Good Morning Tim,

I hope you had a great weekend!

> You can do so quite easily on the client via the OnRemoteTrace event
> handler. If there's a particular reason why you need each request on the
> server, I can certainly consider adding this. It's not especially hard
> to do.

What I'm looking for is the ability to create a log of every command
sent, so later when clients asked 'who changed this field, when, etc',
etc I can go back through the log and tell them when it occurred, what
the old value(s) were, etc.

I was thinking that having it on the server might be more simple than on
the client - less overheads to the clients comptuer, and the log would
need to be stored on the server anyway.

Do you think this the best method of achieving this?

Cheers

Adam.

Adam

>Do you think this the best method of achieving this?

The best approach is DON'T

I've built detailed logging into apps several times and either ended up taking it out or just deleting the log files at intervals because they were never used.

Roy Lambert

Roy
>
> The best approach is DON'T
>
> I've built detailed logging into apps several times and either ended up taking it out or just deleting the log files
at intervals because they were never used.
>

While I think you are right for a lot of apps we find it included as a "must have" in many of the tender specifications
we bid for.

Adam - I think there was a thread on here (search for logging?) which offered some ideas for generic logging.

John

Adam,

<< What I'm looking for is the ability to create a log of every command
sent, so later when clients asked 'who changed this field, when, etc', etc I
can go back through the log and tell them when it occurred, what the old
value(s) were, etc. >>

Ahh, what you want in that case is to customize the server and add some
triggers for the desired tables.  You can find out more information on that
here:

http://www.elevatesoft.com/manual?action=viewtopic&id=dbisam4&product=d&version=7&topic=Customizing_Engine

under "Triggers".

To do so is just a matter of opening up the dbsrvr.dpr project that ships
with the DBISAM Database Server under the \servers\dbsrvr\source
subdirectory of the main installation directory, making the changes, and
then recompiling.

The beauty of the triggers is that it is very easy to simply isolate them
around a certain set of tables, which is nice when you have outside
regulations specifying that certain payment/transaction tables have an audit
trail.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

Thanks for your reply. Triggers might do just what I'm looking for. At
this stage I'm considering something like the following:

var
 i : integer;
 Msg : TStringList;
 ID : String;
begin

if debughook <> 0 then
if (AnsiCompareText(TableName,'log')<>0) then
  begin
   Msg := TStringList.create;
  for I := 0 to CurrentRecord.fieldcount - 1 do // Iterate
    if CurrentRecord.fields[i].fieldkind = fkdata then
      if CurrentRecord.fields[i].value <>
CurrentRecord.fields[i].oldvalue then
       if (uppercase(CurrentRecord.fields[i].fieldname) <> 'INERROR') then
          Msg.add('Field: ' + CurrentRecord.fields[i].fieldname +
       ' changed from "' +    
      vartostr(CurrentRecord.fields[i].oldvalue) + '"  to "' +
      vartostr(CurrentRecord.fields[i].value) + '"');

       if msg.text <> '' then
     AddToLog(TableName, CurrentRecord.RecordID, Msg);

       msg.free;
       Msg := nil;
      end;
end;

I could do a similar thing on the delete. This way I can trap any
alterations or deletions to records at a low level.

Cheers for the help!

Adam.

Hi Roy,

In part I agree with you, but when the end customer wants it, I've
learnt that it's better to give them what they want, instead of telling
them what I think is best for them

If they're not used in the end, it'll be easy to remove - it looks like
using triggers will be a simple way to achieve what I'm chasing.

Cheers mate

Adam.

John


I know. The spec was probably put together by a management consultancy who have no understanding of the real world, or by a government department which is even worse. When I was in consultancy (a big form) I was permanently arguing with the partners over issues like this.

Roy Lambert