I am looking for a way to determine if a database is intended to be a replication source or target. Ideally this could be determined via VSTs or a meta-schema table.
The _Database-feature meta-schema table *almost* works. You can determine that replication is enabled. But not if you are a source or target :(
There are VSTs like _repl-agent and _repl-serv but they only exist when the repl server or the repl agent are *running*. Which is unhelpful if you are trying to determine if they _should_ be running.
The proutil -C describe utility knows -- it shows output similar to:
...
Database Features
ID Feature Active Details
---- --------------------------------- ------ -------
1 OpenEdge Replication Yes Source database
When a db has replication enabled. That would be perfect except for the need to run an external command and parse its output -- that really seems kludgy. Surely there is something within the meta-schema or VSTs that I am overlooking?
You could try comparing the data in the respective _DbServiceManagerObjects VSTs (11.6+). When I look in a repl source, it has a record for Server but not for Agent. It has a status field, which suggests the record will still be there even if the associated process is not running.
This is what I see right after enabling replication as a source (but not actually starting a replserv):
ID: 1
Service Object N: OpenEdge RDBMS
Service Object R: Y
Service Object S: REG
Number of Servic: 0
PID of Lock Hold: 0
User Type of Loc: Not available
User Number of L: 0
a bit like Proutil. ...
try using the <db>.repl.properties files
Replication source have section denoted by [server]
Example assumes Linux or Unix flavour.
input through value("grep '\[server\]` <db>.repl.properties files 2> /dev/null")
import v-result.
input close.
v-source = v-result > "".
or you could define a environment variable and just use os-getenv ....
I'm trying to avoid external dependencies.
In the test case that I half explained above all that I have done (so far) is to run "proutil dbname -C enablesitereplication source". There is no repl.properties file (yet).
The problem is to determine if a database *should* have a replication server (or agent) running. So far the most reliable method that I have found is to run "proutil -C describe".
It seems like there must be a field somewhere that I am overlooking.
(Also - in most of my deployments the repl.properties files have all of the stanzas populated. Even the unused ones. That makes it easier when you flip the roles because everything is defined and ready to go.)
Hi Tom,
I assume that you're using earlier version than 12.1. In this case, there is no VSTs for database roles(replication source/target).
In the OE 12.1 version, we expanded the definition of the _DBStatus VST table to have a new field : “DbStatus-DatabaseRole". With this addition, you can query for database roles:
For each _DbStatus.
Message "Database role: " _DbStatus-databaseRole.
For example, on a source database, you’ll get: “Source”. And this will work even when replication server is not running.
However, for replication target, we restrict access when replication agent is not running. This has been identified as a bug and the restriction will be lifted. But still, you can use this behavior to determine if the database is source or not.
I would just stick to/use -C dbdes.
If the db is running you can query _dbparams for -DBService, but your OE version has to be fairly recent for that, if by 'like to avoid external dependencies' you mean stick to ABL client only, on target without REPL+ license you won't be able to use it anyway, hence my suggestion to always use dbdes.
> _DbStatus-databaseRole
That will be great once 12.1 and above are the coin of the realm!
Meanwhile I may have a something that works on 11.5+ where the _dbPparams VST is available. The -ERO parameter is 0 for a replication source and 1 for a replication target (that you can connect to). That is a step forward.
-dbservice only works if you've specified it, I'm trying to detect situations where people mess up and forget stuff like that
Without the -dbservice the db would not start and (not) be running. I did say when db is running .....