How can I verify my client session is connected to the same database as my AppServer session?
The idea here is to verify the configuration to avoid a mix up. Consider there is a 4gl/ABL client-networking session. There is an AppServer broker configured. Once the 4gl session is connected to the AppServer what values can be examined to confirm they are both connected to the same database?
4gl procedure can be run from the client and AppServer sessions to get values to examine. I am not thinking of what value I can examine that will be different. Is there a value for the name or IP of the server that the DB is on?
Here is an example of error I want to catch. If someone restored a version of the same database onto a 2nd server on the same network. This might have been done getting ready to move to a new server. Even when the live database continues to be used. At this point if configuration values are not accurate there is a risk a client session connected to 1 database can be connected to an AppServer broker connected to the other database. DB names, CRC, schema, local DB path values, all match.
For the case the same server is used for the restored DB and a different path is use; I found VST _areaextent._extent-path can be used.
OE 11.5.1
OS: Windows
Are they shared memory? or client/server?
Can you query the _servers VST for the process and port number or something like that? https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/dmadm/servers-(-servers).html
I have also used the output from proutil -C describe for this type of thing:
display_banner=no; export display_banner; proutil /mypath/mydb -C describe
Then the output looks like so. You should continue to get the same output from the same database as long as it is running.
OpenEdge Database Description
Database Name : /mypath/mydb
Version : 173.0
Block Size : 8192
Largest Cluster : 64
Create Date : Thu Nov 22 20:01:08 2007
Last Open Date : Sun Mar 4 02:07:03 2018
Prior Open Date : Sun Mar 4 02:07:03 2018
Schema Change Date : Fri Mar 2 15:32:26 2018
Before Imaging information
Block Size : 8192
Cluster Size (16K Units) : 2048
Last Open Date : Sun Mar 4 02:07:05 2018
Backup Information
Last Full Backup Date : Sun Mar 4 00:20:02 2018
Last Incremental Backup : *** Not yet performed ***
Database Features
ID Feature Active Details
---- --------------------------------- ------ -------
5 Large Files Yes
9 64 Bit DBKEYS Yes
10 Large Keys Yes
11 64 Bit Sequences
The output will change once the database is restarted or modified. It should be virtually impossible for different databases to return outputs that match each other. (Even if one was a restored copy of the other's backup).
You might try comparing something in _dbStatus such as the last backup or "last open" timestamp. It should be stable from moment to moment (unlike something such as the last TRX num that could change very rapidly) and it would be very unlikely for two different databases to have the same value.
> Isn’t there a db GUID in (relatively) recent versions?
There is: _db._db-guid. I thought it was originally just used with auditing (10.1A+), but I could be wrong about that.
I see that it is populated in DBs of various vintages in both 10.2B and 11.x.
> Can you query the _servers VST for the process and port number or something like that?
Two clients could connect to different 4GL broker ports on the same DB, assuming the DB has multiple brokers of the same server type, so that could in theory be a false positive. Though, taken on the whole, the info in _servers (list of brokers and servers, their ports, their PIDs) should be practically unique.
This is another reason why I think it would be useful to have a VST field for DB server hostname. I have an "idea" for that:
Check DBPARAM() function (or _DbParams. _DbParams-Name since 11.5) for the "-H" value. If not available then use OS call to get the current hostname.
find first _Filelist no-lock.
display _Filelist._FileList-Name.
It gives the full path to the database. Don't use the _AreaExtent.
Host name + full pathname will identify a database.
> It gives the full path to the database. Don't use the _AreaExtent.
I've been using _areaextent._extent-path but it doesn't contain the full path in a relative-path DB. Thanks for the tip George! :)
> Check DBPARAM() function (or _DbParams. _DbParams-Name since 11.5) for the "-H" value.
Just to play devil's advocate... I've seen DBs started with "-H 0.0.0.0", so it's possible the _dbparams approach won't always provide a meaningful answer.
I think Peter's solution might be the winner, provided _db-guid always has a value.
> I've seen DBs started with "-H 0.0.0.0", so it's possible the _dbparams approach won't always provide a meaningful answer.
"0.0.0.0" or "localhost" values would mean that we need to replace them by the current hostname.
Solution with the -H parameter will not work if a box has the multiple NICs. In this case I would check a broker's PID and its startup time. It's very unlikely that two databases on two different boxes were started exactly at the same time and their brokers got the same PIDs. And of course two databases started on the same box at the same time can't have the brokers with the same PID.
> I think Peter's solution might be the winner, provided _db-guid always has a value.
The value is not set in early Progress versions. The value is the same for source and target databases while the client's sessions are often connected to both source and target databases.
find first _Connect where _Connect-id eq 1. display _Connect-PID _Connect-Time _Connect-IPAddress .
It would solve the problem but unfortunately _Connect-IPAddress is unavailable for the processes connected through shared memory (Defect PSC00328031) .
If it will be fixed then we can solve another problem: how to identify the connections of a session to the multiple databases.
Should be possible to get the PID of your sessions and then check them againt the _Connect table.
It's possible that there is another process with the same PID running on different box.
True, but that should have a different userid/num.
User numbers of the same Progress session (process) have the different values in the databases the session is connected to.
User names used to be blank in the auxiliary databases. Batch sessions used to run under the same names. Users can change their names during their sessions (at least they do this in the applications running by our customers). I do identify the connections of the same session by an approximate connect time and by OS login name in db logs. But _Connect VST does not store the initial login name - only the current one.
Just FYI, you need to specify the -newInstance switch on theprocopy command to get a new GUID for each database. documentation.progress.com/.../procopy-utility.html . I believe this switch is supported in PCT too.