What you indicate is known as reactivity. Traditional data engines do not implement any direct way for applications to know if their information has been modified. After saying this, what you want to do is not impossible, but it is complicated and you should understand the cost, the risks, the potential problems, evaluate how to cover all these elements and with all the cards on the table, evaluate if it is really worth implementing .
An initial idea may be to have an X application that can be invoked from the command line and send some kind of message to your application AND, either by sockets or some other means (eg invoking a REST service). Once you have X built, the idea is to install it in the same OS where your SQL Server server resides and, from the trigger in your table, you can invoke a command that executes X with the necessary parameters. X takes this information and sends it to Y. Note that this has terrible points of failure:
- If the trigger fails, X may be invoked (or not).
- You must ensure what happens if the parameters to send to X are not correct or have invalid data eg.
null
.
- X must support reading the parameters and possibly transform them before sending them to Y.
- The communication between X and Y should not be lost.
- You must have a way to track that the parameters arrived at Y correctly.
- If you are inside a LAN, you may not need to secure the communication channels between X and Y. Otherwise, it must be taken into account.
- Once implemented, evaluate the performance under load of operations that trigger the trigger, thus checking the throughput of your architecture.
Another alternative is to use a reactive database (No SQL) that can notify applications if an event such as the one mentioned occurs. For example RethinkDB . This, clearly, requires a strong change at the architectural level and that also deserves its evaluation.
If you do not want to go through the reactive model, you can use the traditional model of having a cron that consults the table or tables that you require and evaluate if it has changed. In case of detecting changes, your application can perform the corresponding actions.
The decision is yours.
Apparently, SQL Server offers Query Notifications so that a .Net application (not Java) can receive notifications when the data in a query has been modified. This would facilitate the implementation of using an X application and your Y application. It should be noted that X would have to be written using .Net (C #, VB .Net, F #, etc).