Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 10 of 10 total |
Detecting user change in database |
Thu, Sep 27 2007 11:52 PM | Permanent Link |
"Adam H." | 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. |
Fri, Sep 28 2007 11:24 AM | Permanent Link |
Chris Erdal | "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) |
Fri, Sep 28 2007 1:47 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Fri, Sep 28 2007 2:35 PM | Permanent Link |
"Jose Eduardo Helminsky" | 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 |
Fri, Sep 28 2007 9:08 PM | Permanent Link |
"Adam H." | 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. |
Fri, Sep 28 2007 9:09 PM | Permanent Link |
"Adam H." | 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. |
Sat, Sep 29 2007 5:15 AM | Permanent Link |
Chris Erdal | "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) |
Sun, Sep 30 2007 8:31 PM | Permanent Link |
"Adam H." | 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. |
Mon, Oct 1 2007 3:56 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Mon, Oct 1 2007 6:16 PM | Permanent Link |
"Adam H." | 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. |
This web page was last updated on Friday, April 19, 2024 at 07:09 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |