> My goal is for a connection to receive signals from other connections.
> E.g., I would get the information about changing a row of a table by
> an other connection. This would be great having the information at once.
> An ugly and slow solution is to send queries to the server e.g. twice
> a minute or so---but is there a better way?
afaik we need multithreaded clients (and servers) to be able to do this.
It would be a nice capability, but asynchronous communication requires
that you set up a separate thread to receive a callback. I'm pretty sure
we have none of the required infrastructure in our existing
communication protocol.
> Browsing the documentation I found NOTIFY and LISTEN. Can I use them
> within an ODBC connection? Is it possible to catch a NOTIFY signal this way?
LISTEN happens on a table (or actually any arbitrary name; it doesn't
need an underlying object). But afaik you have to do a query to get your
LISTEN to fire on the client, since none of our clients are
multithreaded.
> As I realized, the NOTIFY statement doesn't have a second parameter,
> i.e. I cannot give any other signal to an other connection than
> "Yes" or "No". What about future plans?
No future plans afaik. Commercial Ingres allowed a text string to be
associated with a NOTIFY message, which presumably would require a more
involved (and difficult to manage) underlying structure to be created.
- Thomas