I'm getting this in the log as well
[21:14:31] Engine - Set Allowed Differences - Starting...
[21:14:31] Engine - State Change - Need: 'WaitingForComparisonsResolution', Current: 'SchemaSyncInProgress', New: 'AllowedDifferencesResolutionInProgress'.
[21:14:31] Engine - State Change - State is incorrect, aborting!
it doesn't seem to have done anything at all as I can still log and progress an incident with no problems
I've seen such an error once before. When I got this error message it was related to a security permissions.
Are you able to try the sync with the SQL sa User and see what happens?
Even if everything is working fine, I would recommend to restore the database to the default before the first sync.
Just for the record you MUST ALWAYS restore the database to the backed up copy if you receive an error message.
The documentation isn't clear that YOU MUST RESTORE YOUR DATABASE IF YOU RECEIVE AN ERROR when running TTL but when i told support that i hadn't restored the database as all was working fine, there was a lot of pressure to restore immediately, regardless that I would lose all the data entered that morning.
Thanks for the suggestion Fabien. The sa login has generated the same error though
On looking through this there is an extra line of data in a category table (usr_location) I have SQL inserted the row so that the tables now match (even the guid) but i'm still getting the same error. Not sure if this was a good idea or not though
It looks like there each view (the last item in the log file) that it stops on is the item that has the problem. It seems like each of the views that uses the usr_organisation field is having a problem.
When i try to select the view in MS SQL Server Management Studio i get a binding error for some reason:
Msg 207, Level 16, State 1, Procedure vw_PL_Open_Incidents, Line 4
Invalid column name 'usr_organisation'.
Msg 4413, Level 16, State 1, Line 14
Could not use view or function 'TestEnv.dbo.ViewName' because of binding errors.
Troubleshoooting goes on!
Didn't really troubleshoot that but i dropped the views and carried on. There were a few more views that referenced this field that the upgrade found and i dropped them all. Got a new error now as the server that was running the Test to Live process seemed to lose a massive amouint of disk space. Not sure if that was the cause or the symptom though
[16:53:09] RedGate - Comparing [dbo].[tps_attachment_data]
[17:42:58] Engine - State Change - Need: 'DataSyncInProgress', Current: 'DataSyncComparisonInProgress', New: 'EngineFailed'.
[17:42:58] Engine - State Change - State is incorrect, aborting!
I'll restart and keep an eye on the disk space
funny monolog for you here
Currently we are also running from one error to the next one in a customer database.
For me the TTL Module works fine, if you implement it from an OOTB Database, but not in an established Service Desk environment... There are to much scenarios, that must not happen, so it is very difficult to get TTL running in a stable state.
The only thing that satisfies me a little bit, that we are not the only one with a lot of trouble with TTL.
But to your problem:
Is the disk space limited on your databse servers, so there is not enough space for a total copy of the test database?
It does look like a fair amount of disk space is used up during the running of TTL. I've just seen about 1 1/2 gig of disk space disappear in about 10 minutes! Although where it's gone is slightly more vague as none of the files that have been modified during that time amount to that amount of disk space loss
Thanks for your reply Fabian
I was just hoping that my experience may benefit others as well as being theraputic for me!
I'm running the TTL software on my App server (seemed reasonable at the time but maybe it would be much faster on the SQL box) and the disk space isn't large enough to accomodate the whole database either (by a long shot!)
I've found the config file but it doesn't look like there's a way to change the temp folder so it fills up another less essential drive!
I've spoken to support on this and done some testing. It looks like it uses the logged on user's profile temporary directory as when i moved the windows temp and tmp folders it still filled up the C: drive. Probably good practice to move them anyway.
The advice was that it coould take from 2 to 4 times the size of the database in temporary storage. I've got an 80 Gig database and it took about 25 gig of my disk space temporarily.
Looks like it's worked ok. Just a bit of testing to do now