Both an archive shift and a 'dump' of backfill events can cause this error. Could you please attach the PI message logs to see more details?
This is a techsupport question. I suggest that you could phone OSIsoft techsupport team, as they are the PI error solution experts. And I believe, they need the PI message logs to do some analysis.
As Xi suggested, OSIsoft techsupport is best equiped to handle this.
From my experience: when I got this error message, one of my PI subsystems was not running. Please make sure that all the subsystems are running on the server.
Thank you for your prompt replies, I really appreciate it.
However, I did not talk to the techsupport because to my surprise what I found was, using the PI SDK Utility application on actual machine where my client app is to be run, I am able to connect, even browse tags and see their snapshot data, so this kept me wondering what the problem could be. Finally, it drilled down to the following:
I developed my PI client app using the PI SDK dlls from my local machine's PI SDK and Demo Server installation which happens to be of version 188.8.131.528 and for x86 system and the actual machine where I am using my client app is of a x64 system and the PI SDK installed on it is of version 1.4.0.
So when I used the DLLs from the PublicAssembly directory of actual PI SDK Installation, everything just worked fine.
Just one more question. With 1.3.8 we can connect to servers even if installed 1.4.0, right ? If yes, then this was just a problem of x86 and x64 systems, wasn't it?
Thank you agian.
@Vikrant: Thanks, this is appreciated that you shared your findings with the community.
To respond to your question, you can connect to a recent PI Server with an older PI SDK version such as version 184.108.40.2068 The PI Server does not use the PI SDK to "serve" the clients such as PI SMT or PI ProcessBook; requests are handled through RPCs.
An application compiled with x86 will look for x86 or Any compiled .NET references on a computer and start the process as 32-bit. Any CPU means that when the program is started, the .NET Framework will figure out, based on the OS bitness, whether to run your program in 32 bits or 64 bits.
Interestingly, I just had this exact problem. It turns out I had transposed the location 3 and location 5 settings on some new Modbus points. When I rebuilt these points properly and deleted the old ones, things were fine. As usual (for me), dumb configuration errors seem to be my only way to break PI.