Janit

BTW DBAttach isn't the only method of transferring the passwords as there's also a script you can run but I've never used it.

For the passwords to be 'transported' to a new SQL Server, the database must be detached using the DBAttach utility from Capita. DBAttach transfers the passwords from the Master database into the SIMS database ready for transit. You will probably find that not all passwords are reset and it's only those that have been created since the last DBAttach which is probably when SIMS was migrated to SQL 2008.

If you chose to switch on the Redirect Service when SIMS was migrated to SQL 2008 it may be that causing the problem. To resolve this I would suggest stopping the SIMS2005 Instance and see if that helps.

Have you checked the errorlog for SQL to see exactly which port it's using?

@vikpaw - Personally, I would always use DBAttach in the process of transferring the sims database to a new instance but as people seem to be getting away with not using DBAttach, could it be because the user info was transferred to the db when the migration to sql2008 took place? If so, maybe people won't have a problem with this at the moment unless they've had any new sims users or reset passwords since the migration. Just a thought.

Could do with bit more info on what you can see in the Promotion Rules screen. If you select one of your rules, what comes up in the bottom left window?

Shouldn't need to add the column, it's there by default. Selecting it is probably just grouping the schemes by the promotable column. It sounds as though the rules haven't been created properly so I'd look back there to be honest. Confirm and Save etc.

In the browser for the schemes there should be the word 'promotable' for any schemes you've created rules for. Is that the case?

Have you set up the promotion rules via the Routines\School menu?

Ric, did you run dmconfig on the original server to make sure you'd copied the docstorage from the right place? I've seen multiple copies of docstorage before and the duff one's been copied by mistake.

I would guess that your Document Server isn't pointing to the correct location for Docstorage. Have you tried the following: Edited the computer name in Tools\Setups\Document management server? Ran DMConfig on the original machine to make sure you're copying the correct Docstorage folder to the new server? Modified Docstorage subfolder to match the new Server Name? Also, it may be too late for this but when moving SIMS I always advise NOT importing predefined reports otherwise it's more difficult to diagnose any potential problems.

You can install .net framework 1.1 from dotnetfx.exe in the ?:\sims\setups folder.

Is the internet connection ok? I'd run a speedtest to check it. We used to get errors like this until the schools had their switches upgraded. Apparently, their old gear was really quite poor and was running out of memory. Sad but true!

The end date for the current academic year is usually 'calculated' by SIMS itself e.g. so many days after the start date. It's not until you create the following year that the end date is established. We advise all our schools to start the year on 1st September which in turn terminates the previous year on 31st August. Our Childrens Services Dept have stipulated that all Cheshire schools should use these dates so that students have a continous school history record particularly when moving between Junior and secondary schools. Just to add... for new students we then assign a date of admission of 1st September. The first day or so is usually an Inset day but one year we had to get all schools to manually add a holiday through the school diary so that the pupils attendance records were ok.

Creese, from what I gather the damage is already done. I would've preferred the option of going with the upgrade 'as is' though as we could've warned users to make a backup of the quickletter before applying the upgrade. Not sure how many schools make use of the quickletter but pretty sure it's not the majority. We could've emailed everyone to ask if they wanted the newer version and released it on request. We support 300+ schools and approx 120 had already installed it. It's been automatically withdrawn so now we have the task of releasing the new version to all schools and then removing it from the ones who already have it. Nice.

I've never had to change that setting after a new install. Have only taken advantage of disabling it myself for upgrades.

I always start with connect.ini's when I get reason 0. The connect.ini on the workstation, particularly if it's been a sims workstation since the last migration, can sometimes contain too much bumph. It should ideally just have: [sIMSConnection] Redirect=s:\sims And then the central connect.ini in s:\sims should have the correct servername and database name in it. e.g. [sIMSConnection] ServerName=whatevercomputernameis\sims2008 If connect.ini's are correct and they contain the server name rather than IP address, check that you can ping the server by name from a workstation. Shouldn't really need to reinstall any SIMS client on the workstations or adjust the network config on a new sql install.