Having trouble installing SQl Server 2005

I am having trouble installing SQL Server 2005 on a new machine at a hosted company. I am only installing the minimum, SQL Databaes Services. It errors out at the end and says see log. I have installed SQl 2005 10 times with no problem at other locations. The service won't even start it says error 3 path unkown. If I look for the path it shows in the service it hasn't been created, the files and directories were not created at that directory location. I tried to install bot as a Domain Admin and Local Admin accounts.

Here THe summary Log., Core(local) and Core Log files below.

Microsoft SQL Server 2005 9.00.1399.06
==============================
OS Version : Microsoft Windows Server 2003 family, Standard Edition Service Pack 1 (Build 3790)
Time : Tue Mar 20 02:48:40 2007
Machine : CATCSAP021211
Product : Microsoft SQL Server Setup Support Files (English)
Product Version : 9.00.1399.06
Install : Successful
Log File : C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup0016_CATCSAP021211_SQLSupport_1.log
--
Machine : CATCSAP021211
Product : Microsoft SQL Server Native Client
Product Version : 9.00.1399.06
Install : Successful
Log File : C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup0016_CATCSAP021211_SQLNCLI_1.log
--
Machine : CATCSAP021211
Product : Microsoft Office 2003 Web Components
Product Version : 11.0.6558.0
Install : Successful
Log File : C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup0016_CATCSAP021211_OWC11_1.log
--
Machine : CATCSAP021211
Product : Microsoft SQL Server VSS Writer
Product Version : 9.00.1399.06
Install : Successful
Log File : C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup0016_CATCSAP021211_SqlWriter_1.log
--
Machine : CATCSAP021211
Product : Microsoft SQL Server 2005 Backward compatibility
Product Version : 8.05.1054
Install : Successful
Log File : C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup0016_CATCSAP021211_BackwardsCompat_1.log
--

SQL Server Setup failed. For more information, review the Setup log file in %ProgramFiles%\Microsoft SQL Server\90\Setup Bootstrap\LOG\Summary.txt.

Time : Tue Mar 20 02:50:13 2007

List of log files:
C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup0016_CATCSAP021211_Core(Local).log
C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup0016_CATCSAP021211_SQLSupport_1.log
C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup0016_CATCSAP021211_SQLNCLI_1.log
C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup0016_CATCSAP021211_OWC11_1.log
C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup0016_CATCSAP021211_SqlWriter_1.log
C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup0016_CATCSAP021211_BackwardsCompat_1.log
C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup0016_CATCSAP021211_MSXML6_1.log
C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup0016_CATCSAP021211_Datastore.xml
C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup0016_CATCSAP021211_.NET Framework 2.0.log
C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup0016_CATCSAP021211_Core.log
C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Summary.txt
C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup0016_CATCSAP021211_.NET Framework 2.0 LangPack.log
C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup0016_CATCSAP021211_.NET Framework Upgrade Advisor.log
C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup0016_CATCSAP021211_.NET Framework Upgrade Advisor LangPack.log
C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup0016_CATCSAP021211_.NET Framework Windows Installer.log
C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup0016_CATCSAP021211_.NET Framework Windows Installer LangPack.log
C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup0016_CATCSAP021211_Support.log
C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup0016_CATCSAP021211_SCC.log
C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup0016_CATCSAP021211_WI.log

Core(local)

