|
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... 1
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.
(19 Jun '12, 15:32)
ASchild
Replies hidden
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.
(20 Jun '12, 09:56)
Volker Barth
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.
(20 Jun '12, 10:03)
Breck Carter
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:)
(26 Jun '12, 16:29)
Volker Barth
|
Please be aware that the content in SAP SQL Anywhere Forum will be migrated to the SAP Community in June and this forum will be retired.
Follow this question
By Email:Once you sign in you will be able to subscribe for any updates here
By RSS:Markdown Basics
- *italic* or _italic_
- **bold** or __bold__
- link:[text](http://url.com/ "title")
- image?
- numbered list: 1. Foo 2. Bar
- to add a line break simply add two spaces to where you would like the new line to be.
- basic HTML tags are also supported
Question tags:
question asked: 15 Jun '12, 07:20
question was seen: 2,103 times
last updated: 26 Jun '12, 16:29