cancel
Showing results for 
Search instead for 
Did you mean: 

Executing SQL Remote (dbremote) from database

Former Member
2,224

Is it possible to start the SQL Remote process from the database, or do you need to run the executable dbremote.exe?

Are there any stored procedures to start the message agent?

Accepted Solutions (1)

Accepted Solutions (1)

VolkerBarth
Contributor

You can run the DBREMOTE program or use the DBRemoteSQL() function as part of the DbTools API but there is no particular way to start SQL Remote from the database engine.

However, you can start any external program by xp_cmdshell or call external functions, so that would be possible pathes.


If SQL Remote is to be used in batch mode (i.e. not in continuous mode) at the consolidated, one might use a database event to establish some kind of "pull replication": Say, you would like to send messages to the remotes when a "product" table gets updated. A trigger on that table could then trigger an event that would call SQL Remote automatically to generate according messages. Likewise, one could use a database event with a particular schedule to let SQL Remote run at specific times...

Former Member

This works fine as long as the data flows out of the consolidate db. But you will need to make sure incoming messages are also retrieved and processed by dbremote.

VolkerBarth
Contributor
0 Kudos

Yes, for sure.

In case that should be triggered "automatically" from within the database as well (i.e. still using "batch mode"), one idea would be to use a directory server to access the SQL Remote "inbox" and to check that (e.g. by polling in regular intervals) for new entries and make SQL Remote run when a sufficient number of new message files has appeared. - One might ignore "ping messages" then...

Note: I have not implemented such a system; however, we use a similar - though probably much more performant - way by OS file notifications to trigger SQL Remote when messages appear in the inbox.

Breck_Carter
Participant
0 Kudos

AFAIK dbremote automatically applies any messages that have been sent up from a remote database, and that you have to do something like dbremote -a to stop it from doing that.

VolkerBarth
Contributor
0 Kudos

Yes, I agree - though one would usually use "dbremote -s" to prevent the receiving phase altogether, whereas -a would just ignore the application of received messages but possibly purge them.

I guess André's comment (and my response) were just a reminder that while thinking about events to trigger SQL Remote to send messages one should not forget that there might be reasons to receive messages, too. For the rather theoretical discussion on triggering SQL Remote immediately "when product information changes", one might have a situation where this would appear infrequently - and that should usually not prevent the application of frequently sent messages from remotes:)

Answers (0)