I know of a certain large water customer that uses all eight (all four low and four high). Why though is a question I can't answer. ... View more

You might be thinking about the ViewX system name and spaces. Spaces are allowed but having a space in them gives you a warning as it can break scripting.   It doesn't block you creating it though, as not allowing it on systems that had a space in the system name for years breaks even more. ... View more

Yes, that will create duplicate values with the same timestamp, even if the value changes. The method call is deliberately dumb as its about efficiency and you use those method calls to import many hundred of gigabytes of data.   A few ways I can think of:   1. If you know all the data that should be in that historic for the point (either by pre-reading it from CDBHistoric or your original data source has it) the easiest way my be to disable historic and then re-enable historic on that point and the historic will be blank giving you a clean slate. But this is a bit like a sledgehammer to a nut and with hot-standby, low bandwidth links and more complex architectures does have some possible crazy knock-on effects. If in an instance need to ensure property overrides are set. You're also not able to write into the read-only/archive period but that's the same for the next one too anyway.   2. Be surgical and read the existing data, and where existing data matches the timestamp for your new data use the delete method (new since 2017R3 I think?) to remove the old data first so when you import there will be only the values you want in its place. I'd go for this one personally but each to their own.   Both have timing issues and the need to backup things in case of failure. Test though!   Probably can't use modify value, as I think that causes a second entry to be there. Also you can't do the historic optimising methods as their values differ they aren't actually duplicates so they won't be cleaned up. ... View more

I think Jesse answered your questions, but if you have any other suggestions to that page let me know as I'm happy to update it to make things better/clearer/more helpful.   Once OPC-UA is available, both server and client, then that can/will also be added although how it compares on some of those categories I've no idea... yet. Time will tell. ... View more

Just to add, https://tprojects.schneider-electric.com/telemetry/display/CS/Comparison+of+Methods+to+Transfer+Point+Data+Between+ClearSCADA+Systems might be a useful read too (although does duplicate some of what Bevan has written above). ... View more

Usually the timestamp popular for printing mimics so someone knows the time of the data at a later moment, but anything sub second is pointless.   It's worse on WebX the update rate of 5 seconds, and any ViewX or WebX clients connected to a standby can be a few seconds more between updates than clients connected to the main due to the synchronisation.     ... View more

Logic is too disjoint from the database for that, property writes and %D SQL execution happens long after the logic has finished executing. During the execution they are just put onto a stack.   The logic process is documented at https://tprojects.schneider-electric.com/telemetry/display/CS/Logic+Execution   I figured you might not like the SYSTEM() option, I wasn't too keen on that idea myself but how good it might work is very customer specific 🙂 ... View more