This is not reproducable here with SQL Server 2005

Can you please put
$debug=1;
in your config.php

and clear your database, retry installation and see what error you get then when you try to create a survey. Check for any errors.

I'm afraid this hasn't resolved it. Installation went fine. No errors. I've created the database already, setup a SQL user that has DBO Access and the programmed this information in to the config.php file. I have then dropped all the tables from the database, entered the debug line in to the code, saved the config.php file and then access the admin installation. Created the database tables correctly, removed the installation folder (can't login to admin interface without this removal) then tried logging in with the username and password setup in the config.php file, tried to create a survey and get the same error again.

Sorry, but could you try using SQL Server 2000 with your install to see if you get an issue. Thats the only difference I think we're having here.

Thanks :)

I am sorry but I don't have MS SQL Server 2000 handy right now. It may take some time until I get access to one. MSSQL 2000 is on the other hand 9 years old - maybe it is time to update.

I tested on MSSQL Server 2000 now - works fine here.
I guess it is something with your server or configuration. Can you attach your config.php please?

I don't see how showing the config.php file will make a difference as the ssytem is already creating the databases on the server using the username and password I have programmed and alsio allowing me to add users and other bits and pieces to the system.

Here is a copy of the file for your review, but I'm don't think it will help.

Thanks

$databasetype = 'odbc_mssql'; // ADOdb database driver - valid values are mysql, odbc_mssql or postgres
$databaselocation = 'SERVER_NAME_HERE'; // Network location of your Database - for odbc_mssql use the mssql servername, not localhost or IP
$databasename = 'LIMESURVEYS'; // The name of the database that we will create
$databaseuser = 'USERNAME_HERE'; // The name of a user with rights to create db (or if db already exists, then rights within that db)
$databasepass = 'PASSWORDHERE'; // Password of db user
$dbprefix = 'lime'; // A global prefix that can be added to all LimeSurvey tables. Use this if you are sharing
// a database with other applications. Suggested prefix is 'lime_'

// Debug Option
$debug = '1';

// File Locations
$rooturl = "http://{$_SERVER['HTTP_HOST']}/limesurvey"; //The root web url for your limesurvey installation (without a trailing slash). The double quotes (") are important.

$rootdir = dirname(FILE); // This is the physical disk location for your limesurvey installation. Normally you don't have to touch this setting.
// If you use IIS then you MUST enter the complete rootdir e.g. : $rootDir='C:\Inetpub\wwwroot\limesurvey'!
// Some IIS installations also require to use forward slashes instead of backslashes, e.g. $rootDir='C:/Inetpub/wwwroot/limesurvey'!
// If you use OS/2 this must be the complete rootdir with FORWARD slashes e.g.: $rootDir='c:/limesurvey';!
// Site Setup
$sitename = 'GeneralSurvey'; // The official name of the site (appears in the Window title)

$defaultuser = 'admin'; // This is the default username when LimeSurvey is installed
$defaultpass = 'password'; // This is the default password for the default user when LimeSurvey is installed

// Email Settings

$siteadminemail = 'test@test.com'; // The default email address of the site administrator
$siteadminbounce = 'admin@test.com'; // The default email address used for error notification of sent messages for the site administrator (Return-Path)
$siteadminname = 'AdminName'; // The name of the site administrator

Well, your config looks okay.
Since I cannot reproduce it I cannot fix it. Since you are the only person reproting this issue so far it is likely that there is something special with your system. Unless I get direct access to your system there is no way to fix this. Do you think this is possible? If not we will have to close this bug.

Well do you think it could be an incorrectly configured php.ini maybe?

Other than this, I cannot see why there would be any problems other than it being maybe an IIS6 issue, but thats unlikely.

At the stage I've mentioned above, is there any writing back to the files on the server by any chance, as I don't think IIS is permitted to write back to the files on the server.

Thanks

No writing occurs at that point and I would not know what settings in php.ini could cause this. Sorry.
Please re-open only if you can provide access to such a system or have other new intelligence. Thank you.