Microsoft SQL Server 2005 Setup beginning at Mon Mar 19 19:49:04 2007
Process ID : 1300
C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\setup.exe Version: 2005.90.1399.0
Running: LoadResourcesAction at: 2007/2/19 19:49:4
Complete: LoadResourcesAction at: 2007/2/19 19:49:4, returned true
Running: ParseBootstrapOptionsAction at: 2007/2/19 19:49:4
Loaded DLL:C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\xmlrw.dll Version:2.0.3604.0
Complete: ParseBootstrapOptionsAction at: 2007/2/19 19:49:4, returned true
Running: ValidateWinNTAction at: 2007/2/19 19:49:4
Complete: ValidateWinNTAction at: 2007/2/19 19:49:4, returned true
Running: ValidateMinOSAction at: 2007/2/19 19:49:4
Complete: ValidateMinOSAction at: 2007/2/19 19:49:4, returned true
Running: PerformSCCAction at: 2007/2/19 19:49:4
Complete: PerformSCCAction at: 2007/2/19 19:49:4, returned true
Running: ActivateLoggingAction at: 2007/2/19 19:49:4
Complete: ActivateLoggingAction at: 2007/2/19 19:49:4, returned true
Running: DetectPatchedBootstrapAction at: 2007/2/19 19:49:4
Complete: DetectPatchedBootstrapAction at: 2007/2/19 19:49:4, returned true
Action "LaunchPatchedBootstrapAction" will be skipped due to the following restrictions:
Condition "EventCondition: __STP_LaunchPatchedBootstrap__1300" returned false.
Action "BeginBootstrapLogicStage" will be skipped due to the following restrictions:
Condition "Setup is running locally." returned true.
Running: PerformDotNetCheck2 at: 2007/2/19 19:49:4
Complete: PerformDotNetCheck2 at: 2007/2/19 19:49:4, returned true
Running: InvokeSqlSetupDllAction at: 2007/2/19 19:49:4
Loaded DLL:C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\sqlspars.dll Version:2005.90.1399.0
<Func Name='DwLaunchMsiExec'>
Examining 'sqlspars' globals to initialize 'SetupStateScope'
Opening 'MachineConfigScope' for [CATCSAP021211]
Trying to find Product Code from command line or passed transform
If possible, determine install id and type
Trying to find Instance Name from command line.
No Instance Name provided on the command line
If possible, determine action
Machine = CATCSAP021211, Article = WMIServiceWin32OSWorking, Result = 0 (0x0)
Machine = CATCSAP021211, Article = WMIServiceWin32CompSystemWorking, Result = 0 (0x0)
Machine = CATCSAP021211, Article = WMIServiceWin32ProcessorWorking, Result = 0 (0x0)
Machine = CATCSAP021211, Article = WMIServiceReadRegWorking, Result = 0 (0x0)
Machine = CATCSAP021211, Article = WMIServiceWin32DirectoryWorking, Result = 0 (0x0)
Machine = CATCSAP021211, Article = WMIServiceCIMDataWorking, Result = 0 (0x0)
Machine = CATCSAP021211, Article = XMLDomDocument, Result = 0 (0x0)
Machine = CATCSAP021211, Article = Processor, Result = 0 (0x0)
Machine = CATCSAP021211, Article = PhysicalMemory, Result = 0 (0x0)
Machine = CATCSAP021211, Article = DiskFreeSpace, Result = 0 (0x0)
Machine = CATCSAP021211, Article = OSVersion, Result = 0 (0x0)
Machine = CATCSAP021211, Article = OSServicePack, Result = 0 (0x0)
Machine = CATCSAP021211, Article = OSType, Result = 0 (0x0)
Machine = CATCSAP021211, Article = iisDep, Result = 0 (0x0)
Machine = CATCSAP021211, Article = AdminShare, Result = 0 (0x0)
Machine = CATCSAP021211, Article = PendingReboot, Result = 0 (0x0)
Machine = CATCSAP021211, Article = PerfMon, Result = 0 (0x0)
Machine = CATCSAP021211, Article = IEVersion, Result = 0 (0x0)
Machine = CATCSAP021211, Article = DriveWriteAccess, Result = 0 (0x0)
Machine = CATCSAP021211, Article = COMPlus, Result = 0 (0x0)
Machine = CATCSAP021211, Article = ASPNETVersionRegistration, Result = 0 (0x0)
Machine = CATCSAP021211, Article = MDAC25Version, Result = 0 (0x0)
*******************************************
Setup Consistency Check Report for Machine: CATCSAP021211
*******************************************
Article: WMI Service Requirement, Result: CheckPassed
Article: MSXML Requirement, Result: CheckPassed
Article: Operating System Minimum Level Requirement, Result: CheckPassed
Article: Operating System Service Pack Level Requirement, Result: CheckPassed
Article: SQL Compatibility With Operating System, Result: CheckPassed
Article: Minimum Hardware Requirement, Result: CheckPassed
Article: IIS Feature Requirement, Result: CheckPassed
Article: Pending Reboot Requirement, Result: CheckPassed
Article: Performance Monitor Counter Requirement, Result: CheckPassed
Article: Default Installation Path Permission Requirement, Result: CheckPassed
Article: Internet Explorer Requirement, Result: CheckPassed
Article: Check COM+ Catalogue, Result: CheckPassed
Article: ASP.Net Registration Requirement, Result: CheckPassed
Article: Minimum MDAC Version Requirement, Result: CheckPassed
<Func Name='PerformDetections'>
0
<EndFunc Name='PerformDetections' Return='0' GetLastError='0'>
<Func Name='DisplaySCCWizard'>
CSetupBootstrapWizard returned 1
<EndFunc Name='DisplaySCCWizard' Return='0' GetLastError='183'>
Loaded DLL:C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\sqlsval.dll Version:2005.90.1399.0
<EndFunc Name='DwLaunchMsiExec' Return='0' GetLastError='0'>
Complete: InvokeSqlSetupDllAction at: 2007/2/19 19:51:1, returned true
Running: SetPackageInstallStateAction at: 2007/2/19 19:51:1
Complete: SetPackageInstallStateAction at: 2007/2/19 19:51:1, returned true
Running: DeterminePackageTransformsAction at: 2007/2/19 19:51:1
Complete: DeterminePackageTransformsAction at: 2007/2/19 19:51:3, returned true
Running: ValidateSetupPropertiesAction at: 2007/2/19 19:51:3
Complete: ValidateSetupPropertiesAction at: 2007/2/19 19:51:3, returned true
Running: OpenPipeAction at: 2007/2/19 19:51:3
Complete: OpenPipeAction at: 2007/2/19 19:51:3, returned false
Error: Action "OpenPipeAction" failed during execution.
Running: CreatePipeAction at: 2007/2/19 19:51:3
Complete: CreatePipeAction at: 2007/2/19 19:51:3, returned false
Error: Action "CreatePipeAction" failed during execution.
Action "RunRemoteSetupAction" will be skipped due to the following restrictions:
Condition "Action: CreatePipeAction has finished and passed." returned false.
Running: PopulateMutatorDbAction at: 2007/2/19 19:51:3
Complete: PopulateMutatorDbAction at: 2007/2/19 19:51:3, returned true
Running: GenerateRequestsAction at: 2007/2/19 19:51:3
SQL_Engine = 3
SQL_Data_Files = 3
SQL_Replication = 3
SQL_FullText = 3
SQL_SharedTools = 3
SQL_BC_DEP = 3
Analysis_Server = -1
AnalysisDataFiles = -1
AnalysisSharedTools = -1
RS_Server = -1
RS_Web_Interface = -1
RS_SharedTools = -1
Notification_Services = -1
NS_Engine = -1
NS_Client = -1
SQL_DTS = -1
Client_Components = 3
Connectivity = 3
SQL_Tools90 = 3
SQL_WarehouseDevWorkbench = 3
SDK = 3
SQLXML = 3
Tools_Legacy = 3
TOOLS_BC_DEP = 3
SQL_Documentation = 3
SQL_BooksOnline = 3
SQL_DatabaseSamples = -1
SQL_AdventureWorksSamples = -1
SQL_AdventureWorksDWSamples = -1
SQL_AdventureWorksASSamples = -1
SQL_Samples = -1
Complete: GenerateRequestsAction at: 2007/2/19 19:51:4, returned true
Running: CreateProgressWindowAction at: 2007/2/19 19:51:4
Complete: CreateProgressWindowAction at: 2007/2/19 19:51:4, returned true
Running: ScheduleActionAction at: 2007/2/19 19:51:4
Complete: ScheduleActionAction at: 2007/2/19 19:51:4, returned true
Skipped: InstallASAction.11
Skipped: Action "InstallASAction.11" was not run. Information reported during analysis:
No install request found for package: "sqlsupport", referred by package: "as", install will be skipped as a result.
Skipped: InstallASAction.18
Skipped: Action "InstallASAction.18" was not run. Information reported during analysis:
No install request found for package: "owc11", referred by package: "as", install will be skipped as a result.
Skipped: InstallASAction.22
Skipped: Action "InstallASAction.22" was not run. Information reported during analysis:
No install request found for package: "bcRedist", referred by package: "as", install will be skipped as a result.
Skipped: InstallASAction.9
Skipped: Action "InstallASAction.9" was not run. Information reported during analysis:
No install request found for package: "msxml6", referred by package: "as", install will be skipped as a result.
Skipped: InstallDTSAction
Skipped: Action "InstallDTSAction" was not run. Information reported during analysis:
No install request found for package: "dts", install will be skipped as a result.
Skipped: InstallDTSAction.11
Skipped: Action "InstallDTSAction.11" was not run. Information reported during analysis:
No install request found for package: "sqlsupport", referred by package: "dts", install will be skipped as a result.
Skipped: InstallDTSAction.12
Skipped: Action "InstallDTSAction.12" was not run. Information reported during analysis:
No install request found for package: "sqlncli", referred by package: "dts", install will be skipped as a result.
Skipped: InstallDTSAction.18
Skipped: Action "InstallDTSAction.18" was not run. Information reported during analysis:
No install request found for package: "owc11", referred by package: "dts", install will be skipped as a result.
Skipped: InstallDTSAction.22
Skipped: Action "InstallDTSAction.22" was not run. Information reported during analysis:
No install request found for package: "bcRedist", referred by package: "dts", install will be skipped as a result.
Skipped: InstallDTSAction.9
Skipped: Action "InstallDTSAction.9" was not run. Information reported during analysis:
No install request found for package: "msxml6", referred by package: "dts", install will be skipped as a result.
Skipped: InstallNSAction
Skipped: Action "InstallNSAction" was not run. Information reported during analysis:
No install request found for package: "ns", install will be skipped as a result.
Skipped: InstallNSAction.11
Skipped: Action "InstallNSAction.11" was not run. Information reported during analysis:
No install request found for package: "sqlsupport", referred by package: "ns", install will be skipped as a result.
Skipped: InstallNSAction.12
Skipped: Action "InstallNSAction.12" was not run. Information reported during analysis:
No install request found for package: "sqlncli", referred by package: "ns", install will be skipped as a result.
Skipped: InstallNSAction.18
Skipped: Action "InstallNSAction.18" was not run. Information reported during analysis:
No install request found for package: "owc11", referred by package: "ns", install will be skipped as a result.
Skipped: InstallNSAction.22
Skipped: Action "InstallNSAction.22" was not run. Information reported during analysis:
No install request found for package: "bcRedist", referred by package: "ns", install will be skipped as a result.
Skipped: InstallNSAction.9
Skipped: Action "InstallNSAction.9" was not run. Information reported during analysis:
No install request found for package: "msxml6", referred by package: "ns", install will be skipped as a result.
Skipped: InstallRSAction.11
Skipped: Action "InstallRSAction.11" was not run. Information reported during analysis:
No install request found for package: "sqlsupport", referred by package: "rs", install will be skipped as a result.
Skipped: InstallRSAction.18
Skipped: Action "InstallRSAction.18" was not run. Information reported during analysis:
No install request found for package: "owc11", referred by package: "rs", install will be skipped as a result.
Skipped: InstallRSAction.22
Skipped: Action "InstallRSAction.22" was not run. Information reported during analysis:
No install request found for package: "bcRedist", referred by package: "rs", install will be skipped as a result.
Running: InstallSqlAction.11 at: 2007/2/19 19:51:4
Installing: sqlsupport on target: CATCSAP021211
Complete: InstallSqlAction.11 at: 2007/2/19 19:51:5, returned true
Running: InstallSqlAction.12 at: 2007/2/19 19:51:5
Installing: sqlncli on target: CATCSAP021211
Complete: InstallSqlAction.12 at: 2007/2/19 19:51:6, returned true
Running: InstallSqlAction.18 at: 2007/2/19 19:51:6
Installing: owc11 on target: CATCSAP021211
Complete: InstallSqlAction.18 at: 2007/2/19 19:51:13, returned true
Running: InstallSqlAction.21 at: 2007/2/19 19:51:13
Installing: sqlwriter on target: CATCSAP021211
Complete: InstallSqlAction.21 at: 2007/2/19 19:51:18, returned true
Running: InstallSqlAction.22 at: 2007/2/19 19:51:18
Installing: bcRedist on target: CATCSAP021211
Complete: InstallSqlAction.22 at: 2007/2/19 19:51:28, returned true
Running: InstallSqlAction.9 at: 2007/2/19 19:51:28
Installing: msxml6 on target: CATCSAP021211
Error: MsiOpenDatabase failed with 110
Failed to install package
The installation source for this product is not available. Verify that the source exists and that you can access it.
Error: MsiOpenDatabase failed with 110 for MSI {5A710547-B58E-488B-828D-CA9A25A0533C}
Setting package return code to: 1612
Complete: InstallSqlAction.9 at: 2007/2/19 19:51:28, returned false
Error: Action "InstallSqlAction.9" failed during execution. Error information reported during run:
Target collection includes the local machine.
Invoking installPackage() on local machine.
Running: InstallToolsAction.11 at: 2007/2/19 19:51:28
Installing: sqlsupport on target: CATCSAP021211
Complete: InstallToolsAction.11 at: 2007/2/19 19:51:33, returned true
Running: InstallToolsAction.12 at: 2007/2/19 19:51:33
Installing: sqlncli on target: CATCSAP021211
Complete: InstallToolsAction.12 at: 2007/2/19 19:51:34, returned true
Running: InstallToolsAction.13 at: 2007/2/19 19:51:34
Installing: PPESku on target: CATCSAP021211
Complete: InstallToolsAction.13 at: 2007/2/19 19:53:48, returned true
Running: InstallToolsAction.18 at: 2007/2/19 19:53:48
Installing: owc11 on target: CATCSAP021211
Complete: InstallToolsAction.18 at: 2007/2/19 19:53:51, returned true
Running: InstallToolsAction.20 at: 2007/2/19 19:53:51
Installing: BOL on target: CATCSAP021211
Complete: InstallToolsAction.20 at: 2007/2/19 19:55:37, returned true
Running: InstallToolsAction.22 at: 2007/2/19 19:55:37
Installing: bcRedist on target: CATCSAP021211
Complete: InstallToolsAction.22 at: 2007/2/19 19:55:40, returned true
Error: Action "InstallToolsAction.9" failed during execution. Error information reported during run:
Action: "InstallToolsAction.9" will be marked as failed due to the following condition:
Condition "Package "9" either passed when it was last installed, or it has not been executed yet" returned false. Condition context:
Prereq package will be failed due to the previous installation attempt returning: 1612
Installation of package: "msxml6" failed due to a precondition.
Action "InstallSqlAction" will return false due to the following preconditions:
Condition "Action: InstallSqlAction.9 has finished and failed." returned true.
Installation of package: "sql" failed due to a precondition.
Step "InstallSqlAction" was not able to run.
Skipped: InstallNSAction.10
Skipped: Action "InstallNSAction.10" was not run. Information reported during analysis:
No install request found for package: "sqlxml4", referred by package: "ns", install will be skipped as a result.
Running: InstallToolsAction.10 at: 2007/2/19 19:55:40
Installing: sqlxml4 on target: CATCSAP021211
Complete: InstallToolsAction.10 at: 2007/2/19 19:55:44, returned true
Skipped: RepairForBackwardsCompatRedistAction
Skipped: Action "RepairForBackwardsCompatRedistAction" was not run. Information reported during analysis:
Action: "RepairForBackwardsCompatRedistAction" will be skipped due to the following condition:
Condition "sql was successfully upgraded." returned false. Condition context:
sql failed to upgrade and so the uninstall of the upgraded product will not occur.
Error: Action "UninstallForMSDE2000Action" failed during execution. Error information reported during run:
Action: "UninstallForMSDE2000Action" will be marked as failed due to the following condition:
Condition "sql was successfully upgraded." returned false. Condition context:
sql failed to upgrade and so the uninstall of the upgraded product will not occur.
Installation of package: "patchMSDE2000" failed due to a precondition.
Error: Action "UninstallForSQLAction" failed during execution. Error information reported during run:
Action: "UninstallForSQLAction" will be marked as failed due to the following condition:
Condition "sql was successfully upgraded." returned false. Condition context:
sql failed to upgrade and so the uninstall of the upgraded product will not occur.
Installation of package: "patchLibertySql" failed due to a precondition.
Action "InstallToolsAction" will return false due to the following preconditions:
Condition "Action: InstallToolsAction.9 has finished and failed." returned true.
Installation of package: "tools" failed due to a precondition.
Step "InstallToolsAction" was not able to run.
Skipped: InstallASAction
Skipped: Action "InstallASAction" was not run. Information reported during analysis:
No install request found for package: "as", install will be skipped as a result.
Skipped: InstallRSAction
Skipped: Action "InstallRSAction" was not run. Information reported during analysis:
No install request found for package: "rs", install will be skipped as a result.
Skipped: UninstallForRS2000Action
Skipped: Action "UninstallForRS2000Action" was not run. Information reported during analysis:
Action: "UninstallForRS2000Action" will be skipped due to the following condition:
Condition "Action: InstallRSAction was skipped." returned true.
Running: ReportChainingResults at: 2007/2/19 19:55:44
Error: Action "ReportChainingResults" threw an exception during execution.
One or more packages failed to install. Refer to logs for error details. : 1612
Error Code: 0x8007064c (1612)
Windows Error Text: The installation source for this product is not available. Verify that the source exists and that you can access it.

