Microsoft Sharepoint Products and Technologies Resource Kit eBook

972 Part IX: Maintaining a Server in Windows SharePoint Services
By default, Windows SharePoint Services databases use Windows Authentication
for security reasons. Therefore, you should log in to the system as WSSASPTester to
open the SQL Server database, although you can do this from any account that has
access to the Windows SharePoint Services database we created (for example,
Administrator, sa, and so on).
1. Open the SQL Server Query Analyzer by clicking Start, pointing to All Programs,
selecting Microsoft SQL Server, and clicking Query Analyzer.
2. In the Connect To SQL Server dialog box, enter your server instance name. (By
default, for Windows SharePoint Services this is \SHAREPOINT.) In
our example, our server is S2003E, so the server name would be entered as:
s2003e\SHAREPOINT.
3. If you are using WSSASPTester or Administrator, select Windows Authentication.
If you are using a SQL Server account, such as sa, you need to click SQL
Server authentication and enter the Login name and password.
4. Click OK to log in to the database, and open Query Analyzer.
5. On the very top menu bar, there is a drop-down list that indicates the database
you are currently accessing. If you logged in as WSSASPTester, this should
already be pointing to Contoso1. If anything else is shown, such as “master,”
use the drop-down list to locate and select Contoso1. In the Query window,
enter the following select statement:
SELECT tp_ID FROM Lists WHERE tp_Title LIKE '%Problem/Solutions%'
Entering this information should return a single row in the Query Results
window. The GUID for the list is the column named tp_ID. (Note that the
GUID does not have curly braces in the database.)
Note If you do not find the row using the query just shown, the list might
have used the Default Title, General Discussions. If this is the case, substitute
General Discussions for Problem/Solutions in the select statement
and try again.
Use Visual Studio to Create a New ASP.NET Page
In our example, our goal is to display the same data from the Web Part in the Windows
SharePoint Services site, OurNewSharePointSite, in the ASP.NET application
site, OurNewASPNETSite, with as little difficulty and required maintenance as possible.
Basically, we’re going for a “set it and forget it” arrangement because we don’t
want to have to change code or make changes if the data changes.
To do this, we have several options that include using a custom object you create
to instantiate a cloned Web Part within the ASP.NET site. However, these methods are