Hi,

I'm looking to detect whenever a user updates a record. (insert, delete,
edit, etc). I'm hoping to trap the name of the table that the user updates.

My first thought was to use the DBISamEngine and triggers, but this poses a
problem, as the triggers are done at the server end. (Whereas my application
may be ran as a mixture of local access and client/server).

What I'm needing is to trap whenever a change has been made to a table. Is
there a way to do this in DBISam (regardless of whether the application is
remote or local) on the client side? (I need to do this at a
TDBISamdatabase, session or engine level, not on the individual datasets).

Thanks & Regards

Adam.

"Adam H." <ahairsub4@rREMOVEMEspamSTOPPER.jvxp.com> wrote in
news:647D8511-36C9-4BB2-A7DE-A754547705EC@news.elevatesoft.com:

> Hi,
>
> I'm looking to detect whenever a user updates a record. (insert,
> delete, edit, etc). I'm hoping to trap the name of the table that the
> user updates.
>
> My first thought was to use the DBISamEngine and triggers, but this
> poses a problem, as the triggers are done at the server end. (Whereas
> my application may be ran as a mixture of local access and
> client/server).
>
> What I'm needing is to trap whenever a change has been made to a
> table. Is there a way to do this in DBISam (regardless of whether the
> application is remote or local) on the client side? (I need to do this
> at a TDBISamdatabase, session or engine level, not on the individual
> datasets).

Couldn't you write a trigger that fills a log table in the database with
a TIMESTAMP field and the tablename that's just been updated?

you could compile it into both your remote server and local access
versions, and test in the client whether the database is remote or not
before executing it on the client-side.

Of course, if you want to be notified fast enough to prevent the update
for some reason, this isn't any good.
--
Chris
(XP-Pro + Delphi 7 Architect + DBISAM 4.25 build 4 + EDB 1.04 build 3)

Adam,

<< My first thought was to use the DBISamEngine and triggers, but this poses
a problem, as the triggers are done at the server end. (Whereas my
application may be ran as a mixture of local access and client/server). >>

Are you asking if there is a way to use triggers in the client application
when the application is using a remote session ?  Or just whether you can
use triggers with both local access and the server access ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Adam

Use a Timer and check some properties. It does not matter if it is C/S or
local

var dRef: TDateTime;

in the FormCreate

dRef := Table.LastUpdated; // Table must be opened

in the Timer

Table.Refresh;
if Table.LastUpdated <> dRef then begin
   // table was changed
  // do what you want
  dRef := Table.LastUpdated;
end;

Eduardo

Hi Tim,

> << My first thought was to use the DBISamEngine and triggers, but this
> poses a problem, as the triggers are done at the server end. (Whereas my
> application may be ran as a mixture of local access and client/server). >>
>
> Are you asking if there is a way to use triggers in the client application
> when the application is using a remote session ?  Or just whether you can
> use triggers with both local access and the server access ?

I guess in a way, yes - I'm wanting to use triggers on a client application
regardless of whether the user is using remotesession or not, however I
don't need to know the data changed, just that table x has been updated.

Regards

Adam.

Hi Chris, Tim and Eduardo,

Thanks for your reply.

I'm not looking at having logs recorded. What I'm wanting to do is have a
common datamodule within my application (that loads some larger tables for
'lookup' tables). At present, each form I have has a corresponding
datamodule, but there are some common lookup tables that are relative to
most forms.

So, what I'm trying to achieve is to have the lookup tables in one common
datamodule. If the user changes one of the lookup tables elsewhere in the
application (which can be done by a variety of different procedures), i
would like to tag somewhere at a low level in the application that a
particular table has been modified by the end user, thus causing that
particular dataset on the lookup datamodule to be refreshed. (This way I
don't have to refresh on a timer, etc which will cause performance issues).

I know that I'm able to do this by trapping the afterpost and afterdelete
events on each dataset, but I was hoping not to have to go through hundreds
of datasets on numerous datamodules to assign the code, but instead trap it
lower down.

Thanks & Regards

Adam.

"Adam H." <ahairsub4@pleaseREMOVEme.jvxp.com> wrote in
news:7838E640-C049-427A-999F-DA2F1FE7F4D4@news.elevatesoft.com:
> So, what I'm trying to achieve is to have the lookup tables in one
> common datamodule. If the user changes one of the lookup tables
> elsewhere in the application (which can be done by a variety of
> different procedures), i would like to tag somewhere at a low level in
> the application that a particular table has been modified by the end
> user, thus causing that particular dataset on the lookup datamodule to
> be refreshed. (This way I don't have to refresh on a timer, etc which
> will cause performance issues).

I'm halfway along that path in my present application.

I have about 40 forms each dealing with updating one or two tables, and
one DataModule with all the lookups as queries (so I can include looked-
up names in the lookups).

Each form has a stringlist with all the tablenames it is liable to affect
in it.

After each post, I call the RefreshLookups procedure in the Datamodule,
passing the stringlist to the procedure.

In the procedure, I search all the lookups' SQL.text for any of the
tablenames, and close/open the lookup if found.

This works fine in single-user applications, but now that Jose has
introduced me to Table.LastUpdated I'm probably going to scrap all of it
and use that instead!
--
Chris
(XP-Pro + Delphi 7 Architect + DBISAM 4.25 build 4 + EDB 1.04 build 3)

Good Morning Chris,

> This works fine in single-user applications, but now that Jose has
> introduced me to Table.LastUpdated I'm probably going to scrap all of it
> and use that instead!

Ahh - thanks for that. I missed the lastupdated function too. So
effectively, I can simply put a timer on my lookup datamodule, that goes
through the tables and checks for the lastupdated timestamp (comparing with
a list set previously), and if changed, I can then do a table.refresh to
update the table.

This even works better, as it will also detect changes done by other users!

Thanks for the tip!

Adam.

Adam,

<< I guess in a way, yes - I'm wanting to use triggers on a client
application regardless of whether the user is using remotesession or not,
however I don't need to know the data changed, just that table x has been
updated. >>

Yeah, that's a little bit harder to deal with since a) triggers don't fire
on the client for remote sessions and b) it still will only tell you whether
the current client application modified the table, not whether someone else
modified the table.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

> << I guess in a way, yes - I'm wanting to use triggers on a client
> application regardless of whether the user is using remotesession or not,
> however I don't need to know the data changed, just that table x has been
> updated. >>
>
> Yeah, that's a little bit harder to deal with since a) triggers don't fire
> on the client for remote sessions and b) it still will only tell you
> whether the current client application modified the table, not whether
> someone else modified the table.

I thought that may have been the case. I was hoping that their may have been
another solution, and I was half right. Chris has mentioned the
dataset.lastupdated property which looks like it's going to be a great way
to accomplish the same thing (for my case anyway).

Thanks for your help!

Adam.