[sims] Defining Half Term Holidays Crashes Sims.NET

[tech_guy]

Our SIMS Manager has found that since the summer upgrade, whenever she tries to enter the dates for the recent holiday, Sims.NET crashes, throwing all the users out.

 

Has anyone else encountered this issue?

[Ashm]

What actually happens on the SIMS server? Does the sqlserver process hang maxing out the cpu?

 

We had a similar issue before, after running the generic SIMS re-indexing patch seemed to resolve the issue and when editing dates for the academic year afterwards it completed within a few minutes rather than hanging.

[tech_guy]

Just found this so time to give it a whirl:

 

http://support.capitaes.co.uk/websupport/RenderXSL.aspx?KB=KB118715.xmlFalse

[Steve21]

What actually happens on the SIMS server? Does the sqlserver process hang maxing out the cpu?

 

We had a similar issue before, after running the generic SIMS re-indexing patch seemed to resolve the issue and when editing dates for the academic year afterwards it completed within a few minutes rather than hanging.

 

Out of curiosity, where did you get that re-index patch from? One of the Capita support guys told us to run it before, and would email it to us, and months later no email Just wondered if it's downloadable without going through cases etc again.

 

Thanks,

Steve

[Ashm]

Out of curiosity, where did you get that re-index patch from? One of the Capita support guys told us to run it before, and would email it to us, and months later no email Just wondered if it's downloadable without going through cases etc again.

 

Thanks,

Steve

I don't think it's freely available they just emailed it to me when we had the above issue.

 

@tech_guy that's the same KB we followed but we only ended up needing to the "Apply Patch 14265 (Re-Indexes the SQL database)" step.

[jinnantonnixx]

Be careful with the re-index patch.

 

It does three things:

 

1. Changes your database recovery model to 'simple'. This will utterly ruin your backups if you use the 'full' recovery model with log files backups, or you use log shipping. Watch out for this one, it's caught me out. We were on brown alert until I figured out what was causing the database recovery model to change.
   
2. Re-index your databases. The main attraction (but why use a fill factor of 100?)
   
3. Shrinks the log file to the minimum size possible. If you size your log files properly this will mess up your plan as you'll almost certainly experience auto-grow.
   

 

It might not concern your set-up, but it's best to be aware of pitfalls.

Edited November 7, 2012 by jinnantonnixx

[skunk]

Thanks @jinnantonnixx, I tried to apply the re-index patch but it corrupted the DB due to someone logging into our terminal server in the seconds between the db being put into single user mode and DBupdate getting hold of it.

 

But would have not noticed it swapping to 'simple' mode and screwing up my backups. Will look out for this when I get the chance to run it again.

[jinnantonnixx]

That piece of code to shrink the log file (and setting the recovery to 'simple') has absolutely no place in a patch to reindex a database. They should take it out and publish the shrink patch as a separate patch.

 

I just extracted the T-SQL that reindexes the databases and run it from a scheduled SQL job. We shouldn't have to do this, but it's better than knackering up your backups.

 

Sigh.

Edited November 8, 2012 by jinnantonnixx

[jinnantonnixx]

I tried to apply the re-index patch but it corrupted the DB due to someone logging into our terminal server in the seconds between the db being put into single user mode and DBupdate getting hold of it.

 

If that happens again, you can put the database back to multi-user mode with this code. Run the code from a query window (after the rogue user has left the system, of course)

 

alter database [your_sims_database_name] set multi_user with no_wait

Edited November 8, 2012 by jinnantonnixx
wrong text quoted