Source File Name: sqlchaining\sqlchainingactions.cpp
Compiler Timestamp: Thu Sep 1 22:23:05 2005
Function Name: sqls::ReportChainingResults::perform
Source Line Number: 3097

- Context --
sqls::HostSetupPackageInstallerSynch::postCommit
sqls::HighlyAvailablePackage::preInstall
sqls::HighlyAvailablePackage::manageVsResources
sqls::Host
Error: Failed to add file :"C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup0012_CATCSAP021211_.NET Framework 2.0.log" to cab file : "C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\SqlSetup0012.cab" Error Code : 2
Error: Failed to add file :"C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup0012_CATCSAP021211_.NET Framework 2.0 LangPack.log" to cab file : "C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\SqlSetup0012.cab" Error Code : 2
Error: Failed to add file :"C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup0012_CATCSAP021211_.NET Framework Upgrade Advisor.log" to cab file : "C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\SqlSetup0012.cab" Error Code : 2
Error: Failed to add file :"C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup0012_CATCSAP021211_.NET Framework Upgrade Advisor LangPack.log" to cab file : "C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\SqlSetup0012.cab" Error Code : 2
Error: Failed to add file :"C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup0012_CATCSAP021211_.NET Framework Windows Installer.log" to cab file : "C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\SqlSetup0012.cab" Error Code : 2
Error: Failed to add file :"C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup0012_CATCSAP021211_.NET Framework Windows Installer LangPack.log" to cab file : "C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\SqlSetup0012.cab" Error Code : 2
Running: UploadDrWatsonLogAction at: 2007/2/19 19:56:20
Message pump returning: 1612

Core.log

Microsoft SQL Server 2005 Setup beginning at Mon Mar 19 19:48:44 2007
Process ID : 1864
\\Catcsdc021209\SQL\DISC1\setup.exe Version: 2005.90.1399.0
Running: LoadResourcesAction at: 2007/2/19 19:48:44
Complete: LoadResourcesAction at: 2007/2/19 19:48:44, returned true
Running: ParseBootstrapOptionsAction at: 2007/2/19 19:48:44
Loaded DLL:\\Catcsdc021209\SQL\DISC1\xmlrw.dll Version:2.0.3604.0
Complete: ParseBootstrapOptionsAction at: 2007/2/19 19:48:44, returned true
Running: ValidateWinNTAction at: 2007/2/19 19:48:44
Complete: ValidateWinNTAction at: 2007/2/19 19:48:44, returned true
Running: ValidateMinOSAction at: 2007/2/19 19:48:44
Complete: ValidateMinOSAction at: 2007/2/19 19:48:44, returned true
Running: PerformSCCAction at: 2007/2/19 19:48:44
Complete: PerformSCCAction at: 2007/2/19 19:48:44, returned true
Running: ActivateLoggingAction at: 2007/2/19 19:48:44
Complete: ActivateLoggingAction at: 2007/2/19 19:48:44, returned true
Delay load of action "DetectPatchedBootstrapAction" returned nothing. No action will occur as a result.
Action "LaunchPatchedBootstrapAction" will be skipped due to the following restrictions:
Condition "EventCondition: __STP_LaunchPatchedBootstrap__1864" returned false.
Running: PerformSCCAction2 at: 2007/2/19 19:48:44
Loaded DLL:C:\WINDOWS\system32\msi.dll Version:3.1.4000.2435
Loaded DLL:C:\WINDOWS\system32\msi.dll Version:3.1.4000.2435
Complete: PerformSCCAction2 at: 2007/2/19 19:48:44, returned true
Running: PerformDotNetCheck at: 2007/2/19 19:48:44
Complete: PerformDotNetCheck at: 2007/2/19 19:48:44, returned true
Running: ComponentUpdateAction at: 2007/2/19 19:48:44
Complete: ComponentUpdateAction at: 2007/2/19 19:49:3, returned true
Running: DetectLocalBootstrapAction at: 2007/2/19 19:49:3
Complete: DetectLocalBootstrapAction at: 2007/2/19 19:49:3, returned true
Running: LaunchLocalBootstrapAction at: 2007/2/19 19:49:3
Error: Action "LaunchLocalBootstrapAction" threw an exception during execution. Error information reported during run:
"C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\setup.exe" finished and returned: 1612
Aborting queue processing as nested installer has completed
Message pump returning: 1612

Thanks for any Help

Don

I am trying to install evaluation version and i am having the same problem.I ran the sqleval.exe, after downloading the file from microsoft website, but i dont see the sql enterprise component.Please let me know which one should i download , am i doing something wrong by not configuring the server properly.

sql

Having trouble implementing complicated business rules.

