The inability to open the error log could indicate corruption in the internal database. The good news is that in the instances we’ve seen the database get corrupted, the corruption has been isolated to the error log portion, and it’s usually fairly easy to recover.
In the FactorySQL install directory, look for “system_database.fdb”. How big is that file? If it’s over 1-5MB, it’s likely that the error log has been corrupted.
Corruption in the error log could possibly affect the rest of the system, depending on a few different things. If errors are occurring, they wouldn’t get written. The rest of the system might slow down quite a bit.
If you’re getting the success handshake, however, it indicates that the system is receiving successful responses from RSLinx. The question is, are the responses erroneous, or is FactorySQL not attempting to write all of the data.
I would recommend the following course of action:
- We need to resolve the error log issue. I can advise you over the forum, or if it’s possible for you to call into support, we can help you over GoToMeeting.
- We should have you install the OPC Analyzer tool and set up a test case for this group that goes through it. In this way, we can see exactly what FactorySQL is trying to write, and what RSLinx is responding with.
- We should also try the test with synchronous writes, instead of asynchronous. This is a setting under Service Settings in FactorySQL.
The analyzer can be downloaded directly from this link. It’s really very simple to use: start it, and point it to RSLinx. In FactorySQL, you’ll see it show up as another OPC server. Copy your group, and use Search & Replace (from the group’s right-click menu) to change the server name. Then, everything that happens through the group will be traced in the analyzer, and you can export it for us. Of course, we can help with all of this, if you’re able to call in.
Regards,