Shortcuts used with Start -> Run
_________________________________________________
%ALLUSERSPROFILE% -Open the All User's Profile
%HomeDrive% -Opens your home drive e.g. C:\
%UserProfile% -Opens you User's Profile
%temp% Opens -temporary file Folder
%systemroot% -Opens Windows folder
_________________________________________________
Management Consoles
certmgr.msc --Certificate Manager
ciadv.msc --Indexing Service
compmgmt.msc --Computer management
devmgmt.msc --Device Manager
dfrg.msc --Defragment
diskmgmt.msc --Disk Management
fsmgmt.msc --Folder Sharing Management
eventvwr.msc --Event Viewer
gpedit.msc --Group Policy -XP Pro only
iis.msc --Internet Information Services
lusrmgr.msc --Local Users and Groups
mscorcfg.msc --Net configurations
ntmsmgr.msc --Removable Storage
perfmon.msc --Performance Manager
secpol.msc --Local Security Policy
services.msc --System Services
wmimgmt.msc --Windows Management
____________________________________________________________
Shortcuts
access.cpl --Accessibility Options
hdwwiz.cpl --Add New Hardware Wizard
appwiz.cpl --Add/Remove Programs
timedate.cpl --Date and Time Properties
desk.cpl --Display Properties
inetcpl.cpl --Internet Properties
joy.cpl --Joystick Properties
main.cpl keboard --Keyboard Properties
main.cpl --Mouse Properties
ncpa.cpl --Network Connections
ncpl.cpl --Network Properties
telephon.cpl --Phone and Modem options
powercfg.cpl --Power Management
intl.cpl --Regional settings
mmsys.cpl sounds --Sound Properties
mmsys.cpl --Sounds and Audio Device Properties
sysdm.cpl --System Properties
nusrmgr.cpl --User settings
firewall.cpl --Firewall Settings (sp2)
wscui.cpl --Security Center (sp2)
_____________________________________________________________
Run Commands
Calc --Calculator
Cfgwiz32 --ISDN Configuration Wizard
Charmap --Character Map
Chkdisk --Repair damaged files
Cleanmgr --Cleans up hard drives
Clipbrd --Windows Clipboard viewer
Cmd --Opens a new Command Window (cmd.exe)
Control --Displays Control Panel
Dcomcnfg --DCOM user security
Debug --Assembly language programming tool
Defrag --Defragmentation tool
Drwatson --Records programs crash & snapshots
Dxdiag --DirectX Diagnostic Utility
Explorer --Windows Explorer
Fontview --Graphical font viewer
Ftp -ftp.exe program
Hostname --Returns Computer's name
Ipconfig --Displays IP configuration for all network adapters
Jview --Microsoft Command-line Loader for Java classes
MMC --Microsoft Management Console
Msconfig --Configuration to edit startup files
Msinfo32 --Microsoft System Information Utility
Nbtstat --Displays stats and current connections using NetBios over TCP/IP
Netstat --Displays all active network connections
Nslookup--Returns your local DNS server
Ping --Sends data to a specified host/IP
Regedit --Registry Editor
Regsvr32 --Register/de-register DLL/OCX/ActiveX
Regwiz -Registration wizard
Sfc /scannow --System File Checker
Sndrec32 --Sound Recorder
Sndvol32 --Volume control for soundcard
Sysedit --Edit system startup files (config.sys, autoexec.bat, win.ini, etc.)
Taskmgr --Task manager
Telnet --Telnet program
Tracert --Traces and displays all paths required to reach an internet host
Winipcfg --Displays IP configuration
Wupdmgr --Takes you to Microsoft Windows Update
Monday, July 16, 2007
SQL hierarchial query
"Solving problems that are hierarchical and nested in nature are best helped with a record oriented approach rather than a SET ORIENTED approach"
This assertion comes from the Visual FoxPro environment, where developers can navigate through result sets (VFP cursors…not to be confused with SQL Server Cursors) at the record level, very quickly and easily. No question, VFP is a great database tool. So great in fact, that some have used it for so long, and to solve so many problems, that it's easy to conclude that VFP's offerings are the only optimal hammer in the toolbox for certain operations.
SQL Server 2005 conforms more closely to the ANSI-99 SQL spec – and some of the features of the ANSI-99 standard making querying more flexible than before. One such feature is Common Table Expressions and recursive querying of hierarchical data. I'm going to devote some blog entries over the next few weeks to recursive querying, as I believe developers regularly face this challenge.
I'm going to start with a very simple example, to demonstrate the mechanics of recursive querying in SQL 2005. First, here's a simple set of hierarchical data – a product hierarchy with Brands, Groups, and Items. Each row contains a unique integer identifier, a description, and a reference to the row's parent:
DECLARE @tProducts TABLE (ID int, Name char(50), ParentID int)
INSERT INTO @tProducts VALUES (1, 'Brand 1', null)
INSERT INTO @tProducts VALUES (2, 'Brand 2', null)
INSERT INTO @tProducts VALUES (3, 'Brand 3', null)
INSERT INTO @tProducts VALUES (6, 'Brand 1, Group 1', 1)
INSERT INTO @tProducts VALUES (7, 'Brand 1, Group 2', 1)
INSERT INTO @tProducts VALUES (8, 'Brand 1, Group 3', 1)
INSERT INTO @tProducts VALUES ( 9, 'Brand 2, Group 1', 2)
INSERT INTO @tProducts VALUES (10, 'Brand 2, Group 2', 2)
INSERT INTO @tProducts VALUES ( 11, 'Brand 3, Group 3', 3)
INSERT INTO @tProducts VALUES (12, 'Brand 1, Group 1, Item 1', 6)
INSERT INTO @tProducts VALUES (13, 'Brand 1, Group 1, Item 2', 6)
INSERT INTO @tProducts
VALUES (14, 'Brand 1, Group 1, Item 1, SKU 1', 12)
Here's the challenge: for any specific item in this table, I want to know all the child records, going all the way down the hierarchy. Think about how you'd handle this query in SQL 2000 using SQL statements. While it was doable, querying hierarchical data was never an easy task. Fortunately, SQL 2005 makes this much simpler. Here's the entire query, which sets a search string, and then retrieves all the child records for that search string:
DECLARE @cSearch char(50)
SET @cSearch = 'Brand 1, Group 1'
; WITH ProductCTE AS
-- Anchor query
(SELECT ID, Name, ParentID
FROM @tProducts
WHERE Name = @cSearch
UNION ALL
-- Recursive query
SELECT Prod.ID, Prod.Name, Prod.ParentID
FROM @tProducts Prod
INNER JOIN ProductCTE
ON ProductCTE.ID = Prod.parentID )
SELECT * FROM ProductCTE
I'll confess, when I first looked at CTE and recursive query syntax, I felt pretty stupid that I couldn't grasp it. So, I took an online example, completely changed the sample data, built my own example, and then I didn't feel quite so stupid. ;)
Here's the deal/trick with recursive queries - in a "normal" SQL SELECT statement, you're querying from a table that isn't changing during the lifetime of the query (OK, data could be inserted from another session, but that's a different topic). You're querying directly FROM one table, and into a totally separate result set.
In a recursive query, some of the data you need to query is actually a result of a prior phase of the query. So results become the source for future results. Think about this with respect to our simple example, where we want all the children of a particular row – we can't pull the lowest level (SKU) without pulling the level above that (Item), and we can't do that without pulling the level above that (Group) and so on.
So let's take a look at the anatomy of the query, which has three parts. The first part is defining the Common Table Expression…
; WITH ProductCTE AS
As I said in my last blog post, a CTE is like a temporary derived table or view, with a very short lifespan. What we're going to do in the next two steps is query into ProductCTE for the search string, and then continue to query all the way down the hierarchy by comparing IDs to ParentIDs.
The second part is called the main or anchor query:
(SELECT ID, Name, ParentID
FROM @tProducts
WHERE Name = @cSearch
The anchor query executes first, so we know that ProductCTE will contain the ID, Name, and ParentID for the single row that matches the search condition.
The final part is the actual recursive query, which is connected to the anchor query with a UNION ALL:
UNION ALL
-- Recursive query
SELECT Prod.ID, Prod.Name, Prod.ParentID
FROM @tProducts Prod
INNER JOIN ProductCTE
ON ProductCTE.ID = Prod.ParentID )
Note that the anchor query is performing a join between the original list of products and the ProductCTE. So each "hit" between an ID and a ParentID will go into ProductCTE, and the query will continue until no more matches are found.
OK, so that handles querying DOWNWARD….suppose we wanted to find all the parent rows instead? Just switch the column names on the INNER JOIN in the recursive query:
ON ProductCTE.ParentID = Prod.ID )
If you're wondering about any limit to the number of recursions, the default is 100, which can be configured: check out MAXRECURSION in the online help if you ever have a hierarchy with more than 100 levels. (I'm almost afraid to see a hierarchy with that many levels!)
See, that wasn't so bad? There are many examples of hierarchical data out there, such as Bill of Material data, organization chart data, etc. Anyone who has ever worked with e-commerce applications is likely VERY familiar with the challenges of hierarchical data. SQL Server 2005 makes life much easier to deal with these challenges.
This assertion comes from the Visual FoxPro environment, where developers can navigate through result sets (VFP cursors…not to be confused with SQL Server Cursors) at the record level, very quickly and easily. No question, VFP is a great database tool. So great in fact, that some have used it for so long, and to solve so many problems, that it's easy to conclude that VFP's offerings are the only optimal hammer in the toolbox for certain operations.
SQL Server 2005 conforms more closely to the ANSI-99 SQL spec – and some of the features of the ANSI-99 standard making querying more flexible than before. One such feature is Common Table Expressions and recursive querying of hierarchical data. I'm going to devote some blog entries over the next few weeks to recursive querying, as I believe developers regularly face this challenge.
I'm going to start with a very simple example, to demonstrate the mechanics of recursive querying in SQL 2005. First, here's a simple set of hierarchical data – a product hierarchy with Brands, Groups, and Items. Each row contains a unique integer identifier, a description, and a reference to the row's parent:
DECLARE @tProducts TABLE (ID int, Name char(50), ParentID int)
INSERT INTO @tProducts VALUES (1, 'Brand 1', null)
INSERT INTO @tProducts VALUES (2, 'Brand 2', null)
INSERT INTO @tProducts VALUES (3, 'Brand 3', null)
INSERT INTO @tProducts VALUES (6, 'Brand 1, Group 1', 1)
INSERT INTO @tProducts VALUES (7, 'Brand 1, Group 2', 1)
INSERT INTO @tProducts VALUES (8, 'Brand 1, Group 3', 1)
INSERT INTO @tProducts VALUES ( 9, 'Brand 2, Group 1', 2)
INSERT INTO @tProducts VALUES (10, 'Brand 2, Group 2', 2)
INSERT INTO @tProducts VALUES ( 11, 'Brand 3, Group 3', 3)
INSERT INTO @tProducts VALUES (12, 'Brand 1, Group 1, Item 1', 6)
INSERT INTO @tProducts VALUES (13, 'Brand 1, Group 1, Item 2', 6)
INSERT INTO @tProducts
VALUES (14, 'Brand 1, Group 1, Item 1, SKU 1', 12)
Here's the challenge: for any specific item in this table, I want to know all the child records, going all the way down the hierarchy. Think about how you'd handle this query in SQL 2000 using SQL statements. While it was doable, querying hierarchical data was never an easy task. Fortunately, SQL 2005 makes this much simpler. Here's the entire query, which sets a search string, and then retrieves all the child records for that search string:
DECLARE @cSearch char(50)
SET @cSearch = 'Brand 1, Group 1'
; WITH ProductCTE AS
-- Anchor query
(SELECT ID, Name, ParentID
FROM @tProducts
WHERE Name = @cSearch
UNION ALL
-- Recursive query
SELECT Prod.ID, Prod.Name, Prod.ParentID
FROM @tProducts Prod
INNER JOIN ProductCTE
ON ProductCTE.ID = Prod.parentID )
SELECT * FROM ProductCTE
I'll confess, when I first looked at CTE and recursive query syntax, I felt pretty stupid that I couldn't grasp it. So, I took an online example, completely changed the sample data, built my own example, and then I didn't feel quite so stupid. ;)
Here's the deal/trick with recursive queries - in a "normal" SQL SELECT statement, you're querying from a table that isn't changing during the lifetime of the query (OK, data could be inserted from another session, but that's a different topic). You're querying directly FROM one table, and into a totally separate result set.
In a recursive query, some of the data you need to query is actually a result of a prior phase of the query. So results become the source for future results. Think about this with respect to our simple example, where we want all the children of a particular row – we can't pull the lowest level (SKU) without pulling the level above that (Item), and we can't do that without pulling the level above that (Group) and so on.
So let's take a look at the anatomy of the query, which has three parts. The first part is defining the Common Table Expression…
; WITH ProductCTE AS
As I said in my last blog post, a CTE is like a temporary derived table or view, with a very short lifespan. What we're going to do in the next two steps is query into ProductCTE for the search string, and then continue to query all the way down the hierarchy by comparing IDs to ParentIDs.
The second part is called the main or anchor query:
(SELECT ID, Name, ParentID
FROM @tProducts
WHERE Name = @cSearch
The anchor query executes first, so we know that ProductCTE will contain the ID, Name, and ParentID for the single row that matches the search condition.
The final part is the actual recursive query, which is connected to the anchor query with a UNION ALL:
UNION ALL
-- Recursive query
SELECT Prod.ID, Prod.Name, Prod.ParentID
FROM @tProducts Prod
INNER JOIN ProductCTE
ON ProductCTE.ID = Prod.ParentID )
Note that the anchor query is performing a join between the original list of products and the ProductCTE. So each "hit" between an ID and a ParentID will go into ProductCTE, and the query will continue until no more matches are found.
OK, so that handles querying DOWNWARD….suppose we wanted to find all the parent rows instead? Just switch the column names on the INNER JOIN in the recursive query:
ON ProductCTE.ParentID = Prod.ID )
If you're wondering about any limit to the number of recursions, the default is 100, which can be configured: check out MAXRECURSION in the online help if you ever have a hierarchy with more than 100 levels. (I'm almost afraid to see a hierarchy with that many levels!)
See, that wasn't so bad? There are many examples of hierarchical data out there, such as Bill of Material data, organization chart data, etc. Anyone who has ever worked with e-commerce applications is likely VERY familiar with the challenges of hierarchical data. SQL Server 2005 makes life much easier to deal with these challenges.
SQl Server Managment
Recently I came accross are really painfull problem of 'msdb label SUSPECT by the recovery'.
The reasons for msdb marked 'SUSPECT' is unrecognizable. But after it, I am unable to access msdb database, which i found out is the backbone for all server related queries. If this happens, you are left with no choice but to restore the DB, but first off all Do you have the backup of msdb database ?
advice : aways take backup of msdb database as soon as you install the sql server.
usefull article : http://searchsqlserver.techtarget.com/tip/0,289483,sid87_gci1052507,00.html
With SQL Server 2005, there is default remote connections disabled.
use Microsoft SQL Server 2005 -> Configuration Tools -> Surface Area Configuration
To give alias name to an existing Database (which in my project was a limitation; should be local)
use Microsoft SQL Server 2005 -> Configuration Tools -> Configuration Manager (Native CLient Configuration)
Prefer to use authentication as 'windows and sql mode'.
--To do this Right-Click Server on the Managment studio and goto properties
--Select Security and choose desiired authentication.
The reasons for msdb marked 'SUSPECT' is unrecognizable. But after it, I am unable to access msdb database, which i found out is the backbone for all server related queries. If this happens, you are left with no choice but to restore the DB, but first off all Do you have the backup of msdb database ?
advice : aways take backup of msdb database as soon as you install the sql server.
usefull article : http://searchsqlserver.techtarget.com/tip/0,289483,sid87_gci1052507,00.html
With SQL Server 2005, there is default remote connections disabled.
use Microsoft SQL Server 2005 -> Configuration Tools -> Surface Area Configuration
To give alias name to an existing Database (which in my project was a limitation; should be local)
use Microsoft SQL Server 2005 -> Configuration Tools -> Configuration Manager (Native CLient Configuration)
Prefer to use authentication as 'windows and sql mode'.
--To do this Right-Click Server on the Managment studio and goto properties
--Select Security and choose desiired authentication.
Subscribe to:
Posts (Atom)
