Primary and Standby configuration for Database Connections

It depends on the current setup. Where are the databases hosted? On the Citect servers, or on separate machines? If they are on the Citect servers then you need to consider moving them to a separate machine, otherwise you will have to come up with synchronization features and functions to keep all databases equal.

Do you have separate Citect client machines? If so, do these clients connect to the databases themselves or is that handled by the Citect server?

If the database cicode functions will be running on both redundant servers, for instance if they are called periodically from an event, you have to add a check to these functions to determine if it is running on the active server or server process. It depends on the type of server how to achieve that. For the Alarm servers you can check if ServerInfo("Alarm", 0) = "1". This works also for "Trend" and "Report" server types.

The I/O server can be primary/standby per I/O device, so this check won't work. If you really need to access the databases from the I/O server processes, you could monitor the status of an I/O device with this check: IF ProcessIsServer("IOSERVER", "", IODeviceInfo("PLC1", 17)) THEN ...

Please change "PLC1" to the name of the I/O device you like to check for. I usually use a redundant disk PLC (persistant memory I/O device) for this, because it should always be on-line.

Hello,

In a Primary/Backup IOServer redundant system configuration (IOServerPR + IOServerST) is there any Cicode function to get the current master server?

(IOServerPR or IOSeverST) ????

IOservers do not have the concept of Primary/Standby because it is cascade to IOdevices.
You can use IOdeviceinfo as indicated by Patrik.

Thanks Antonio,

Patrick call only works in same server. I wanted to check both PR&St servers status from an third PC.

The PC would the engineering station with a Citect runtime license. Servers checks done with a dedicated program developed in C# with CtAPI helper library.

Then you may need to wrap the call in a MessageRPC() not sure if it works via CTAPI but I believe it could.

IODeviceInfo mode 17 works on the client

"Apart from when Type is set to 3 or 17, this function can only be used if the I/O Server is on the current machine"

Which also makes sense, as different clients could be connected to different servers, particularly in some sort of degraded mode of operation where clients are only able to connect to certain, different servers.

Type 17 will do the job for me. Already tested and works fine

Thanks for your Info

Type 17 will do the job for me. Already tested and works fine

Thanks for your Info