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. If I
change the dialect in the merchandise information system from 1 to 3 it
stops working. That is one problem with the replicators. Another problem
is, that they dont use encrypted connections so far as I can see.
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.

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.
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.


Andi