At 03:57 PM 20/06/2005 +0200, you wrote:

>Helen Borrie schrieb:
> > At 12:44 PM 20/06/2005 +0200, you wrote:
> > In triggers (which apply to inserts, updates and deletes) the "NEW."
> > context variables supply this information. If you don't know about them,
> > ask again.
>
>I know about the NEW. variables, but not which data(context) they can
>contain :-) Do you have a link for a docu of this types of variables? I
>couldnt find something about. Or do you have a possibility
>(SQL-statement) to get the hole context possibilitys?
>
> >
> > For selects, there are no context variables.
>
> > Unfortunately your problem description is decidedly
> unspecific. Perhaps if
> > you provided an example of what you need to in the run-time situation, we
> > can hone in on a solution.
>
>I tried to use some replicators, but all are using dialect 3.

??? That does not compute. :-/

>If I
>change the dialect in the merchandise information system from 1 to 3 it
>stops working.

The dialect of the client library has to match the dialect of the
database. If you are planning to connect to a dialect 1 and a dialect 3
database using one client, you are going to encounter problems. If you
can't change the existing database to dialect 3, then rebuild your own
database as dialect 1.

>That is one problem with the replicators. Another problem
>is, that they dont use encrypted connections so far as I can see.

No. You can use an SSH tunnelling software to do this.

>The last big problem is, that I have to integrate the configuration into
>the merchandise information system. All that is not really wise possible
>with an existing replication system.

That still doesn't figure. Every replication system is custom built to
synchronise specific source and target databases.

>My idea is to create an additional table, in which a trigger fires the
>datasets in that have changed (insert,update,delete). I want to update
>only the exact change of a dataset, not the hole one. Thats why I need
>the field-NAME of the field that changed in the dataset.

In an After Update trigger on the table(s) that change, you would do
something along the following lines:

create trigger au_atable for atable
active after update
as
begin
if (exists (
select id from blah
where id = new.atable_id)) then
begin
if ((new.anotherfield <> old.anotherfield or ({various tests for
null})) then
update blah
set whatever = new.anotherfield
where id = new.atable_id;
....
end
else
begin
insert into blah (......)
....
end
end

>An external skript is reading this tabel and updates every dataset
>through a ssh-connection. I wrote a server and a client for the
>datatransfer wich uses a ssh-tunnel. On the other side the dataset is
>written into the database through the server. Some tables have to be
>bidirectional updated, but only some.

Cut your cloth to suit your coat. A script by itself can't do all that you
need. Triggers support the conditional logic that you need to make this
work. If you have a trigger on tableA that updates or inserts to table
blah, and blah needs to respond in some way, then you will probably need
either Before or After triggers on blah to do more work.

./heLen