The company I work for is a managed healthcare organization. One
particular metric we use for determining compensation for a medical
practice in our network is tracking the number of times a particular
practice sees a particular patient (member of the healthcare network).
Practices are awarded one "point" for each such occurrance within a
given timeframe, and compensated according to the number of total
points they accumulate for all network members.
As such, each month, I must take the medical claims filed for that
month and traverse through them in chronological order for each
member/practice combination, a "point" for each instance, but only one
per combination in, for example, a three month period. Therefore, if
practice A sees member 1 on 2006-01-01, then practice A would be
awarded one point on 2006-01-01, and would not be eligible for another
point for seeing member 1 until 2006-04-01.
Traversing the ordered data set is the easy part. I utilize a cursor,
note the last point date for each member/practice combination involved,
and then loop through new claims, awarding points for any claim that is
at least three months from the date the last point was awarded. The
problem I am having is correctly building that data set (cursor). This
is due to certain specific business rules I will list below. Here is a
simplified representation of the data involved:
-- Medical Practices:
CREATE TABLE Practices
(
PracticeID VARCHAR(6),
SpecialtyID INT
)
INSERT Practices VALUES ('A', 10)
INSERT Practices VALUES ('B', 10)
INSERT Practices VALUES ('C', 10)
INSERT Practices VALUES ('D', 21)
INSERT Practices VALUES ('E', 21)
INSERT Practices VALUES ('F', 21)
INSERT Practices VALUES ('G', 45)
-- Practices Splits (occasionally, one practice
-- will split up into multiple newer practices,
-- or multiple practices will merge into one newer
-- practice):
CREATE TABLE PracticeSplits
(
PracticeID_OLD VARCHAR(6),
PRacticeID_NEW VARCHAR(6)
)
INSERT PracticeSplits VALUES ('A', 'B')
INSERT PracticeSplits VALUES ('A', 'C')
INSERT PracticeSplits VALUES ('D', 'F')
INSERT PracticeSplits VALUES ('E', 'F')
-- SpecialtyExceptions (will explain below):
CREATE TABLE SpecialtyExceptions
(
SpecialtyID INT
)
INSERT SpecialtyExceptions VALUES (10)
-- Medical Claims:
CREATE TABLE Claims
(
ClaimID VARCHAR(16),
MemberID INT,
PracticeID VARCHAR(6),
VisitDate DATETIME
)
INSERT Claims VALUES ('200600001', 1, 'A', '2006-01-01')
INSERT Claims VALUES ('200600002', 1, 'A', '2006-02-11')
INSERT Claims VALUES ('200600003', 1, 'A', '2006-03-01')
INSERT Claims VALUES ('200600004', 1, 'A', '2006-03-30')
INSERT Claims VALUES ('200600005', 2, 'A', '2006-02-01')
INSERT Claims VALUES ('200600006', 2, 'B', '2006-01-01')
INSERT Claims VALUES ('200600007', 2, 'B', '2006-01-01')
INSERT Claims VALUES ('200600008', 2, 'C', '2006-03-01')
INSERT Claims VALUES ('200600009', 3, 'A', '2006-02-01')
INSERT Claims VALUES ('2006000010', 3, 'c', '2006-02-21')
INSERT Claims VALUES ('2006000011', 4, 'D', '2006-02-24')
INSERT Claims VALUES ('2006000012', 4, 'E', '2006-03-01')
INSERT Claims VALUES ('2006000013', 4, 'E', '2006-04-26')
INSERT Claims VALUES ('2006000014', 5, 'F', '2006-01-11')
INSERT Claims VALUES ('2006000015', 5, 'A', '2006-05-11')
INSERT Claims VALUES ('2006000016', 5, 'G', '2006-05-14')
Here are the rules:
1) In determining the date of the last point awarded, practice
splits must be considered. In this scenario, if practice A was
awarded a point on '2006-01-01', then neither practice A nor
practices B nor C may receive a point for the next three months.
2) Certain specialties are handled as exceptions, in that only
one point shall be awarded to *any* practice of the same
specialty where that specialty is represented in the
SpecialtyExceptions table. In the above scenario, if practice A
is awarded a point for seeing member 1 on 2006-01-01, then no
other practice with a specialty ID of 10 may receive a point for
seeing member 1 until 2006-04-01.
PROBLEM: Produce a data set consisting of all claims for each
network member, for each practice that would reflect the following
data, thereby facilitating the awarding of visit points in
accordance with the aforementioned business rules.
ClaimID, MemberID, PracticeID, VisitDate, PriorMaxVisitDate,
SpecialtyID
If I've been unclear on anything, please let me know. The schema was
developed by a contractor some time ago. While I would be open to
suggestions on any possible improvements in that regard, I'm not
exactly itching to re-write any more of it that might be absolutely
necessary.A couple of questions...
First, regarding this "one point within a time frame" rule, can you
elaborate on that? Is it one point per quarter per member, or must there be
a 3 month window? If Member 1 has an appointment on 2006-02-17 and another
apointment on 2006-04-01, will you count the later appointment for the month
of April, or exclude it because there was already an appointment in the last
3 months? If you are expluding it, do you do so based on 3 calendar months,
or 90 days?
In your sample data, specialties and practice splits are equivilant.
Meaning all practices in specialty 10 (A,B,C) are split, and all practices
in Specialty 21 (D,E,F) are also split. Is this just coincidence in your
test data, or are practices always split for a given specialty? If so, both
the PracticeSplits and the SpecialtyExceptions are redundant. Also, in the
case of specialty 10 being an exception, because these practices are already
split, this is redundant. Again, if this is merely a coincidence then it is
fine.
If you really have redundant rules built into different tables, then you
will want to change this to minimize the extraneous data, and simplify the
rules. In the mean time, you should be able to get all this information in
a single select without looping through an ordered set.
"Richard Carpenter" <rumbledor@.hotmail.com> wrote in message
news:1148409474.980326.150370@.j33g2000cwa.googlegroups.com...
> The company I work for is a managed healthcare organization. One
> particular metric we use for determining compensation for a medical
> practice in our network is tracking the number of times a particular
> practice sees a particular patient (member of the healthcare network).
> Practices are awarded one "point" for each such occurrance within a
> given timeframe, and compensated according to the number of total
> points they accumulate for all network members.
> As such, each month, I must take the medical claims filed for that
> month and traverse through them in chronological order for each
> member/practice combination, a "point" for each instance, but only one
> per combination in, for example, a three month period. Therefore, if
> practice A sees member 1 on 2006-01-01, then practice A would be
> awarded one point on 2006-01-01, and would not be eligible for another
> point for seeing member 1 until 2006-04-01.
> Traversing the ordered data set is the easy part. I utilize a cursor,
> note the last point date for each member/practice combination involved,
> and then loop through new claims, awarding points for any claim that is
> at least three months from the date the last point was awarded. The
> problem I am having is correctly building that data set (cursor). This
> is due to certain specific business rules I will list below. Here is a
> simplified representation of the data involved:
> -- Medical Practices:
> CREATE TABLE Practices
> (
> PracticeID VARCHAR(6),
> SpecialtyID INT
> )
> INSERT Practices VALUES ('A', 10)
> INSERT Practices VALUES ('B', 10)
> INSERT Practices VALUES ('C', 10)
> INSERT Practices VALUES ('D', 21)
> INSERT Practices VALUES ('E', 21)
> INSERT Practices VALUES ('F', 21)
> INSERT Practices VALUES ('G', 45)
> -- Practices Splits (occasionally, one practice
> -- will split up into multiple newer practices,
> -- or multiple practices will merge into one newer
> -- practice):
> CREATE TABLE PracticeSplits
> (
> PracticeID_OLD VARCHAR(6),
> PRacticeID_NEW VARCHAR(6)
> )
> INSERT PracticeSplits VALUES ('A', 'B')
> INSERT PracticeSplits VALUES ('A', 'C')
> INSERT PracticeSplits VALUES ('D', 'F')
> INSERT PracticeSplits VALUES ('E', 'F')
> -- SpecialtyExceptions (will explain below):
> CREATE TABLE SpecialtyExceptions
> (
> SpecialtyID INT
> )
> INSERT SpecialtyExceptions VALUES (10)
> -- Medical Claims:
> CREATE TABLE Claims
> (
> ClaimID VARCHAR(16),
> MemberID INT,
> PracticeID VARCHAR(6),
> VisitDate DATETIME
> )
> INSERT Claims VALUES ('200600001', 1, 'A', '2006-01-01')
> INSERT Claims VALUES ('200600002', 1, 'A', '2006-02-11')
> INSERT Claims VALUES ('200600003', 1, 'A', '2006-03-01')
> INSERT Claims VALUES ('200600004', 1, 'A', '2006-03-30')
> INSERT Claims VALUES ('200600005', 2, 'A', '2006-02-01')
> INSERT Claims VALUES ('200600006', 2, 'B', '2006-01-01')
> INSERT Claims VALUES ('200600007', 2, 'B', '2006-01-01')
> INSERT Claims VALUES ('200600008', 2, 'C', '2006-03-01')
> INSERT Claims VALUES ('200600009', 3, 'A', '2006-02-01')
> INSERT Claims VALUES ('2006000010', 3, 'c', '2006-02-21')
> INSERT Claims VALUES ('2006000011', 4, 'D', '2006-02-24')
> INSERT Claims VALUES ('2006000012', 4, 'E', '2006-03-01')
> INSERT Claims VALUES ('2006000013', 4, 'E', '2006-04-26')
> INSERT Claims VALUES ('2006000014', 5, 'F', '2006-01-11')
> INSERT Claims VALUES ('2006000015', 5, 'A', '2006-05-11')
> INSERT Claims VALUES ('2006000016', 5, 'G', '2006-05-14')
> Here are the rules:
> 1) In determining the date of the last point awarded, practice
> splits must be considered. In this scenario, if practice A was
> awarded a point on '2006-01-01', then neither practice A nor
> practices B nor C may receive a point for the next three months.
> 2) Certain specialties are handled as exceptions, in that only
> one point shall be awarded to *any* practice of the same
> specialty where that specialty is represented in the
> SpecialtyExceptions table. In the above scenario, if practice A
> is awarded a point for seeing member 1 on 2006-01-01, then no
> other practice with a specialty ID of 10 may receive a point for
> seeing member 1 until 2006-04-01.
> PROBLEM: Produce a data set consisting of all claims for each
> network member, for each practice that would reflect the following
> data, thereby facilitating the awarding of visit points in
> accordance with the aforementioned business rules.
> ClaimID, MemberID, PracticeID, VisitDate, PriorMaxVisitDate,
> SpecialtyID
> If I've been unclear on anything, please let me know. The schema was
> developed by a contractor some time ago. While I would be open to
> suggestions on any possible improvements in that regard, I'm not
> exactly itching to re-write any more of it that might be absolutely
> necessary.
>|||Jim Underwood wrote:
> A couple of questions...
> First, regarding this "one point within a time frame" rule, can you
> elaborate on that? Is it one point per quarter per member, or must there
be
> a 3 month window? If Member 1 has an appointment on 2006-02-17 and anothe
r
> apointment on 2006-04-01, will you count the later appointment for the mon
th
> of April, or exclude it because there was already an appointment in the la
st
> 3 months? If you are expluding it, do you do so based on 3 calendar month
s,
> or 90 days?
It is based on a three month window and pertains to a particular member
visit with a particular practice. For example, of the claims reviewed
for the current month, a particular practice could be awarded ten visit
points provided they saw ten different members, none of whom had
visited that practice (or any split-related practice, or any specialty
excepted practice) within the past three months.

> In your sample data, specialties and practice splits are equivilant.
> Meaning all practices in specialty 10 (A,B,C) are split, and all practices
> in Specialty 21 (D,E,F) are also split. Is this just coincidence in your
> test data, or are practices always split for a given specialty? If so, bo
th
> the PracticeSplits and the SpecialtyExceptions are redundant. Also, in th
e
> case of specialty 10 being an exception, because these practices are alrea
dy
> split, this is redundant. Again, if this is merely a coincidence then it
is
> fine.
It is, in fact, merely coincidental of my hastily compiled test data.
There is no relationship between practice splits and specialties.

