Attach to a running process

Attach to a Process

(Professional only)

Instead of having the profiler launch the process to profile, it is also possible to attach the profiler to an already running .NET Process.

In order to attach to a process, Debugging Tools for Windows must be installed on the computer. These tools can be downloaded from http://www.microsoft.com/whdc/devtools/debugging.

NOTE! On a 64-bit operating system, you will need to download the 32-bit debugging tools to attach to a 32-bit process and the 64-bit debugging tools to attach to a 64-bit process.

After the debugging tools have been installed, the following steps should be performed to attach the profiler to a running process:

1. Select the Attach to Process command from the File menu or Attach Profiler to Process from the Profiler menu if running under Visual Studio.

2. The “Attach to” wizard appears.

3. Select the process you want to attach to from the list of .NET processes.

4. If you want to profile using the default settings, click Start to start the application.

5. If you want to modify settings, you can use the Next button to modify some common settings.

6. When you have decided on the settings, click Start to attach to the process.

7. If Debugging Tools for Windows is not installed, the dialog below will appear, instructing you to install the debugging tools.

Script to Randomly create names and SSN

Script to Randomly create names and SSN from RIS database


DECLARE @Firstnames TABLE(ID int identity(1,1), Firstname varchar(12))
DECLARE @LastNames TABLE(ID int identity(1,1), LastName varchar(20))
DECLARE @FirstNameCount int
DECLARE @LastNameCount int
DECLARE @PatientCount int
DECLARE @PatientID int

DECLARE @FirstNameRandom INT
DECLARE @LastNameRandom INT

DECLARE @Upper INT
DECLARE @Lower INT

INSERT INTO @Firstnames (Firstname)
SELECT FirstName FROM tbPatients GROUP BY FirstName

SELECT @FirstNameCount= Count(*) FROM @Firstnames

INSERT INTO @LastNames (LastName)
SELECT LastName FROM tbPatients GROUP BY LastName

SELECT @LastNameCount= Count(*) FROM @LastNames

SELECT @PatientCount=COUNT(*) FROM tbPatients

SELECT @FirstNameCount, @LastNameCount,@PatientCount

UPDATE tbPatients SET SSN=null


DECLARE cursor_Patients CURSOR FOR
SELECT PatientID FROM tbPatients
OPEN cursor_Patients
FETCH NEXT FROM cursor_Patients INTO @PatientID
WHILE (@@FETCH_STATUS = 0)
BEGIN

SET @Lower=1
SET @Upper=@FirstNameCount
SELECT @FirstNameRandom = ROUND(((@Upper - @Lower -1) * RAND() + @Lower), 0)

SET @Upper=@LastNameCount
SELECT @LastNameRandom = ROUND(((@Upper - @Lower -1) * RAND() + @Lower), 0)

UPDATE tbPatients
SET FirstName = (SELECT Firstname FROM @Firstnames WHERE ID=@FirstNameRandom),
LastName = (SELECT LastName FROM @LastNames WHERE ID=@LastNameRandom)
WHERE PatientID=@PatientID

UPDATE tbPatients
SET SSN = (SELECT CONVERT(varchar(9),CONVERT(int,ROUND(((999999999 - 110000000 -1) * RAND() + 110000000), 0))))
WHERE PatientID=@PatientID

FETCH NEXT FROM cursor_Patients INTO @PatientID
END
CLOSE cursor_Patients
DEALLOCATE cursor_Patients


SELECT FirstName, LastName, SSN FROM tbPatients

SQL Cursor example

Good cursor example here

DECLARE cursor_Patients CURSOR FOR
SELECT PatientID FROM tbPatients
OPEN cursor_Patients
FETCH NEXT FROM cursor_Patients INTO @PatientID
WHILE (@@FETCH_STATUS = 0)
BEGIN
SELECT @PatientID
FETCH NEXT FROM cursor_Patients INTO @PatientID
END
CLOSE cursor_Patients
DEALLOCATE cursor_Patients

ALTER DATABASE replaces sp_dbcmptlevel

ALTER DATABASE Compatibility Level (Transact-SQL)

Sets certain database behaviors to be compatible with the specified version of SQL Server. New in SQL Server 2008, the following ALTER DATABASE syntax replaces the sp_dbcmptlevel procedure for setting the database compatibility level. For other ALTER DATABASE options, see ALTER DATABASE (Transact-SQL).

ALTER DATABASE AdventureWorks
SET COMPATIBILITY_LEVEL = 100;
GO

vs

sp_dbcmptlevel AdventureWorks 100

Getting this error when trying to create an assembly from a DLL.

Determine current database compatibility level
DBCC CHECKDB

Checks the logical and physical integrity of all the objects in the specified database by performing the following operations:

• Runs DBCC CHECKALLOC on the database.
  
• Runs DBCC CHECKTABLE on every table and view in the database.
  
• Runs DBCC CHECKCATALOG on the database.
  
• Validates the contents of every indexed view in the database.
  
• Validates link-level consistency between table metadata and file system directories and files when storing varbinary(max) data in the file system using FILESTREAM.
  
• Validates the Service Broker data in the database.
  

This means that the DBCC CHECKALLOC, DBCC CHECKTABLE, or DBCC CHECKCATALOG commands do not have to be run separately from DBCC CHECKDB. For more detailed information about the checks that these commands perform, see the descriptions of these commands.