• State Not Answered
  • Replies 5 replies
  • Subscribers 582 subscribers
  • Views 155 views
  • Users 0 members are here
Options
Related

DBF file handling Question - data flow Clients - Servers to a corporate file server with Plant Scada 2023R2 Update 9

Alan

Version = Plant Scada 2023R2 Update 9

my project has a database i am finding has become "intermittently" unstable possibly after recent upgrade from Citect SCADA 2018 to 2023R2 or some security updates pushed out by IT Dept or Microsoft.

what i am noticing is slow performance in read/writes to this database file. Note the code is 7 + years and has not been modified so has proven very reliable to now.

i am trying to understand the data flow and where the issue is. 

when operators make a change to the process, a cicode file writes this change or reads from the  *.dbf file that resides on the "Corporate file Server" in a folder.

the folder and file is mapped as a network drive on the SCADA server. in devices "file name" field  \\Servername\database_folder\MyDB.dbf (example only) is the path to the location on the corporate File server

for the above configuration i would like some explanation of the data flow for this.

QUESTION when an operator makes the change from either SCADA Client A, B or C is the data written to the corporate server directly or via the SCADA server?

  • SCADA Client > Corporate Server

                                    OR

  • SCADA Client > SCADA Server > Corporate Server

 i am unsure of what the corrective action was as i tried many things (restart SCADA, reboot all SCADA machines, recompile, pack etc) one or more of these rectified the issue.

Parents
  • 0

    It is not good to have multiple processes (clients) reading or writing the same dbf file at the same time. I tested this many years ago and found that most of the time it works fine,  but occasionally one client will fail to write. Very rarely, one client can get locked out and can no longer access the file. Reading can also be a problem, but writing is the main problem.

    You can write code for the clients to command the server to do the writes. Or the clients could write to a local file and the server could copy the data to the corporate file.  Or you could use SQL Server which is designed for multiple clients. Or you could use some sort of handshake so only one client accesses the file at a time. 

Reply
  • 0

    It is not good to have multiple processes (clients) reading or writing the same dbf file at the same time. I tested this many years ago and found that most of the time it works fine,  but occasionally one client will fail to write. Very rarely, one client can get locked out and can no longer access the file. Reading can also be a problem, but writing is the main problem.

    You can write code for the clients to command the server to do the writes. Or the clients could write to a local file and the server could copy the data to the corporate file.  Or you could use SQL Server which is designed for multiple clients. Or you could use some sort of handshake so only one client accesses the file at a time. 

Children
No Data
© 2025 AVEVA Group Limited or its subsidiaries. All Rights Reserved.