> If you really have redundant rules built into different tables, then you
> will want to change this to minimize the extraneous data, and simplify the
> rules. In the mean time, you should be able to get all this information i
n
> a single select without looping through an ordered set.
Well, there are additional requirements that prevent handling this
through query. For starters, it is possible for a claim to be reversed
(voided), thereby rendering all visit points from the visit date on
that claim forward for that practice/member invalid, requiring the
process to reconsider and reestablish visit points for all subsequent
claim data.
I *would* be interested to know how I might be able to establish these
visit points on a one-per-three-month basis through standard query
while adhering to these business rules, though. Maybe I *could* make
that work after all.|||OK, this solution may be more complicated than it needs to be, but I think I
was able to get the results as a distinct list of "point worthy" encounters.
If the list is accurate, you can just change the select clause to
PracticeID, Count(*)
and group by practiceID
I created a cross referencing view on Practice Splits so that D and E would
be mutually exclusive, along with B and C. I assumed this is how you wanted
it to work, just remove the view and access the table directly if this is
not the case.
I also assumed that you wanted results by quarter, or rather wanted to
exclude points based on an earlier encounter with the same patient in the
particular quarter. I used 4 datetime variables, 2 to control the time
frame for which you are counting points, and 2 to control the timeframe for
which you are checking to see if points were already awarded.
You may be better off looping through this data in procedural code, if that
procedural code is much easier to follow. The multiple not exists and
subqueries make this a little ugly.
/*
Create a view to cross reference practice splits using the transitive
property
if A splits with B and A splits with C then B will split with C
This also duplicates the date with columns reversed for ease of joining
later on
*/
create view PracticeSplit_vw as
select b.PracticeID_NEW as PracticeID_OLD, c.PracticeID_NEW
from PracticeSplits a
inner join PracticeSplits b
on a.PracticeID_OLD = b.PracticeID_OLD
inner join PracticeSplits c
on b.PracticeID_OLD = c.PracticeID_OLD
and b.PracticeID_new <> c.practiceID_new
union
select b.PracticeID_OLD as PracticeID_OLD, c.PracticeID_OLD
from PracticeSplits a
inner join PracticeSplits b
on a.PracticeID_NEW = b.PracticeID_NEW
inner join PracticeSplits c
on b.PracticeID_NEW = c.PracticeID_NEW
and b.PracticeID_OLD <> c.PracticeID_OLD
union
select A.PracticeID_OLD, a.PracticeID_NEW
from PracticeSplits a
union
select A.PracticeID_NEW, a.PracticeID_OLD
from PracticeSplits a;
go
Declare @.PeriodStart as datetime
Declare @.PeriodEnd as datetime
Declare @.QuarterStart as datetime
Declare @.QuarterEnd as datetime
set @.PeriodStart = '2006-01-01'
set @.PeriodEnd = '2006-04-01'
set @.QuarterStart = '2006-01-01'
set @.QuarterEnd = '2006-04-01'
Select *
from practices as Prac
inner join claims as Claim
on Prac.PracticeID = Claim.PracticeID
where Claim.VisitDate >= @.PeriodStart
and Claim.VisitDate < @.PeriodEnd
/*
exclude patients already seen this period by this provider
*/
and not exists
(
select 1 from claims as Claim1
where
(
Claim1.VisitDate < Claim.VisitDate
or
(
Claim1.VisitDate = Claim.VisitDate
and claim1.claimID < claim.claimID
)
)
and claim1.memberID = claim.memberID
and claim1.PracticeID = claim.PracticeID
and Claim1.VisitDate >= @.QuarterStart
and Claim1.VisitDate < @.QuarterEnd
)
and not exists
/*
exclude patients for Practice Splits
*/
(
select 1 from claims as Claim1
where
(
Claim1.VisitDate < Claim.VisitDate
or
(
Claim1.VisitDate = Claim.VisitDate
and claim1.claimID < claim.claimID
)
)
and claim1.memberID = claim.memberID
and claim1.PracticeID in
(
select split.PracticeID_NEW
from PracticeSplit_vw as split
where split.PracticeID_OLD = claim.PracticeID
)
and Claim1.VisitDate >= @.QuarterStart
and Claim1.VisitDate < @.QuarterEnd
)
and not exists
/*
exclude patients for specialty exceptions
*/
(
select 1 from claims as Claim1
where
(
Claim1.VisitDate < Claim.VisitDate
or
(
Claim1.VisitDate = Claim.VisitDate
and claim1.claimID < claim.claimID
)
)
and claim1.memberID = claim.memberID
and Prac.SpecialtyID in
(
select spec.SpecialtyID
from SpecialtyExceptions as spec
where spec.SpecialtyID = Prac.SpecialtyID
)
and Claim1.VisitDate >= @.QuarterStart
and Claim1.VisitDate < @.QuarterEnd
)|||Take a look at what I posted and see if it is manageable (and if it works at
all on real data). If it works as it is, we may be able to add another
check to it to account for voided claims. Actually, we can definately do
it, it just may be more trouble than it is worth.
"Richard Carpenter" <rumbledor@.hotmail.com> wrote in message
news:1148415117.269330.20150@.j73g2000cwa.googlegroups.com...
> Jim Underwood wrote:
there be
another
month
last
months,
> It is based on a three month window and pertains to a particular member
> visit with a particular practice. For example, of the claims reviewed
> for the current month, a particular practice could be awarded ten visit
> points provided they saw ten different members, none of whom had
> visited that practice (or any split-related practice, or any specialty
> excepted practice) within the past three months.
>
practices
your
both
the
already
it is
> It is, in fact, merely coincidental of my hastily compiled test data.
> There is no relationship between practice splits and specialties.
>
the
in
> Well, there are additional requirements that prevent handling this
> through query. For starters, it is possible for a claim to be reversed
> (voided), thereby rendering all visit points from the visit date on
> that claim forward for that practice/member invalid, requiring the
> process to reconsider and reestablish visit points for all subsequent
> claim data.
> I *would* be interested to know how I might be able to establish these
> visit points on a one-per-three-month basis through standard query
> while adhering to these business rules, though. Maybe I *could* make
> that work after all.
>|||This is similar to the approach I was taking, though I was using the
code to produce a cursor to scroll through and determine the visit
points. Also, as far as the practice splits go, if practice A splits
into practices B and C, there is no relationship between B and C with
regard to visit points.
One point of note, however, is that, although these points would be
tabulated every month, the "new" data may consist of claims that are
months apart, due to the nature of health care claims processing. We
may receive claims that were erroneously filed with the wrong payor(s)
and bounced around for some time before finally making it to us. As
such, there must be a means of handling the possibility of a particular
practice/patient combination being represented more than once in a
given month (new period), yet only receiving one point unless those
visits were actually more than, say, the pre-established period lenght
of three months apart. That was where I found the need for scrolling
through the cursor to compare all new claims chronologically. In
reviewing your code, it appears that visit points would be awarded to
*every* new practice/patient combination for which a previous instance
had not been represented within that given timeframe.
For the sake of clarity, I haven't provided the entire scope for this
problem, though the missing pieces aren't part of the core process. For
example, the time period in question is actually dependent upon the
specialty of the practice - some are three months, but most are six.
This is referenced through a one-to-one relationship with a Specialties
table.
You have, however, brought to light a couple of areas where I could
possibly have been more efficient. I will try and incorporate those
approaches into the current process. I thank you so much for your time
to this point. You have been extremely helpful.|||Your rules do sound quite complex. While I am certain they could be
resolved with straight SQL, procedural code will probably work better,
simply because it will be easier to follow. The effort that would go into
making it work with straight SQL probably would not be worth it, and no one
would be able to maintain the resulting SQL should problems arise.
Thank you for clarifying how practice splits work. It makes that particular
function a little simpler, although your other requirements certainly
complicate things. Once you get all your logic working, you might post the
final code here and see if anyone can consolidate it, just for kicks. I am
rather interested in seeing your final results.
"Richard Carpenter" <rumbledor@.hotmail.com> wrote in message
news:1148564860.790963.269430@.38g2000cwa.googlegroups.com...
> This is similar to the approach I was taking, though I was using the
> code to produce a cursor to scroll through and determine the visit
> points. Also, as far as the practice splits go, if practice A splits
> into practices B and C, there is no relationship between B and C with
> regard to visit points.
> One point of note, however, is that, although these points would be
> tabulated every month, the "new" data may consist of claims that are
> months apart, due to the nature of health care claims processing. We
> may receive claims that were erroneously filed with the wrong payor(s)
> and bounced around for some time before finally making it to us. As
> such, there must be a means of handling the possibility of a particular
> practice/patient combination being represented more than once in a
> given month (new period), yet only receiving one point unless those
> visits were actually more than, say, the pre-established period lenght
> of three months apart. That was where I found the need for scrolling
> through the cursor to compare all new claims chronologically. In
> reviewing your code, it appears that visit points would be awarded to
> *every* new practice/patient combination for which a previous instance
> had not been represented within that given timeframe.
> For the sake of clarity, I haven't provided the entire scope for this
> problem, though the missing pieces aren't part of the core process. For
> example, the time period in question is actually dependent upon the
> specialty of the practice - some are three months, but most are six.
> This is referenced through a one-to-one relationship with a Specialties
> table.
> You have, however, brought to light a couple of areas where I could
> possibly have been more efficient. I will try and incorporate those
> approaches into the current process. I thank you so much for your time
> to this point. You have been extremely helpful.
>

Having condition

I have query:
SELECT name,company,sum(quantity) as quantity from table
GROUP BY name,company WITH ROLLUP HAVING name is not null
But in result set I get also resulting rows with name is null:
name company quantity
--
NULL NULL 100
NULL company1 2
NULL company2 5
...
...
name 1 company1 2
...
Any idea why?
How can I remove summarazing rows with name is null in result set?
I thought that having should work?
regards,Simonwhere name is not null
Having is intended for filtering aggregate values, not column values.
Admittedly, I would have expected it to work anyway. Maybe the rollup is
affecting it. I don't generally have a use for rollup, so I'm not really
sure how it functions...
"simonZ" <simon.zupan@.studio-moderna.com> wrote in message
news:%23N4vH%23HZGHA.2136@.TK2MSFTNGP05.phx.gbl...
> I have query:
> SELECT name,company,sum(quantity) as quantity from table
> GROUP BY name,company WITH ROLLUP HAVING name is not null
> But in result set I get also resulting rows with name is null:
> name company quantity
> --
> NULL NULL 100
> NULL company1 2
> NULL company2 5
> ...
> ...
> name 1 company1 2
> ...
> Any idea why?
> How can I remove summarazing rows with name is null in result set?
> I thought that having should work?
> regards,Simon
>|||Hi,
Check WITH ROLLUP clause in BOL.
The number of summary rows in the result set is determined by the number of
columns included in the GROUP BY clause. Each operand (column) in the GROUP
BY clause is bound under the grouping NULL and grouping is applied to all
other operands (columns). Because CUBE returns every possible combination of
group and subgroup, the number of rows is the same, regardless of the order
in which the grouping columns are specified.
Tomasz B.
"Jim Underwood" wrote:

