Create all necessary logins that are in your original database in new server, restored the database and run stored procedure "sp_change_users_login" to map the users in restored database to the logins...

I seen someome reported similar problem in this forum but can't remember how do they resolved it.

What is your SQL Server authentication mode?

If you have SMS server, try to create it into a SMS package and push it to all your machines.

Has the app's admin account been granted to access SQL Server?

Did non-admin accounts work with TCP/IP? Same question too, are they granted to access SQL Server?

You should be fine by removing the 7.0 version from control panel but it is always to be good if you could test it.

Try to use UNC path.

EXECUTE sp_makewebtask @outputfile = N'W:\sites\ww\default2.asp', @query=N'EXECUTE [WWWServices2]', @templatefile=N'\\yourservername\sharename\sites\ww\default.tpl', @dbname=N'WWWServices', @whentype=9,@procname=N'web_task_WWWServices2',@codepage=65001,@charset=N'utf-8'

What error messages did you get?

Default collation is case-insensitive.

Detach it, rename the file name and re-attach.

You can change the logical file name too with "alter database modify file" command.

You can't declare int type since it is Integer (whole number), Use declare @var decimal (7,4). 

In addition, using more processors means managing more threads and requires more cache synchronization and SQL Server has more coordination to perform since it needs to slice and regroup...

Try right join

We have seen turning the parallel on to certain degree has created heavy I/O into disk subsystem which becomes bottleneck for the performance.

You need try to find out what...

Or try dynamic query.

declare @cmd varchar(1024)

declare @orderby varchar(10)

select @cmd = "select * from authors order by " + @orderby

exec (@cmd)