I understand the problem but I don't think that there is a good solution for it. Diafaan SMS Server uses database transactions to read, write and update multiple records in the SQL database in one process. Without transactions the database queries would be slow to keep up with the message throughput in Diafaan SMS Server. When a database transaction fails, Diafaan SMS Server has no way to determine the exact reason for the problem, the database driver returns an error code and error text but it does not specify which record or process is the underlying reason for the error.
Diafaan SMS Server can do two things when a database error happens. It can roll back the transaction and discard the whole batch of database updates (this is the default behavior). Or it can regard the database problem as temporary and try to write or update the messages later (this is the behavior when 'MessageLogRetryOnError' is set to true). At the moment the SQL Connector does not use an internal database to store unhandled database updates so when the SQL Connector is restarted when the SQL database is offline, the pending message updates are lost.
The best way to handle this problem is to determine what the underlying cause of the issue is. If it is an unreliable connection to the database then that should be addressed, for instance by using a local database program instead of a database on a remote server. If the problem is caused by an unreliable ODBC driver then an update of the driver could solve the problem. If the problem only occurs for specific messages then there could be a problem with the database design, for instance that a specific field is not long enough. You can look at the error messages in the event log or in the communication log of the SQL Connector to see the error codes and error messages that the database returns to determine the root cause of the error. Unfortunately, this is not always easy to find and solve.
Hope you are fine. We have come across this issue earlier and now also sometimes we face this issue. We have set MessageLogRetryOnError to True due to this if some records are not able to be written or updated to the MessageLog database it retry and then all the other messages after that are also stuck and not been logged into the database. Once the SQL Connector is restarted then only it starts logging again, during the restart all the records which are stuck are lost.
Request you to make a provision for the number of retries, say the MessageLogRetryOnError is true it will retry 3 times to insert or update the record in 5secs or 10secs if it cannot log then would drop that record and move to the next record so that there is no loss of more records if one is stuck. I hope I have made you understand what I am trying to say.
Thanks again for your wonderful support and co-operation every time we request you something.
Have a great day!!
Most Users Ever Online: 494
Currently Browsing this Page:
Guest Posters: 602
Newest Members:, Henk Helmantel
Administrators: Henk Helmantel: 1275