> where name is not null
> Having is intended for filtering aggregate values, not column values.
> Admittedly, I would have expected it to work anyway. Maybe the rollup is
> affecting it. I don't generally have a use for rollup, so I'm not really
> sure how it functions...
> "simonZ" <simon.zupan@.studio-moderna.com> wrote in message
> news:%23N4vH%23HZGHA.2136@.TK2MSFTNGP05.phx.gbl...
>
>|||Thanks. I looked it up after making the last post, and tested it out.
On SQL 2000 the having clause works fine with this same logic. Granted, my
tables are different, but the following excluded null values from the result
set.
select description, bogusID, count(*), sum(random_id) from my_table
group by description, bogusID with rollup
having description is not null.
If I remove the having, then I get back rows where description is null, with
the having these rows are excluded. However, in my test the having
description is not null also removed the grand summary at the end of the
report. This is as expected, and the grand summary row is there if I use
where instead of having.
"Tomasz Borawski" <TomaszBorawski@.discussions.microsoft.com> wrote in
message news:2E2D3DBB-EA47-4E7F-BBB5-73C86261AA95@.microsoft.com...
> Hi,
> Check WITH ROLLUP clause in BOL.
> The number of summary rows in the result set is determined by the number
of
> columns included in the GROUP BY clause. Each operand (column) in the
GROUP
> BY clause is bound under the grouping NULL and grouping is applied to all
> other operands (columns). Because CUBE returns every possible combination
of
> group and subgroup, the number of rows is the same, regardless of the
order
> in which the grouping columns are specified.
> Tomasz B.
> "Jim Underwood" wrote:
>
is
really|||I meant to ask in my last response...
What version of SQL Server are you using, and could you post table DDL and
the full query that you are executing. If what you already posted is the
complete query, then just say so.
"simonZ" <simon.zupan@.studio-moderna.com> wrote in message
news:%23N4vH%23HZGHA.2136@.TK2MSFTNGP05.phx.gbl...
> I have query:
> SELECT name,company,sum(quantity) as quantity from table
> GROUP BY name,company WITH ROLLUP HAVING name is not null
> But in result set I get also resulting rows with name is null:
> name company quantity
> --
> NULL NULL 100
> NULL company1 2
> NULL company2 5
> ...
> ...
> name 1 company1 2
> ...
> Any idea why?
> How can I remove summarazing rows with name is null in result set?
> I thought that having should work?
> regards,Simon
>|||The only reliable test you can make in HAVING with ROLLUP/CUBE
is based on the GROUPING(column) test.So in this example you can test
HAVING GROUPING([name])=0/1
HAVING GROUPING(company)=0/1
HAVING GROUPING([name])=0/1 and/or GROUPING(company)=0/1
0 will test for null,1 a non null if i remember:)
Of course you make as complex a HAVING as you want using the GROUPING()
statements ie.
GROUPING([name])+GROUPING(company)=0
Of course the big implication of all this is that a temp table or derived
table
must be used for aggregate testing.Silly:)
"simonZ" <simon.zupan@.studio-moderna.com> wrote in message
news:%23N4vH%23HZGHA.2136@.TK2MSFTNGP05.phx.gbl...
>I have query:
> SELECT name,company,sum(quantity) as quantity from table
> GROUP BY name,company WITH ROLLUP HAVING name is not null
> But in result set I get also resulting rows with name is null:
> name company quantity
> --
> NULL NULL 100
> NULL company1 2
> NULL company2 5
> ...
> ...
> name 1 company1 2
> ...
> Any idea why?
> How can I remove summarazing rows with name is null in result set?
> I thought that having should work?
> regards,Simon
>

hash table (#) order by problem with more records

We have one single hash (#) table, in which we insert data processing
priority wise (after calculating priority).
for. e.g.

Company Product Priority Prod. QtyProd_Plan_Date
C1 P11100
C1 P22 50
C1 P33 30
C2 P11200
C2 P42 40
C2 P53 10

There is a problem when accessing data for usage priority wise.
Problem is as follows:

We want to plan production date as per group (company) sorted order and
priority wise.

==>With less data, it works fine.
==>But when there are more records for e.g. 100000 or more , it changes
the logical order of data

So plan date calculation gets effected.

==Although I have solved this problem with putting identity column and
checking in where condition.

But, I want to know why this problem is coming.

If anybody have come across this similar problem, please let me know
the reason and your solution.

IS IT SQL SERVER PROBLEM?

Thanks & Regards,
T.S.Negi> when there are more records for e.g. 100000 or more , it changes
> the logical order of data

Are you referring to the perceived order in the table? Rows in tables
have NO logical order in a relational database. If you require a
particular order you have to query them using a SELECT statement with
an ORDER BY clause otherwise the ordering is undefined.

If that doesn't answer your question then please describe your problem
with DDL (including keys), sample data INSERT statements and show your
required end result.

--
David Portas
SQL Server MVP
--|||While inserting records in hash table. It is already order by on some
fields.
But when selecting/updating records, I want the same order of records
should be updated/selected.

"Rows in tables have NO logical order in a relational database"
I think, True for hash(#) and permanent table.

T.S.Negi

David Portas wrote:
> > when there are more records for e.g. 100000 or more , it changes
> > the logical order of data
> Are you referring to the perceived order in the table? Rows in tables
> have NO logical order in a relational database. If you require a
> particular order you have to query them using a SELECT statement with
> an ORDER BY clause otherwise the ordering is undefined.
> If that doesn't answer your question then please describe your
problem
> with DDL (including keys), sample data INSERT statements and show
your
> required end result.
> --
> David Portas
> SQL Server MVP
> --|||There is an update condition. Which I want to make sure, performing on
ordered data (order by used at the time of insert).
I want to avoide loop.

Reason: "Rows in tables have NO logical order in a relational database"
!!!!

So Please advice.
Thanks,
T.S.Negi

Sample SQL:
===========

UPDATE #WK_PDR_ProcessingData SET
@.Opn_Stock_Qty= CASE WHEN (
@.Customer_Cd = Customer_Cd
AND @.Product_No = Product_No
AND @.Product_Site_Cd = Product_Site_Cd
AND @.Assy_Company_Cd = Assy_Company_Cd
AND @.Assy_Section_Cd = Assy_Section_Cd
AND @.Line_Cd = Line_Cd
) THEN @.Opn_Stock_Qty + @.Production_Qty - @.Requirement_Qty
ELSE begin_Stock_Qty END,
Calc_Stock_Qty= @.Opn_Stock_Qty + Production_Qty - Requirement_Qty,
@.Customer_Cd = Customer_Cd,
@.Product_No = Product_No,
@.Product_Site_Cd= Product_Site_Cd,
@.Assy_Company_Cd= Assy_Company_Cd,
@.Assy_Section_Cd= Assy_Section_Cd,
@.Line_Cd = Line_Cd,
@.Production_Qty = Production_Qty,
@.Requirement_Qty= Requirement_Qty
FROM #WK_PDR_ProcessingData|||tilak.negi@.mind-infotech.com (tilak.negi@.mind-infotech.com) writes:
> While inserting records in hash table. It is already order by on some
> fields.

And once it is inserted, there is no longer any order.

> But when selecting/updating records, I want the same order of records
> should be updated/selected.
> "Rows in tables have NO logical order in a relational database"
> I think, True for hash(#) and permanent table.

Well, obviously you have some operation that does not give you the
desired result, and you posted an UPDATE statement, which is a little
funny, because all you do is to assign a variable.

I suggest that you follow the standard recommendation and post:

o CREATE TABLE statement for your table(s)
o INSERT statements with sample data.
o The desired result given the sample.
o A short narrative of what ou are trying to achieve.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||UPDATEs are not ordered either. The result of your UPDATE statement is
undefined, unreliable and, in my view, not useful.

Please specify the whole problem rather than post fragments of your
non-working solution. The best way to specify the problem is to post
DDL, sample data and required end results. See:
http://www.aspfaq.com/etiquette.asp?id=5006

--
David Portas
SQL Server MVP
--

Hardware scalability

Dear all,
My company has got a Win 2000 SP3 (PIII 1.2Ghz, 1.5Go RAM) server with SQL
2000 SP3a installed (around 90 databases in which around 10 are used daily
not intensively - total data size : 5.5Go - in which 10% is for daily used
databases). SQL Server is setup to use at most 800Mo of RAM. Transactional
replication is implemented. The server is setup as editor only (distributor
and subscribers are on other powerful servers). All is working fine. Network
load is low (10Mo pikes for I/O). We have got around 20 frequent users on
this server.
We are planning to implement two new databases that should represents a
significant increase in workload (frequent heavy batches processes - 1Go of
data). Moreover, we need to integrate them in the transactional replication
process.
We are wondering if our hardware will be sufficient enough to support this
added workload. Yet, I've not found any rule to deduce hardware requirements
from databases size and use.
Could you give me clues for scaling my server, knowing that I have no
similar test server to make benchmarking? Maybe have you similar systems?
Thanks a lot,
Eric.
Eric,
You're correct there's not much to go on here. However, I would point out
one thing. Sounds like the server infrequently services reasonably short
requests. That indicates that the single processor is probably keeping up
with the requests because its generally only getting one request at a time.
So the responsiveness to the users is acceptable. By integrating heavy
batch processes into the mix, there's a strong likelihood that SQL won't
have an internal scheduler free when a user request is initiated. A mix of
heavy batch or large query, with OLTP on too few processors usually results
in end users waiting on screens.
"itparis" <itparis@.discussions.microsoft.com> wrote in message
news:DF71D8B2-6184-4631-82F3-6FE96FA81514@.microsoft.com...
> Dear all,
> My company has got a Win 2000 SP3 (PIII 1.2Ghz, 1.5Go RAM) server with SQL
> 2000 SP3a installed (around 90 databases in which around 10 are used daily
> not intensively - total data size : 5.5Go - in which 10% is for daily used
> databases). SQL Server is setup to use at most 800Mo of RAM. Transactional
> replication is implemented. The server is setup as editor only
> (distributor
> and subscribers are on other powerful servers). All is working fine.
> Network
> load is low (10Mo pikes for I/O). We have got around 20 frequent users on
> this server.
> We are planning to implement two new databases that should represents a
> significant increase in workload (frequent heavy batches processes - 1Go
> of
> data). Moreover, we need to integrate them in the transactional
> replication
> process.
> We are wondering if our hardware will be sufficient enough to support this
> added workload. Yet, I've not found any rule to deduce hardware
> requirements
> from databases size and use.
> Could you give me clues for scaling my server, knowing that I have no
> similar test server to make benchmarking? Maybe have you similar systems?
> Thanks a lot,
> Eric.
|||"Danny" <someone@.nowhere.com> wrote in message
news:KpdWe.6396$XO6.2458@.trnddc03...
> Eric,
> You're correct there's not much to go on here. However, I would point out
> one thing. Sounds like the server infrequently services reasonably short
> requests. That indicates that the single processor is probably keeping up
> with the requests because its generally only getting one request at a
> time. So the responsiveness to the users is acceptable. By integrating
> heavy batch processes into the mix, there's a strong likelihood that SQL
> won't have an internal scheduler free when a user request is initiated. A
> mix of heavy batch or large query, with OLTP on too few processors usually
> results in end users waiting on screens.
>
I have to agree with Danny on this one. The right answer (as always with
database) is, It depends.
Do you want to optimize your server for general usage, or do you want to
optimize your server to handle the spikes in performance.
For general usage, I would suggest that you add more RAM to the box. 4GB
total and give 2GB to SQL Server. You will still have spikes, most likely
due to the processor running heavy batches, but should otherwise be in
decent shape. On the replication side of the house, depending on the size
of your transactions which are being replicated and how often replication
occurs (immediate, every 15 minutes etc.). You may want to upgrade your NIC
if possible to 100MB or even 1GB.
If you want to optimize to handle the spikes, then more RAM, 2 procs with
higher speeds and larger L2 caches should help out.
You can read up on a lot of the perf counters to watch for at
www.sql-server-performance.com Take a look at McGeHee's article... It's a
great first step...
http://www.sql-server-performance.co...ance_audit.asp
Rick Sawtell
MCT, MCSD, MCDBA
|||The "standard" config for a dedicated and heavy-duty SQLServer
hardware is 2-processors, all the RAM you can get, at least separate
physical drive for log files, generally RAID-5 for the main DBs.
These days with 200gb drives going for a hundred bux you don't need
RAID just to get your storage size up, but it still helps isolate
physical storage concerns. Network-attached storage is even better,
if you have gigahertz networks. And oh yes, Windows2003, makes
hyperthreading work and has better general threading and COM 1.5+.
Click up Dell and configure such a server, betcha can get a couple of
3ghz processors starting around, um, ... $10k? $15k? Depends. Once
you reach blade-scale, adding another processor is cheap.
Let's say a proper current box like this would be around 5x faster
than a single PIII with a single physical disk drive.
J.
On Thu, 15 Sep 2005 02:00:07 -0700, "itparis"
<itparis@.discussions.microsoft.com> wrote:

>Dear all,
>My company has got a Win 2000 SP3 (PIII 1.2Ghz, 1.5Go RAM) server with SQL
>2000 SP3a installed (around 90 databases in which around 10 are used daily
>not intensively - total data size : 5.5Go - in which 10% is for daily used
>databases). SQL Server is setup to use at most 800Mo of RAM. Transactional
>replication is implemented. The server is setup as editor only (distributor
>and subscribers are on other powerful servers). All is working fine. Network
>load is low (10Mo pikes for I/O). We have got around 20 frequent users on
>this server.
>We are planning to implement two new databases that should represents a
>significant increase in workload (frequent heavy batches processes - 1Go of
>data). Moreover, we need to integrate them in the transactional replication
>process.
>We are wondering if our hardware will be sufficient enough to support this
>added workload. Yet, I've not found any rule to deduce hardware requirements
>from databases size and use.
>Could you give me clues for scaling my server, knowing that I have no
>similar test server to make benchmarking? Maybe have you similar systems?
>Thanks a lot,
>Eric.

Hardware scalability

Dear all,
My company has got a Win 2000 SP3 (PIII 1.2Ghz, 1.5Go RAM) server with SQL
2000 SP3a installed (around 90 databases in which around 10 are used daily
not intensively - total data size : 5.5Go - in which 10% is for daily used
databases). SQL Server is setup to use at most 800Mo of RAM. Transactional
replication is implemented. The server is setup as editor only (distributor
and subscribers are on other powerful servers). All is working fine. Network
load is low (10Mo pikes for I/O). We have got around 20 frequent users on
this server.
We are planning to implement two new databases that should represents a
significant increase in workload (frequent heavy batches processes - 1Go of
data). Moreover, we need to integrate them in the transactional replication
process.
We are wondering if our hardware will be sufficient enough to support this
added workload. Yet, I've not found any rule to deduce hardware requirements
from databases size and use.
Could you give me clues for scaling my server, knowing that I have no
similar test server to make benchmarking? Maybe have you similar systems?
Thanks a lot,
Eric.Eric,
You're correct there's not much to go on here. However, I would point out
one thing. Sounds like the server infrequently services reasonably short
requests. That indicates that the single processor is probably keeping up
with the requests because its generally only getting one request at a time.
So the responsiveness to the users is acceptable. By integrating heavy
batch processes into the mix, there's a strong likelihood that SQL won't
have an internal scheduler free when a user request is initiated. A mix of
heavy batch or large query, with OLTP on too few processors usually results
in end users waiting on screens.
"itparis" <itparis@.discussions.microsoft.com> wrote in message
news:DF71D8B2-6184-4631-82F3-6FE96FA81514@.microsoft.com...
> Dear all,
> My company has got a Win 2000 SP3 (PIII 1.2Ghz, 1.5Go RAM) server with SQL
> 2000 SP3a installed (around 90 databases in which around 10 are used daily
> not intensively - total data size : 5.5Go - in which 10% is for daily used
> databases). SQL Server is setup to use at most 800Mo of RAM. Transactional
> replication is implemented. The server is setup as editor only
> (distributor
> and subscribers are on other powerful servers). All is working fine.
> Network
> load is low (10Mo pikes for I/O). We have got around 20 frequent users on
> this server.
> We are planning to implement two new databases that should represents a
> significant increase in workload (frequent heavy batches processes - 1Go
> of
> data). Moreover, we need to integrate them in the transactional
> replication
> process.
> We are wondering if our hardware will be sufficient enough to support this
> added workload. Yet, I've not found any rule to deduce hardware
> requirements
> from databases size and use.
> Could you give me clues for scaling my server, knowing that I have no
> similar test server to make benchmarking? Maybe have you similar systems?
> Thanks a lot,
> Eric.|||"Danny" <someone@.nowhere.com> wrote in message
news:KpdWe.6396$XO6.2458@.trnddc03...
> Eric,
> You're correct there's not much to go on here. However, I would point out
> one thing. Sounds like the server infrequently services reasonably short
> requests. That indicates that the single processor is probably keeping up
> with the requests because its generally only getting one request at a
> time. So the responsiveness to the users is acceptable. By integrating
> heavy batch processes into the mix, there's a strong likelihood that SQL
> won't have an internal scheduler free when a user request is initiated. A
> mix of heavy batch or large query, with OLTP on too few processors usually
> results in end users waiting on screens.
>
I have to agree with Danny on this one. The right answer (as always with
database) is, It depends.
Do you want to optimize your server for general usage, or do you want to
optimize your server to handle the spikes in performance.
For general usage, I would suggest that you add more RAM to the box. 4GB
total and give 2GB to SQL Server. You will still have spikes, most likely
due to the processor running heavy batches, but should otherwise be in
decent shape. On the replication side of the house, depending on the size
of your transactions which are being replicated and how often replication
occurs (immediate, every 15 minutes etc.). You may want to upgrade your NIC
if possible to 100MB or even 1GB.
If you want to optimize to handle the spikes, then more RAM, 2 procs with
higher speeds and larger L2 caches should help out.
You can read up on a lot of the perf counters to watch for at
www.sql-server-performance.com Take a look at McGeHee's article... It's a
great first step...
http://www.sql-server-performance.com/sql_server_performance_audit.asp
Rick Sawtell
MCT, MCSD, MCDBA|||The "standard" config for a dedicated and heavy-duty SQLServer
hardware is 2-processors, all the RAM you can get, at least separate
physical drive for log files, generally RAID-5 for the main DBs.
These days with 200gb drives going for a hundred bux you don't need
RAID just to get your storage size up, but it still helps isolate
physical storage concerns. Network-attached storage is even better,
if you have gigahertz networks. And oh yes, Windows2003, makes
hyperthreading work and has better general threading and COM 1.5+.
Click up Dell and configure such a server, betcha can get a couple of
3ghz processors starting around, um, ... $10k? $15k? Depends. Once
you reach blade-scale, adding another processor is cheap.
Let's say a proper current box like this would be around 5x faster
than a single PIII with a single physical disk drive.
J.
On Thu, 15 Sep 2005 02:00:07 -0700, "itparis"
<itparis@.discussions.microsoft.com> wrote:
>Dear all,
>My company has got a Win 2000 SP3 (PIII 1.2Ghz, 1.5Go RAM) server with SQL
>2000 SP3a installed (around 90 databases in which around 10 are used daily
>not intensively - total data size : 5.5Go - in which 10% is for daily used
>databases). SQL Server is setup to use at most 800Mo of RAM. Transactional
>replication is implemented. The server is setup as editor only (distributor
>and subscribers are on other powerful servers). All is working fine. Network
>load is low (10Mo pikes for I/O). We have got around 20 frequent users on
>this server.
>We are planning to implement two new databases that should represents a
>significant increase in workload (frequent heavy batches processes - 1Go of
>data). Moreover, we need to integrate them in the transactional replication
>process.
>We are wondering if our hardware will be sufficient enough to support this
>added workload. Yet, I've not found any rule to deduce hardware requirements
>from databases size and use.
>Could you give me clues for scaling my server, knowing that I have no
>similar test server to make benchmarking? Maybe have you similar systems?
>Thanks a lot,
>Eric.

Hardware scalability

Dear all,
My company has got a Win 2000 SP3 (PIII 1.2Ghz, 1.5Go RAM) server with SQL
2000 SP3a installed (around 90 databases in which around 10 are used daily
not intensively - total data size : 5.5Go - in which 10% is for daily used
databases). SQL Server is setup to use at most 800Mo of RAM. Transactional
replication is implemented. The server is setup as editor only (distributor
and subscribers are on other powerful servers). All is working fine. Network
load is low (10Mo pikes for I/O). We have got around 20 frequent users on
this server.
We are planning to implement two new databases that should represents a
significant increase in workload (frequent heavy batches processes - 1Go of
data). Moreover, we need to integrate them in the transactional replication
process.
We are wondering if our hardware will be sufficient enough to support this
added workload. Yet, I've not found any rule to deduce hardware requirements
from databases size and use.
Could you give me clues for scaling my server, knowing that I have no
similar test server to make benchmarking? Maybe have you similar systems?
Thanks a lot,
Eric.Eric,
You're correct there's not much to go on here. However, I would point out
one thing. Sounds like the server infrequently services reasonably short
requests. That indicates that the single processor is probably keeping up
with the requests because its generally only getting one request at a time.
So the responsiveness to the users is acceptable. By integrating heavy
batch processes into the mix, there's a strong likelihood that SQL won't
have an internal scheduler free when a user request is initiated. A mix of
heavy batch or large query, with OLTP on too few processors usually results
in end users waiting on screens.
"itparis" <itparis@.discussions.microsoft.com> wrote in message
news:DF71D8B2-6184-4631-82F3-6FE96FA81514@.microsoft.com...
> Dear all,
> My company has got a Win 2000 SP3 (PIII 1.2Ghz, 1.5Go RAM) server with SQL
> 2000 SP3a installed (around 90 databases in which around 10 are used daily
> not intensively - total data size : 5.5Go - in which 10% is for daily used
> databases). SQL Server is setup to use at most 800Mo of RAM. Transactional
> replication is implemented. The server is setup as editor only
> (distributor
> and subscribers are on other powerful servers). All is working fine.
> Network
> load is low (10Mo pikes for I/O). We have got around 20 frequent users on
> this server.
> We are planning to implement two new databases that should represents a
> significant increase in workload (frequent heavy batches processes - 1Go
> of
> data). Moreover, we need to integrate them in the transactional
> replication
> process.
> We are wondering if our hardware will be sufficient enough to support this
> added workload. Yet, I've not found any rule to deduce hardware
> requirements
> from databases size and use.
> Could you give me clues for scaling my server, knowing that I have no
> similar test server to make benchmarking? Maybe have you similar systems?
> Thanks a lot,
> Eric.|||"Danny" <someone@.nowhere.com> wrote in message
news:KpdWe.6396$XO6.2458@.trnddc03...
> Eric,
> You're correct there's not much to go on here. However, I would point out
> one thing. Sounds like the server infrequently services reasonably short
> requests. That indicates that the single processor is probably keeping up
> with the requests because its generally only getting one request at a
> time. So the responsiveness to the users is acceptable. By integrating
> heavy batch processes into the mix, there's a strong likelihood that SQL
> won't have an internal scheduler free when a user request is initiated. A
> mix of heavy batch or large query, with OLTP on too few processors usually
> results in end users waiting on screens.
>
I have to agree with Danny on this one. The right answer (as always with
database) is, It depends.
Do you want to optimize your server for general usage, or do you want to
optimize your server to handle the spikes in performance.
For general usage, I would suggest that you add more RAM to the box. 4GB
total and give 2GB to SQL Server. You will still have spikes, most likely
due to the processor running heavy batches, but should otherwise be in
decent shape. On the replication side of the house, depending on the size
of your transactions which are being replicated and how often replication
occurs (immediate, every 15 minutes etc.). You may want to upgrade your NIC
if possible to 100MB or even 1GB.
If you want to optimize to handle the spikes, then more RAM, 2 procs with
higher speeds and larger L2 caches should help out.
You can read up on a lot of the perf counters to watch for at
www.sql-server-performance.com Take a look at McGeHee's article... It's a
great first step...
http://www.sql-server-performance.c...mance_audit.asp
Rick Sawtell
MCT, MCSD, MCDBA|||The "standard" config for a dedicated and heavy-duty SQLServer
hardware is 2-processors, all the RAM you can get, at least separate
physical drive for log files, generally RAID-5 for the main DBs.
These days with 200gb drives going for a hundred bux you don't need
RAID just to get your storage size up, but it still helps isolate
physical storage concerns. Network-attached storage is even better,
if you have gigahertz networks. And oh yes, Windows2003, makes
hyperthreading work and has better general threading and COM 1.5+.
Click up Dell and configure such a server, betcha can get a couple of
3ghz processors starting around, um, ... $10k? $15k? Depends. Once
you reach blade-scale, adding another processor is cheap.
Let's say a proper current box like this would be around 5x faster
than a single PIII with a single physical disk drive.
J.
On Thu, 15 Sep 2005 02:00:07 -0700, "itparis"
<itparis@.discussions.microsoft.com> wrote:

>Dear all,
>My company has got a Win 2000 SP3 (PIII 1.2Ghz, 1.5Go RAM) server with SQL
>2000 SP3a installed (around 90 databases in which around 10 are used daily
>not intensively - total data size : 5.5Go - in which 10% is for daily used
>databases). SQL Server is setup to use at most 800Mo of RAM. Transactional
>replication is implemented. The server is setup as editor only (distributor
>and subscribers are on other powerful servers). All is working fine. Networ
k
>load is low (10Mo pikes for I/O). We have got around 20 frequent users on
>this server.
>We are planning to implement two new databases that should represents a
>significant increase in workload (frequent heavy batches processes - 1Go of
>data). Moreover, we need to integrate them in the transactional replication
>process.
>We are wondering if our hardware will be sufficient enough to support this
>added workload. Yet, I've not found any rule to deduce hardware requirement
s
>from databases size and use.
>Could you give me clues for scaling my server, knowing that I have no
>similar test server to make benchmarking? Maybe have you similar systems?
>Thanks a lot,
>Eric.

Hanging or lockup issue with SQL Server and Terminal Services 2000 on NT 4 Domain Server

Hi all,

Have a situation that my company has never run across before. Client
is running NT4 for the domain server, using terminal services 2000 and
running an application with a SQL Server backend and they are
experiencing locking problems. Once one person gets locked out then
everyone trying to access that tables is also locked out as a result.
It is not specific to a certain User, or module within the
application. It's not a specific time of the day (like when a backup
would be running) and sometimes it's in the middle of the night when
there are actually less Users on the system.

We have 500 customers using this application. Most are using SQL
Server backend, alot of the newer customers are using Terminal
Services, and the number of Users is not accessive as compared to our
other customers. THe only difference is that I do not specifically
know of another client with an NT4 Domain server in the mix.

We actually switched to SQL Server as the recommended back end due to
locking issues using SQLBase because SQL Server is row locking and
SQLBase is page locking. Since making this change we have stopped
seeing the locking for years until now. Is this a SQLServer issue or
issue with the NT Domain server?

Anyone have any ideas?

Thanks
A"ACP" <Akzsurtep@.aol.com> wrote in message
news:f8ce0b90.0409271213.66baade5@.posting.google.c om...
> Hi all,
> Have a situation that my company has never run across before. Client
> is running NT4 for the domain server, using terminal services 2000 and
> running an application with a SQL Server backend and they are
> experiencing locking problems. Once one person gets locked out then
> everyone trying to access that tables is also locked out as a result.
> It is not specific to a certain User, or module within the
> application. It's not a specific time of the day (like when a backup
> would be running) and sometimes it's in the middle of the night when
> there are actually less Users on the system.
> We have 500 customers using this application. Most are using SQL
> Server backend, alot of the newer customers are using Terminal
> Services, and the number of Users is not accessive as compared to our
> other customers. THe only difference is that I do not specifically
> know of another client with an NT4 Domain server in the mix.
> We actually switched to SQL Server as the recommended back end due to
> locking issues using SQLBase because SQL Server is row locking and
> SQLBase is page locking. Since making this change we have stopped
> seeing the locking for years until now. Is this a SQLServer issue or
> issue with the NT Domain server?
> Anyone have any ideas?
> Thanks
> A

It's hard to say what's going on without more information - what version of
MSSQL do you have and which OS is it running on? What is the application and
how does it connect to MSSQL (ODBC, OLE DB)? Also, since it used to work
fine, has anything changed recently such as a new servicepack installation?

As for the locking itself, what do you mean that someone is "locked out"? Do
you mean their connection times out, that they're the victim of a deadlock,
or something else? Have you checked what sp_who2 and sp_lock say about which
connections are blocked and what objects are locked by the blocking
connection(s)? Is there anything unusual in the MSSQL log at the time the
problem happens?

It sounds like one connection locks a table, then doesn't release it
(perhaps an uncommitted transaction - you can check with DBCC OPENTRAN), but
you will have to look into what the connection is actually doing when the
issue occurs.

Simon|||It's definitely a lock on the SQL Server database. The problem is it
is across the board as far as what Users are doing when it happens.
It is grabbing a lock on a table and then locking others out in a
chain reaction. But it's difficult to pinpoint since it's happening
to Users performing different transactions and hitting different
tables in the database. So I'll check using sp_lock and try and
narrow it down a little more. And then I'll look into the option of
using DBCC OPENTRAN if I can narrow it down.

Thanks for the help|||http://www.sommarskog.se/sqlutil/aba_lockinfo.html

This may be of some help to you.

Akzsurtep@.aol.com (ACP) wrote in message news:<f8ce0b90.0409291713.3d7cd6a@.posting.google.com>...
> It's definitely a lock on the SQL Server database. The problem is it
> is across the board as far as what Users are doing when it happens.
> It is grabbing a lock on a table and then locking others out in a
> chain reaction. But it's difficult to pinpoint since it's happening
> to Users performing different transactions and hitting different
> tables in the database. So I'll check using sp_lock and try and
> narrow it down a little more. And then I'll look into the option of
> using DBCC OPENTRAN if I can narrow it down.
> Thanks for the help