Tài liệu Programming Microsoft SQL Server 2000 with Microsoft Visual Basic .Net - P5 doc

using t he OPENROWSET funct ion because t he linked server sy nt ax is m or e
st raight forward, and you no longer have t o perform the first t wo st eps.
Creat e a link ed server for a rem ot e or het erogeneous data source w it h t he
sp_addlinkedserv er sy st em st ored procedure. This procedure can take as m any
as seven argum ent s, but you can use as few as t wo argum ent s for cr eat ing a
reference t o a rem ot e SQL Server source and as few as four argum ent s for a
linked server point ing t o an Access data source. Aft er correctly init ializing t he
linked server reference wit h t he sp_addlink edserver sy st em st ored procedure,
invoke sp_addlink edsrv login for m apping logins on t he curr ent SQL Ser ver 2000
inst ance t o logins for t he rem ot e or het erogeneous dat a source. When a user runs
a query on t he local server against t he link ed ser ver, t he local server logs in t o
the linked server w it h the credent ials specified w hen t he sp_addlink edsrv login
syst em st ored procedure was last run for t he link ed server. You can invok e t he
sp_linkedservers syst em st ored pr ocedur e t o it em ize in a result set t he linked
servers defined on a local server .
Secur it y for Vir t ua l Direct ories
Virt ual direct ories ar e necessary for Web dat a access t o SQL Serv er dat a sources
via XML. Each dat abase t hat requires Web access via XML m ust have a virtual
dir ect ory point ing t o it . As described in t he “Virt ual Direct ory Managem ent ”
sect ion of Chapt er 6 , y ou m ust designat e a login for t he virt ual direct ory. All
access t o t he dat abase is m apped through t he login t hat you specify on t he
Security tab of t he Propert ies dialog for a direct ory.
Figure 7-1 sh ows the Propert ies dialog box used for t he MyNwind v irt ual direct ory
that ser ved as t he source for m ost of t he sam ples in Chapt er 6. Not ice that t he
Security tab specifies I USR_CCS1 in t he User Nam e t ext box. The User Nam e t ext
box cont ains t he login nam e for t he v irt ual dir ect ory. Select ing Windows as t he
Account Type aut om at ically inst alls I USR_servernam e as t he login. Windows 2000
Ser ver aut om at ically inst alls t he I USR_ser vernam e user account . I I S
aut om at ically uses t his Windows user account for anonym ous login. Since t he
sam ples for Chapt er 6 ran fr om a server nam ed ccs1, t he dialog replaced
servernam e w it h CCS1.

Figu re 7 - 1 . Use th e Secur it y t ab for a vir t ual dire ct ory t o specify t he login
by w hich u ser s of th e v irt ua l dire ct or y w ill gain access t o a SQL Se rve r.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

I f you decide t o allow access t o your dat abase t hrough t he I USR_servernam e
Windows account , you m ust m anually creat e a login for t he Windows user on
your SQL Server inst ance. Then you m ust creat e a user secu rity account in t he
dat abase t o which t he v irt ual direct ory point s. Finally y ou m ust assign
perm issions t o t he I USR_serv ernam e securit y account appropriat e t o t he needs of
your applicat ion. For exam ple, if you w ant to enable browsers t o r ead from any
row source in t he dat abase, y ou can assign t he I USR_servernam e user account t o
the db_dat areader fix ed dat abase role. I f you have m ore rest rict ive requirem ent s,
use t he T- SQL GRANT st at em ent t o specify m ore granular perm issions, such as
the abilit y t o view j ust one t able or view. Make sure t he dat abase has perm issions
for t he public role t hat don’t allow the I USR_ser vernam e account t o access the
dat abase w it h a differ ent set of perm issions than t he one you specify explicit ly for
the virt ual dir ect or y user account .
When you decide t o per m it updat es, inserts, and delet es t o a database t hr ough a
virt ual ser ver, t he user securit y account for t he virt ual direct ory’s login m ust
enable t hese act ions. My advice is t o carefully rest rict t he row sources t hat you
m ake available for updat ing over t he Web. Av oid assigning t he I USR_ser vernam e
account t o the db_dataw rit er fixed dat abase role. I nst ead, assign I NSERT,
UPDATE, or DELETE perm issions wit h t he T- SQL GRANT st at em ent for whichever
dat abase obj ect s require m odificat ion over t he Web.


Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Sam ples for Logins and Users
Login and user securit y accounts com plem ent one anot her. Recall t hat a login
aut horizes access to a server, but a user account grant s access t o a database on

a serv er. The users of your applicat ions t ypically need both t ypes of securit y
account s t o access a dat abase on a SQL Server inst ance. I n addit ion, ther e are
two dist inct t ypes of logins. The sam ples in t his sect ion explore t he different kinds
of logins for SQL Server and how t hey relat e t o user secur ity account s. All t he
script s in this sect ion are in the LoginAndDropUsers.sq l sam ple file.
Add a SQL Server Login a nd Use r
Recall t hat a login get s a user int o a server but not necessarily int o any databases
on t he serv er. This is because a login t ypically requires a m at ching securit y
account for each dat abase t o which a user is t o have access. How ever, t her e are
two w ays in w hich a user can access a dat abase w it hout a user account for t he
dat abase. First , t he dat abase can have a guest account . The user w ill t hen enj oy
any perm issions assigned explicit ly t o t he guest account or indirect ly t o t he guest
account t hrough perm issions for a dat abase’s public role. Second, if a login is a
m em ber of t he sysadm in fixed server role, it can access any dat abase on a server
wit hout any rest rict ions on it s funct ionalit y. For t his reason, you want to lim it t he
num ber of logins w it h m em bership in t he sysadm in role. I f y ou need t o carefully
specify how t he user of a login can int eract wit h a dat abase, you m ust creat e a
user securit y account for t he login in t he dat abase.
I nvoke t he sp_addlogin sy st em st ored procedure to cr eat e a new SQL Server
login. Wit h t he sp_addlogin syst em stored procedur e, you can create a login t hat
SQL Server m anages. When users at t em pt t o gain access to a SQL Serv er
inst ance wit h t his login, t hey m ust explicit ly designat e bot h t he login nam e and
it s associated password. To cr eat e a SQL Server login, y ou m ust be a m em ber of
either the sysadm in or securit yadm in fixed server role. An y user can ch ange her
own passw ord w it h t he sp_password syst em st ored procedure. Only m em bers of
the sysadm in and securityadm in fixed serv er roles can invoke sp_password t o
change t he password for a login different fr om t heir own.
N ot e
While a SQL Server login enables a user to connect to a SQL
Server inst ance by specifying a login nam e and password, it

is the SI D ( securit y ident ifier) that SQL Server uses t o
identify and track t he user. SQL Server internally generat es a
GUI D t o r epresent t he SI D for SQL Server logins.
I nvoke t he sp_grant dbaccess syst em stored procedure t o cr eate a user securit y
account in a dat abase for a login. Only m em bers of t he sy sadm in fixed server role
as well as the db_owner and db_accessadm in fixed dat abase roles can run
sp_grant dbaccess. Before running sp_grant dbaccess, m ake su re t he database
cont ext is set t o t he dat abase in which you want to create a user security
account . For exam ple, inv oke t he USE st atem ent for a dat abase nam e before
running sp _grant dbaccess.
The following T- SQL scr ipt uses sp_addlogin t o cr eat e a new SQL Server login. I t
is m andat or y to specify t he @loginam e and @passw d argum ent s for t he
sp_addlogin syst em st ored procedure. You can opt ionally specify sever al ot her
argum ent s t o change the default set t ings deriv ed from your SQL Server
configurat ion. For exam ple, t he script dem onst rat es t he syntax for designat ing a
default database of Chapt er07, t he sam ple dat abase for t his chapt er. I f t he script
didn’t m ake t his assignm ent for t he @defdb argum ent , t he default dat abase
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
would have been t he m aster database. The m ast er dat abase is one of t he built - in
dat abases t hat SQL Ser ver uses t o adm inist er it self. While all users require access
to t his database, you probably don’t want to m ake it t he default database for
typical users.
Not ice t hat t he scr ipt explicit ly refer ences t he m ast er dat abase before invok ing
sp_addlogin. This reference isn’t st rict ly necessary since you can cr eat e a login
securit y account from any database on a server. How ever, t he sam ple script
invokes t he USE st at em ent t wo m ore t im es, and t hese t wo r eferences are
necessary. You m ust invok e t he USE st atem ent before running t he
sp_grant dbaccess syst em st ored pr ocedur e. Recall t hat t his syst em st ored
procedure cr eat es a user secu rit y account . Set t ing t he database cont ext before
invoking sp_grantdbaccess det erm ines the dat abase for w hich t he system st ored

procedure cr eat es a user secu rit y account .
--LoginAndDropUsers
--Create a SQL Server login with access
--to the Chapter07 and Northwind databases.
USE master
EXEC sp_addlogin
@loginame = ’vbdotnet1’,
@passwd= ’passvbdotnet1’,
@defdb = ’Chapter07’
USE Chapter07
EXEC sp_grantdbaccess ’vbdotnet1’
USE Northwind
EXEC sp_grantdbaccess ’vbdotnet1’

The vbdot net 1 login doesn’t st rict ly requir e a user securit y account for t he
Nort hwind dat abase because t his sam ple dat abase has a guest account , and t he
public role for t he database grant s perm issions t o all dat abase obj ect s in t he
init ial version of t he database. However, cr eat ing a user account for t he
vbdotnet 1 login allows y ou t o rem ove t he guest account for the database and st ill
m aintain dat a access privileges. I n addit ion, a user account for t he vbdot net 1
login enables a database designer t o fine- t une t he perm issions available t o t he
login relat iv e t o ot her dat abase users.
Rem ove a SQL Se r ver Login and User
I n t he norm al course of database m anagem ent , it becom es necessary t o rem ove
as well as add dat abase users. Since a SQL Server dat abase user has t wo
different secu rit y account t ypes, you m ust rem ove bot h t o flush a user com plet ely
from a dat abase serv er. To prev ent orphaned user account s, SQL Ser ver doesn’t
allow you t o delet e t he login for a user w it hout delet ing the user account s
associat ed wit h t hat login. Rem oving t he user account s without elim inat ing t heir
login st ill allows a user t o access a database server, and t he login can access any

dat abases wit h a guest account .
N ot e
I n addition to being unable to rem ove a login wit h one or
m ore associat ed user accounts, y ou cannot rem ove a login
that is current ly in use, owns a database, or owns a job in
the m sdb database. A job is a sequence of st eps for
aut om at ing a task that is defined in t he m sdb database, one
of t he built - in databases t hat SQL Server uses to m anage
it self. As m ent ioned prev iously, you can nev er rem ove t he sa
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
login from a SQL Server inst ance.
Before you at t em pt t o rem ove a login, it ’s useful t o survey any associat ed user
securit y accounts associat ed wit h the login. Th is perm it s y ou to m ak e sur e t hat
you can rem ove all of the user security account s associat ed wit h a login before
at t em pt ing to rem ove t he login. I nvoke t he sp_helplogins syst em st ored
procedure wit h t he nam e of t he login for which you’re seeking inform at ion, as
show n in t he follow ing code. The syst em st or ed procedure ret urns a r esult set
com prising t wo recordsets. The first recordset cont ains a single row for t he login
that y ou specify. The second recordset cont ains a row for each user account
associat ed wit h t he login nam ed as t he argum ent for t he sp_helplogins sy st em
st ored procedure. I f you don’t specify a login nam e as an argum ent w hen you
invoke sp_helplogins, t he sy st em st ored procedure still r eturns t wo recordset s.
However, t hese recordsets ret urn inform at ion for all t he logins on t he current SQL
Ser ver inst ance.
--Return info about a login, including
--its database user accounts.
EXEC sp_helplogins @LoginNamePattern=‘vbdotnet1’

Figure 7-2 sh ows the tw o recordset s t hat resu lt from running sp _helplogins
vbdotnet 1 aft er first inv oking t he scr ipt in t he preceding sect ion. The first

recordset st art s wit h t he login nam e followed by a part ial display of t he login’s
SI D. The next t wo colum ns indicat e t he default dat abase and language for t he
login. The next -t o-last colum n, AUser, is yes when t he login has at least one
corresp onding user account . The last colum n, ARem ot e, indicat es whet her t he
login specifies a r em ot e login for a linked server. The second recordset provides
inform at ion about each user account for t he login. The first and third colum ns
denot e, respect ively, t he login nam e and t he user nam e. By default , t hese are t he
sam e, but you can override t his convent ion. The second colum n designat es the
dat abase t o which t he user account belongs. The last colum n specifies whet her
the user account is for an individual user or a role.
Figu re 7 - 2 . Use t h e sp_ h elplogin s syst em store d pr oced ur e t o le arn about
a log in on a da t aba se ser ver .

Arm ed w it h t he inform at ion in Figure 7- 2, you can const ruct a T- SQL script like
the follow ing to rem ove t he vbdotnet 1 security account s from t he serv er. St art by
invoking t he sp_revokedbaccess syst em st ored procedure in each dat abase wit h a
user account for the vbdot net 1 login. Specify t he user account nam e as t he
argum ent for t he sp_revokedbaccess syst em st or ed procedure. Notice t hat t he
script inv okes sp_revokedbaccess twice— once in each dat abase for which t he
vbdotnet 1 login has a user account . The scr ipt closes by r unning t he sp_droplogin
syst em st ored procedure. This syst em st ored procedure requires j ust one
argum ent specifying t he nam e of t he login t o r em ove. The perm issions for
rem oving user accounts and logins m at ch t hose for adding t hem : a login
at t em pt ing to rem ove a login m ust be a m em ber of t he sy sadm in or
securit yadm in fix ed server role t o run sp_droplogin.
--Drop a SQL Server login,
--first revoking its user accounts.
USE Northwind
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
EXEC sp_revokedbaccess ’vbdotnet1’

USE Chapter07
EXEC sp_revokedbaccess ’vbdotnet1’
EXEC sp_droplogin @loginame = ’vbdotnet1’

Adding and Rem oving Logins for a W indow s User
Managing a login based on a Windows user account for Windows NT, Windows
2000, or Windows XP is sim ilar t o m anaging a SQL Server login. By a Windows
user account , I m ean t he account by w hich Windows validat es a user. From a
user perspect ive, t he m ain difference is t hat a login based on a Windows user
account doesn’t hav e t o specify a login and passw ord when connect ing to a SQL
Ser ver inst ance. For a dat abase user wit h a login based on a Windows user
account , all a user has t o do is select the Windows Aut hent icat ion opt ion in t he
Connect To SQL Server dialog box of Qu ery Analyzer. I f t he t arget SQL Server
inst ance has a login for t he Window s user account , t he connect ion at tem pt
succeeds. Howev er, a m em ber of t he sy sadm in group m ust first creat e a login for
the Windows account in order for t he att em pt to succeed.
The process for cr eat ing login and user secur it y account s based on a Windows
user account is sim ilar t o that for m anaging SQL Server logins. When cr eat ing a
login for a Windows user account , invoke t he sp_grant login syst em st ored
procedure t o cr eat e a login for t he Windows user. When you designat e a login
nam e for a Windows user account , t he nam e m ust hav e t wo parts delim it ed by a
backslash ( \ ) . The part before t he backslash is the nam e of t he Windows server.
The part aft er t he backslash is t he nam e of t he Windows user.
The sp_grant login syst em st ored procedur e is analogous t o t he sp_addlogin
syst em st ored procedure. Bot h of t hese sy st em st ored procedures cr eat e a new
login. SQL Server saves bot h of t he logins in t he sy slogins t able. SQL Ser ver also
reports bot h t ypes of logins in t he sam e colum n of t he resu lt set from the
sp_helplogins syst em st ored procedure. How ever, t he login creat ed w it h
sp_grant login is aut hent icat ed by a Windows 2000 or Windows NT server. When a
Windows user at tem pt s t o connect , SQL Server stores t he Windows secur it y

ident ifier for t he Windows user . The Windows secu rit y ident ifier is analogous t o
the SQL Server SI D. However, t he Windows securit y ident ifier is m anaged by t he
Windows server, and t he Windows securit y ident ifier is longer than t he SQL
Ser ver SI D ( 85 byt es for Window s and 16 byt es for SQL Ser ver) .
Aft er you cr eat e a login for a Windows user account , t he login cannot connect t o
any dat abase wit hout a user secur ity account unless t he dat abase has a guest
account . You can cr eat e a user securit y account for a login based on a Window s
user account wit h t he ident ical procedure for a SQL Server login. First set t he
dat abase cont ext for t he user securit y account . For exam ple, invoke t he USE
st atem ent t o specify t he nam e of t he dat abase for which you want t o creat e a
user account . Second run sp_grant dbaccess w it h t he nam e of the login as it s
argum ent .
The following sh ort script dem onst rates t he synt ax for cr eat ing a login based on a
Windows user account . The Windows user account resides on a Windows 2000
Ser ver nam ed CCS1. The nam e of t he account on t he Window s serv er is
winvbdot net 1. The last t wo lines of t he script cr eat e a user secur it y account in t he
Chapt er07 dat abase based on t he login cr eat ed w it h sp_grant login.
--Create a Windows login with
--access to Chapter07 database.
EXEC sp_grantlogin ’CCS1\winvbdotnet1’
USE Chapter07
EXEC sp_grantdbaccess ’CCS1\winvbdotnet1’

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
N ot e
I f t he Windows user account is for a Window s serv er that
isn’t a dom ain server but m erely an applicat ion server , you
m ust cr eate a local account on a Windows NT Workst at ion or
Windows 2000 Professional client com puter wit h t he sam e
nam e and password as on t he Windows server.

Rem oving t he login is a t wo-st ep process because t he login has a single user
securit y account associated wit h it . First rem ove t he user account for t he
Chapt er07 dat abase. The syst em st ored procedur e for elim inat ing a user securit y
account based on a login for a Windows user account is t he sam e as for delet ing a
user account based on a SQL Server login. Second revok e t he login. When
dropping a login, you use a different sy st em st ored procedure for one based on a
Windows user account t han for one creat ed by SQL Server. Here is t he T- SQL
code for im plem ent ing t he st eps.
--Drop a Windows login with sp_revokelogin,
--but first revoke its user accounts.
USE Chapter07
EXEC sp_revokedbaccess ’CCS1\winvbdotnet1’
EXEC sp_revokelogin ’CCS1\winvbdotnet1’

W ho’s Using Your Application?
By now, you should feel com fort able wit h t he idea t hat there
are act ually t wo reasonable answer s t o t his quest ion. The first
answ er is t he login nam e. This nam e ident ifies a user as she
ent ers a SQL Serv er inst ance. The second answ er is t he nam e
of t he user securit y account. This ident ifies a user wit hin a
dat abase. I f a login doesn’t have a user security account
assigned explicit ly t o it for a database and the dat abase has a
guest account, t he login can enter t he dat abase with t he guest
user account.
SQL Server 2000 offers two built- in funct ions for telling you
the login nam e and user account nam e of the user perform ing
a task in your dat abase. The SYSTEM_USER funct ion ret urns
the login nam e. The CURRENT_USER funct ion ret urns t he user
account nam e. Before discussing a list ing t o clarify the
operat ion of t hese funct ions, I want t o m ent ion t he DB_NAME

funct ion. When you enter DB_NAME() in a SELECT st at em ent ,
it returns the nam e of the current dat abase.
The following short script invokes the SYSTEM_USER and
CURRENT_USER funct ions in t hree different databases—
m ast er, Nor t hwind, and Chapt er07. I f you run t his script aft er
connect ing t o a SQL Server inst ance wit h the
CCS1\ winvbdot net1 login, you obt ain an ident ical result set
from each SELECT st at em ent. However, two differ ent values
are displayed for t he CURRENT_USER funct ion. I n the m aster
and Northw ind dat abases, t he CURRENT_USER funct ion
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
ret urns guest . I n the Chapt er07 database, the
CURRENT_USER funct ion returns CCS1\ winvbdot net 1. This is
because the login has a user account nam ed aft er it in t he
Chapt er07 database.
--
Demonstrate functions telling who’s using a database.
USE master
SELECT DB_NAME(), SYSTEM_USER, CURRENT_USER
USE Northwind
SELECT DB_NAME(), SYSTEM_USER, CURRENT_USER
USE Chapter07
SELECT DB_NAME(), SYSTEM_USER, CURRENT_USER

Proce ssing Logins Based on W in dow s Gr oups
I n addit ion t o basing a login on an indiv idual Windows user account , you can also
creat e a login for a Window s group account . The latt er t y pe of Windows account
provides a single nam e for referencing m ore t han one individual Windows
account . When you cr eat e a login based on a Window s group, all the individual
m em bers of t he group inher it t he login assigned t o t he gr oup. I n addit ion, you

can creat e separat e logins for a subset of t he indiv idual m em bers of a Windows
group. These logins for individual Windows account s com plem ent t he login based
on t he Window s group account by providing an alt er nat ive rout e int o a SQL
Ser ver inst ance and t he dat abases on it .
The sam ple for t his sect ion works w it h a Windows group nam ed w invbdot net. The
group cont ains t wo individual Windows user account s nam ed winvbdot net 1 and
winvbdot net 2. All t he account s reside on a CCS1 Windows 2000 server. The
following T- SQL scr ipt shows t he code for creat ing dist inct logins for t he Windows
group and t he indiv idual Window s account s t hat belong t o t he Windows group.
Aft er t he ex ecut ion of t he scr ipt , both t he w invbdot net 1 and w invbdot net 2 users
connect t o t he SQL Serv er inst ance w ith t heir own logins as well as t he login for
the Windows group. I n addition, bot h individual Windows user account s hav e
their own user accounts in t he Chapt er07 database, and t he Windows user
account s m ap t o the Chapt er07 user account for t he Window s group.
--Create login for winvbdotnet Windows group.
EXEC sp_grantlogin ’CCS1\winvbdotnet’
USE Chapter07
EXEC sp_grantdbaccess ’CCS1\winvbdotnet’

--Also create logins for group members individually.
EXEC sp_grantlogin ’CCS1\winvbdotnet1’
EXEC sp_grantdbaccess ’CCS1\winvbdotnet1’
EXEC sp_grantlogin ’CCS1\winvbdotnet2’
EXEC sp_grantdbaccess ’CCS1\winvbdotnet2’
GO

Ther e are act ually t wo ways to m ak e a login unavailable for use. First , you can
run t he sp_revokelogin syst em st ored procedur e as dem onst rated in t he
preceding sect ion. This approach rem oves t he login for t he Window s user from
the database server. Wit h t his approach in t he current cont ext , rev oking t he

CCS1\ w invbdot net 1 Windows user login st ill perm it s the winvbdot net 1 Windows
m em ber of t he w invbdotnet group to connect t o the dat abase serv er. Th is
capabilit y is possible because the Windows user can access the dat abase serv er
thr ough t he login for t he w invbdot net Windows group.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
The following script shows the sy nt ax for a second appr oach. I t denies login
perm ission t o an exist ing login— in t his case, t he one for t he w invbdot net1
Windows user. This approach st ill perm its t he winvbdot net2 Windows user t o
access t he dat abase ser ver. However, by denying t he login perm ission for the
CCS1\ w invbdot net 1 login, t he scr ipt overrides t he abilit y of t he w invbdot net 1
Windows user t o access t he dat abase server t hr ough t he CCS1\ w invbdot net login.
--This does not affect winvbdotnet2,
--which is a member in winvbdotnet group.
EXEC sp_denylogin ’CCS1\winvbdotnet1’
GO

The following one- line scr ipt blocks the winvbdot net2 Windows user from
accessing t he dat abase server. The logins for t he winvbdot net 1 and w invbdot net 2
Windows users are still on t he dat abase server. I n addit ion, t he
CCS1\ w invbdot net login st ill aut hor izes its m em bers to log in t o the server. A
deny set t ing (inst it ut ed by the sp_denylogin syst em st ored procedure) for t he
individual Window s accounts over rides t he access grant ed by t he sp_grant login
syst em st ored procedure for t he CCS1\ winvbdot net Windows group account . This
general rule is t rue for all perm issions. A deny sett ing overr ides a grant set t ing.
--This does affect winvbdotnet2,
--which is a member in winvbdotnet group.
EXEC sp_denylogin ’CCS1\winvbdotnet2’
GO

To rem ov e t he logins for t he individual Window s users and t he Window s group to

which t he users belong, you sh ould revoke t he dat abase access t o t he user
securit y accounts cor responding t o logins. Then you can r evok e t he specific logins
for t he Windows users and Window s group. The follow ing scr ipt shows t he sy nt ax
for accom plish ing t hese t asks. While t he sp_denylogin syst em st ored procedure
disables a login from accessing a server , t his sy st em st ored procedure doesn’t
rem ove t he login from a SQL Server inst ance— instead, you need t he
sp_revokelogin sy st em st ored procedure t o accom plish t he t ask.
--Cleanup account settings.
USE Chapter07
EXEC sp_revokedbaccess ’CCS1\winvbdotnet’
EXEC sp_revokedbaccess ’CCS1\winvbdotnet1’
EXEC sp_revokedbaccess ’CCS1\winvbdotnet2’
EXEC sp_revokelogin ’CCS1\winvbdotnet’
EXEC sp_revokelogin ’CCS1\winvbdotnet1’
EXEC sp_revokelogin ’CCS1\winvbdotnet2’
GO


Sam ples for Assigning Perm issions
This sect ion dem onst rat es t he essent ial T- SQL st atem ent s for organizing
perm issions w it hin a dat abase. Specific t echniques exist for obj ect and st at em ent
perm issions. I n addit ion, the final t opic in t he section rev eals how to m anage
perm issions w hen a user account can possess a perm ission direct ly as well as
indirectly t hrough it s m em bership in one or m ore Windows account s or SQL
Ser ver roles.
The sam ples in t his sect ion rely on a v ersion of t he Em ailCont act s table. The
“Script ing Tables” section of Chapt er 2 init ially present ed the T- SQL code for t his
table. For t he purposes of t his ch apt er, you can re-cr eat e this table in t he
Chapt er07 dat abase sim ply by changing the references t o t he Chapt er02
dat abase in Chapt er 2 t o t he Chapt er07 dat abase. A copy of t he m odified code

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
exist s in t he sam ple file Creat eEm ailCont act sTable.sql for your easy r eference.
This sect ion also r elies on t he ex ist ence of t he four logins wit h their m at ching
user securit y accounts creat ed so far in t his chapter. Recall that one login is a
SQL Server login ( vbdot net 1), anot her t wo are Windows user logins
(CCS1\ winvbdot net 1 and CCS1 \ winvbdot net 2), and a fourth login is a Window s
group login ( CCS1\ w invbdot net) com prising each of t he tw o Windows user
account s. This sect ion presents t he T- SQL code for assigning perm issions t o t he
user account s for t he logins. The perm issions relat e t o t he Em ailContacts t able.
Ther efore, cr eat e t he Em ailCont act s table wit h a m em ber of the sysadm in fixed
server role, such as t he Windows Adm inist rat or user account or t he SQL Server
sa login.
Sele ct , I nse r t , a nd Delet e Perm issions for a Ta ble
To evaluat e the effect of perm ission assignm ent s, you w ill need t w o concurrent
act ive connect ions t o your dat abase server. Connect once as a m em ber of t he
sysadm in fixed serv er role, and connect a second t im e with a SQL Ser ver login—
nam ely, vbdot net 1. Not e t hat if you ran t he code sh ow n ear lier t o drop t he
vbdotnet 1 login account , you’ll need t o rerun t he code that creat es t he account .
To confirm t hat the user account for t he vbdot net1 login has no perm issions in
the Chapt er07 dat abase, at t em pt t o r un t he following script wit h t he user account
for t he login. Not ice t hat t he at t em pt ret urns an error m essage say ing, in effect ,
that SELECT perm ission is denied on t he Em ailCont act s obj ect in t he Chapt er07
dat abase.
--SelectInsertDeletePermission
--The SELECT succeeds if the user has
--SELECT permission.
USE Chapter07
SELECT * FROM EmailContacts

To rem edy t he er ror condit ion, you need t o assign SELECT perm ission for t he

Em ailCont acts t able to t he vbdot net1 user account . Fr om your session init iat ed by
a sysadm in m em ber, run t he following line of T- SQL. You m ust invoke t his line of
code from y our session for t he sy sadm in role m em ber. You can also alw ays
assign perm issions from a session w it h any m em ber of t he db_owner fixed
dat abase roles. Sessions for select ed other user account s w ill w ork in sp ecial
circum st ances; see t he “GRANT” t opic in Books Online for det ails. Recall also that
m em bers of t he sy sadm in role have perm ission t o perform all t asks on a
dat abase serv er.
--Assign SELECT permission for the EmailContacts
--table to the vbdotnet1 user account.
GRANT SELECT ON EmailContacts TO vbdotnet1

Not ice t hat you can assign a SELECT perm ission wit h t he GRANT T- SQL
st atem ent. The sam ple in t he preceding T- SQL st at em ent uses the SELECT
keyword. This k eyword denotes t he perm ission t o r un a SELECT st atem ent , such
as t he sam ple t o select all colum ns for all rows from the Em ailCont act s t able. You
can opt ionally assign I NSERT, UPDATE, DELETE, and REFERENCES per m issions
for a t able. When concurrent ly assigning m ore t han one perm ission, delim it t he
it em s in your list of perm issions with com m as. Aft er t he perm issions, use t he
keyword ON and t hen specify the row source, which is the Em ailCont act s t able in
this dem onst rat ion. Conclude t he GRANT st atem ent w it h the TO keyword followed
by t he account t o w hich you are grant ing perm ission. The preceding GRANT
st atem ent designat es t he user security account for t he vbdot net 1 login. You can
alternat ively sp ecify a SQL Server role for one or m ore user account s or t he user
securit y accounts for a Windows user or a Windows gr oup account .
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Aft er invoking t he preceding GRANT st at em ent , t he session for the vbdotnet 1
user can ex ecut e a SELECT stat em ent against t he Em ailCont act s table. However,
the follow ing at t em pt s from t he vbdot net 1 connect ion t o insert a row and t hen
delet e the row fail wit h a pair of error m essages about denied I NSERT and

DELETE perm issions. Again, t he problem is t hat t he vbdot net 1 user doesn’t have
t he proper perm issions.
--Run from Chapter07 database context for vbdotnet1 user.
INSERT INTO EmailContacts
VALUES(3,’Tony’, ’Hill’, ’’)
SELECT * FROM EmailContacts
GO

DELETE
FROM EmailContacts
WHERE Email1 = ’’
SELECT * FROM EmailContacts
GO

Running t he follow ing stat em ent from t he sy sadm in session enables t he
vbdotnet 1 user account wit h t he proper perm issions t o ex ecut e t he preceding
script . Notice t hat t he sy nt ax for adding m ult iple perm issions is t he sam e as for
adding a single perm ission except t hat you delim it perm issions wit h a com m a.
The following st at em ent adds I NSERT and DELETE perm issions t o t he existing
SELECT perm ission for t he vbdot net 1 user account .
--Delimit more than one permission in a GRANT
--statement by using a comma.
GRANT INSERT, DELETE ON EmailContacts TO vbdotnet1

You can drop all perm issions for t he vbdot net 1 user account by r evoking or
denying t hem . When you are work ing w it h an indiv idual user account t hat doesn’t
belong t o any role, you can eit her revoke or deny exist ing perm issions for t he
account . Use t he REVOKE st at em ent w it h t he ALL key word t o rem ove any exist ing
perm issions from a user account . The follow ing one- line script dem onst rat es t he
syntax for dropping t he SELECT, I NSERT, and DELETE perm issions from

vbdotnet 1.
--Use the ALL keyword to concurrently
--drop all existing permissions.
REVOKE ALL ON EmailContacts TO vbdotnet1

Perm ission t o Cr ea t e a Ta ble
When you assign t he perm ission t o creat e a t able to user account s for any login
not in t he sysadm in fixed server role, you com plicat e how an applicat ion m ust
refer t o t ables. This is because all m em bers of t he sysadm in fixed serv er r ole are
the dbo user. This dbo user belongs to all databases. You cannot drop t he dbo
user from a dat abase— j ust as no one can drop t he sa login from an inst ance of
SQL Server. The rules for referencing tables cr eated by t he dbo user are different
than t hose for tables cr eat ed by any ot her dat abase user.
Ever y user can refer im plicit ly t o t ables cr eat ed by the dbo user . When the
sam ples in the preceding sect ion referenced Em ailCont acts, t hey im plicit ly
referred t o dbo.Em ailCont act s because t he table was cr eat ed by a m em ber of t he
sysadm in fixed serv er role. SQL Server requires you t o explicit ly refer t o t ables
creat ed by other users.
When a user w ho doesn’t qualify as a dbo user cr eates a t able, ot her users can
refer t o t he t able by t he nam e of t he t able’s owner and t he t able’s nam e. For
exam ple, if vbdot net 1, who isn’t a dbo user, creat es a t able nam ed Em ailContact s
in t he Chapt er07 dat abase, ot her users m ust r efer to t he t able as
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
vbdotnet 1.Em ailCont act s. The vbdot net1 user can refer t o t he Em ailCont act s
table that it cr eat ed as eit her vbdot net 1.Em ailCont act s or j ust Em ailCont act s.
However, if t hat user want s t o reference the dbo Em ailCont act s table, he m ust
specify dbo.Em ailCont act s. I f any ot her user, w ho didn’t herself cr eate a t able
nam ed Em ailCont acts, refers to a t able wit h Em ailContact s, SQL Server
aut om at ically int erpret s t his as a r eference t o dbo.Em ailCont act s.
N ot e

When you perm it non- dbo users to creat e tables, a best
pract ice is always to use t he owner qualifier when referring
to a t able. I f a dbo user creat es a table nam ed
Em ailContact s, refer t o it as dbo.Em ailCont act s. I f a non- dbo
user, such as v bdotnet1, cr eates a table nam ed
Em ailContact s, refer t o it as vbdot net1.Em ailContact s.
Because users who write t heir own T- SQL st at em ents can
deviat e from t hese rules and t he rules lengt hen T- SQL
st at em ents in any event , rest rict the perm ission t o cr eat e
tables t o t he dbo user if at all possible.
The following line of scr ipt shows t he sy nt ax for enabling t he vbdot net 1 user t o
creat e a table. Set t he dat abase cont ext if it isn ’t already set to the database for
which you want t o grant the perm ission. Not ice t hat the sy nt ax for grant ing
perm ission t o execu te a st atem ent is slight ly different t han for an obj ect
perm ission. Aft er t he GRANT k eyword, y ou list the st atem ent for which you are
grant ing perm ission, but ther e’s no need t o follow t his st at em ent wit h t he ON
keyword. I n addit ion t o CREATE TABLE, y ou can reference CREATE DATABASE,
CREATE VI EW, CREATE PROCEDURE, CREATE FUNCTI ON, and select ed ot her
st atem ents. ( See t he “GRANT” t opic in Books Online for the com plet e list .) As
wit h grant ing obj ect perm issions, you can use a com m a delim it er when
concu rrent ly grant ing perm ission for m ore t han one st at em ent . Close t he GRANT
st atem ent wit h t he TO k eyword followed by t he nam e of t he account that is to
receive t he st at em ent perm ission.
--PermissionToCreateATable
--Set the database context before invoking.
GRANT CREATE TABLE TO vbdotnet1

Aft er execut ing t he preceding GRANT st at em ent , t he vbdot net 1 user can cr eat e a
table, such as one nam ed Em ailContact s. Because vbdot net 1 ow ns
vbdotnet 1.Em ailCont act s, it can aut om at ically insert and delete r ows fr om t he

table— j ust like m em bers of t he sysadm in fixed server role and t he db_owner
fixed database role. However , ow ning an obj ect doesn ’t aut om at ically convey
m em bersh ip in any r ole. Since the vbdot net 1 login isn ’t a m em ber of t he
sysadm in fixed dat abase role, t he vbdot net 1 user cannot be a dbo user. The
following script show s t he code for cr eat ing t he vbdot net 1.Em ailCont act s table.
Running t he script from the session connect ion based on t he vbdot net 1 login
m akes t he vbdot net 1 user the table’s owner.
--Invoke the DROP TABLE statement if the EmailContacts
--table already exists for the vbdotnet1 user.
CREATE TABLE EmailContacts
(
ContactID int Not Null PRIMARY KEY,
FirstName nvarchar(20) NULL,
LastName nvarchar(35) NULL,
Email1 nvarchar (255) NULL
)

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
List ing t he t ables from t he sysadm in session now shows t wo t ables w it h t he nam e
Em ailCont acts. Use t he following scr ipt t o display the list of t ables w it h
Em ailCont acts as t heir nam e locat ed in t he Chapt er07 dat abase. Figure 7-3 sh ows
the resu lt set from t he script . One r ow in t he result set is for t he dbo user, and
the ot her is for t he vbdot net 1 user.
--List the EmailContacts tables after creating
--a second one with the vbdotnet1 user.
USE Chapter07
SELECT *
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME = ’EmailContacts’

Figur e 7 - 3 . Th e Table_ Schem a colu m n in th e r esu lt se t from t he
I NFORMATI ON _ SCH EM A.TABLES vie w den ot e s a t able ow n er ’s u ser
n a m e.

N ot e
You cannot drop a user and it s corr esponding login if t he
user owns an obj ect , such as a t able, in a database. I f t he
object s for a user are no longer required, sim ply drop them
and then drop the user and its login. If you requir e the
object s that are owned by a user who m ust be dropped,
inv oke t he sp_changeobj ect owner sy st em st ored procedure
to t ransfer obj ect ownership t o a user who will rem ain in t he
dat abase. Then dr op t he user and login.
You can add row s t o and delet e row s from t he vbdotnet 1.Em ailCont act s t able wit h
a script such as t he follow ing. Because t he scr ipt references t he t able wit h it s
owner qualifier, you can run t he script from any connect ion based on a login wit h
a user having perm ission t o select , insert , and delet e r ows from the t able— for
exam ple, t he dbo user or t he vbdotnet 1 user. The script generat es a resu lt set
wit h t hree r ecordset s. The first recordset is em pt y because t he preceding script
creat ing t he t able doesn’t insert any rows. The second r ecordset shows t he new
row for Tony Hill. The t hird row sh ow s t he table em pt y again aft er t he delet ion of
t he row for Tony Hill.
--Run from Chapter07 database context.
SELECT * FROM vbdotnet1.EmailContacts
INSERT INTO vbdotnet1.EmailContacts
VALUES(3,’Tony’, ’Hill’, ’’)
SELECT * FROM vbdotnet1.EmailContacts

DELETE
FROM vbdotnet1.EmailContacts

WHERE Email1 = ’’
SELECT * FROM vbdotnet1.EmailContacts

W indow s Users and Gr ou ps
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Windows users t hat are part of Windows group account s in SQL Serv er creat e
special challenges for sett ing securit y. This is because an individual Windows user
account can derive its perm ission for a t ask fr om m ult iple sources. Even if you
revok e a perm ission fr om t he user account for a Windows user, the Windows user
m ay st ill be able to perform t he t ask cont rolled by t he perm ission. This can
happen because t he user account for a Windows group, t o which a Windows user
belongs, grant s t he sam e perm ission r evoked for the individual Window s user
account . I n fact , this sam e scenar io applies to SQL Server user- defined roles. A
SQL Server account can belong t o m ult iple roles and have perm issions applied
dir ect ly t o it . Revoking one perm ission m ay not fully close all t he rout es by which
a SQL Server user account can derive perm ission t o perform t he t ask.
N ot e
When work ing with a Windows user account t hat can belong
to a Windows group or a SQL Server user account t hat can
belong to one or m or e user- defined roles, consider using a
DENY st at em ent t o rem ov e a perm ission. This st at em ent
block s t he perm ission t o perform a t ask even if the account
is grant ed perm ission for t he task by virtue of it s
m em bership in another Windows gr oup or SQL Server role.
The sp_helprot ect syst em st ored procedure helps you m onitor t he perm ission
assignm ents for user accounts. By default , sp_helpr ot ect ret ur ns a result set wit h
the obj ect and stat em ent perm issions for all t he user account s in all dat abases on
a database server. You can filt er the resu lt set by specifying select ed argum ents.
For exam ple, designat ing a dat abase in t he @nam e argum ent ret urns t he
perm issions for j ust that database. You can also filt er by t ype of perm ission

(obj ect or st at em ent ) , by account t o whom a perm ission is granted, and by w ho
grant ed t he perm ission. I f you assign filt ers so t hat t he result set from
sp_helprot ect is em pt y, t he pr ocedur e ret urns an error m essage for t he condit ion.
The following script t rack s t he assignm ent of perm issions in t he Chapt er07
dat abase. Before t he execut ion of any GRANT st at em ent in t he script , a dat abase
connect ion t o t he Chapt er07 dat abase t hat is based on t he login for
CCS1\ w invbdot net 1 cannot perform a SELECT stat em ent on t he
dbo.Em ailCont act s t able. Aft er t he first set of GRANT st at em ent s, t he
CCS1\ w invbdot net 1 user account can perform a SELECT st at em ent based on t wo
dist inct perm issions. One perm ission is grant ed direct ly t o t he user in the second
GRANT st at em ent . The other perm ission is grant ed t o t he user account t hrough
the CCS1\ winvbdot net Window s gr oup because CCS1\ winvbdot net 1 is a m em ber
of t his Windows group. The inv ocat ion of t he sp_helprot ect sy st em st ored
procedure aft er t he first three GRANT st at em ent s confirm s t hese tw o perm issions
and one m ore for t he CCS1 \ w invbdot net 2 Windows user account .
The next T- SQL st at em ent in t he script revokes t he SELECT perm ission for t he
dbo.Em ailCont act s t able for t he CCS1\ winvbdot net1 Windows user. This rem oves
the perm ission from t he collect ion of perm issions in t he dat abase. The execut ion
of sp_helprotect in t he next st at em ent confirm s t hat t he perm ission is m issing.
However, rem ov ing t he perm ission doesn’t block t he CCS1\ winvbdot net 1
Windows user from perform ing a SELECT st at em ent w it h t he dbo.Em ailCont acts
table as it s source. This is because the CCS1 \ winvbdot net 1 Windows user der ives
SELECT perm ission for t he t able from it s m em bership in t he CCS1\ w invbdot net
Windows group.
Revoking SELECT perm ission for t he CCS1\ w invbdot net Windows group account
in t he dat abase w ill block the CCS1 \ winvbdotnet 1 Windows user from perform ing
a SELECT st at em ent on the Em ailContact s t able. However, t his act ion w ill also
rem ove SELECT perm ission for t he CCS1 \ winvbdotnet 2 Windows user. The script
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
inst ead invokes a DENY st at em ent for SELECT perm ission on t he

dbo.Em ailCont act s t able for t he CCS1\ winvbdot net1 user account . This st at em ent
rest rict s j ust t he abilit y of t he CCS1\ winvbdot net 1 Windows user t o perform a
SELECT st at em ent wit h Em ailCont act s as t he source. Any ot her user in the
CCS1\ w invbdot net Windows group st ill r etains perm ission for a SELECT st at em ent
against t he dbo. Em ailCont act s table. The final execut ion of sp_helprot ect rev eals
an explicit perm ission denying t he CCS1\ winvbdot net 1 user account from
perform ing a SELECT st atem ent on t he dbo.Em ailCont act s table.
--DenyPermission
--Before granting SELECT permissions, SELECT statements from
--either CCS1\winvbdotnet1 or CCS1\winvbdotnet2 were denied.

--Grant SELECT permission for dbo.EmailContacts for
--a Windows group and its two individual Windows accounts.
GRANT SELECT ON dbo.EmailContacts TO [CCS1\winvbdotnet]
GRANT SELECT ON dbo.EmailContacts TO [CCS1\winvbdotnet1]
GRANT SELECT ON dbo.EmailContacts TO [CCS1\winvbdotnet2]

EXEC sp_helprotect @name=‘dbo.EmailContacts’

--After granting SELECT permission, SELECT statements from
--either CCS1\winvbdotnet1 or CCS1\winvbdotnet2 were granted.

--Revoke SELECT permission for dbo.EmailContacts
--for CCS1\winvbdotnet1.
REVOKE SELECT ON dbo.EmailContacts TO [CCS1\winvbdotnet1]

EXEC sp_helprotect @name=‘dbo.EmailContacts’

--After revoking SELECT permission for CCS1\winvbdotnet1, the
--account could still perform a SELECT statement for EmailContacts.

--Deny SELECT permission for dbo.EmailContacts
--for CCS1\winvbdotnet1.
DENY SELECT ON dbo.EmailContacts TO [CCS1\winvbdotnet1]

EXEC sp_helprotect @name=‘dbo.EmailContacts’

--Denying SELECT permission makes it impossible
--for CCS1\winvbdotnet1 to SELECT from EmailContacts.

--Clean up permission assignments.
REVOKE SELECT ON dbo.EmailContacts TO [CCS1\winvbdotnet]
REVOKE SELECT ON dbo.EmailContacts TO [CCS1\winvbdotnet1]
REVOKE SELECT ON dbo.EmailContacts TO [CCS1\winvbdotnet2]


Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Chapt er 8 . Overview of t he .N ET
Fram ew ork
This book is aim ed at professional developers w ho have an int erest in
program m ing SQL Server 2000 w it h Visual Basic .NET. Up t o t his point , t he
book’s focus was pr im arily on SQL Server. I believ e t hat you cannot opt im ally
program SQL Server in any language w it hout a firm underst anding of it s basic
work ings. Chapt ers 2 t hrough 7 provide a foundat ion in SQL Server t hat will serve
you especially well for dat a access and m anipulat ion t ask s, as w ell as relat ed dat a
definit ion t ask s.
Chapt er 1 int roduces you t o beginning Visual Basic .NET and ADO.NET t echniques
so t hat you have som e cont ext for underst anding how t o apply t he SQL Serv er
2000 topics present ed in Chapt ers 2 t hrough 7 . This chapt er builds on t he init ial
exposure t o t echnologies for t he .NET Fram ew ork t hat appears in Chapt er 1. I f

you j um ped t o t his chapt er wit hout any prior exposur e t o the .NET Fram ework,
now is a great t im e to look over Chapt er 1. To take m axim um advant age of Visual
Basic .NET for cr eating SQL Server solut ions, you need t his background. Chapter
1 st arts to convey t his background, and this chapter finishes t he t ask so you are
ready t o dig int o t he .NET Fram ew ork code sam ples t hr oughout t he rest of the
book.
Visual Basic .NET is one of t he core pr ogram m ing languages for t he .NET
Fram ew ork, which Microsoft defines as “a new com put ing plat form designed t o
sim plify applicat ion dev elopm ent in t he highly dist ribut ed environm ent of t he
I nt er net .” Micr osoft is t aking a w hole new init iative wit h t he .NET Fram ework t hat
radically redefines how businesses can program and deploy solut ions as well as
access resources over corporat e intranet s or t he I nt ernet . I n m any present at ions
on t he bet a versions, it was popular t o hear t hat Micr osoft was bet ting it s
business on t he .NET Fr am ework. Whether or not this is precisely t rue, it is clear
that Micr osoft has invest ed heav ily in prov iding a com prehensiv e new st ruct ure
for building solut ions, and t he firm has changed in a m aj or way its m ost popular
program m ing language— Visual Basic. The scope and m agnit ude of t he changes
provide Visual Basic dat abase developers wit h challenges and opportunities.
This chapt er at t em pt s t o fam iliarize y ou w it h t he archit ect ure of t he .NET
Fram ew ork and relat ed t echnologies, including ASP.NET and XML Web serv ices.
See Chapt er 1 for int roduct ory m aterial on Visual Basic .NET and ADO.NET. My
goal in t his chapt er isn’t t o em pow er y ou as a program m er wit h t hese
technologies. I nst ead, I aim t o show how t he t echnologies com plem ent one
anot her. I n t he process, I feel you will dev elop an appreciat ion of why it is
im port ant for you t o adopt t he .NET Fram ework and st art program m ing it w it h
Visual Basic .NET. This book’s rem aining chapt ers exam ine t he program m ing y ou
use for t he t opics int roduced concept ually in t his chapt er and Chapt er 1. This
chapt er cont ains a program m ing sam ple, but I put it there j ust for reference
purposes. This chapt er is about concept s— not code. ADO.NET, ASP.NET, and XML
Web serv ices each are cover ed in a separat e chapt er that drills down into

techniques for dev eloping solut ions wit h t hem . Plus, there’s anot her chapter—
Chapt er 12— on m anaging XML wit h Visual Basic .NET.


An I nt roduct ion t o t he .NET Fram ew ork
This sect ion int roduces you t o core .NET Fram ewor k concepts. I t st arts w it h an
ov erview of t he .NET Fram ew ork archit ect ure. Next it m oves on t o what ’s new
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
about source code com pilation. This is a nat ural ent ry point t o discussing how you
m anage t he refer encing of solut ions by clients and how to deploy solut ions. The
sect ion closes w it h brief looks at selected .NET Fram ework feat ures t hat build on
m aterial covered earlier in t he sect ion and are im port ant t o how you will use .NET
Fram ew ork solut ions.
.N ET Fr am e w or k Archit ect u r e
Perhaps the m ost dom inant archit ect ural elem ent of the .NET Fram ework is it s
com m on language runt im e. The runt im e sits on top of t he operat ing sy st em .
Program m ers write t o t he r untim e in any com pliant language. The runt im e
event ually writes w hat is called m anaged code t o t he specific operat ing sy st em on
which it r uns. As I wr it e t his chapt er, t he operat ing system s t hat support the
com m on language runt im e include t hose based on t he 32-bit versions of
Windows, including Windows 98, Windows Millennium , Windows NT, Windows
2000, and Window s XP. Micr osoft has a Window s .NET Server operat ing sy st em in
bet a t hat likely will include t he .NET Fram ework. I n addit ion, you can ex pect t he
runt im e t o pr oduce code suit able for t he fort hcom ing 64- bit version of Windows.
While t he com m on language r untim e r uns on top of Windows syst em s, one of t he
great st rengths of runt im e-com pliant solut ions is their int eroperabilit y wit h ot her
operat ing sy st em s. This follows from r unt im e support for XML and XML Web
services. The core t echnologies for XML and XML Web services rely on
indust rywide st andards. Because ot her vendors are endorsing t hese st andards
along wit h Microsoft , y ou can be assured of a level of int er operabilit y for t he

solut ions t hat you cr eat e w it h the runt im e. I f vendors follow t hrough on t heir
endorsem ent s for t he st andards and you build your solut ions w it h code m anaged
by t he runt im e, you can achiev e levels of int eroperability acr oss operat ing
syst em s not previously enj oyed by application developers.
N ot e
Learn m ore about XML in Chapter 6 and Chapt er 12. XML
Web services is t he t opic of the closing sect ion in t his chapter
as well as the whole of Chapt er 1 3 .
When you develop solut ions for SQL Server, you will benefit from t he fact that t he
com m on language runt im e can be host ed by SQL Server 7 and lat er v ersions and
Micr osoft I nt er net I nform ation Services v ersions 4.0 and lat er; I I S is t he
Micr osoft Web server for Windows NT and Windows 2000. This gives you a chance
to int egrat e t ightly your dat abase and Web solut ions w it h t he m anaged code
generat ed by the runt im e. For exam ple, t he .NET Fram ework sh ips w ith m anaged
providers for SQL Ser ver and OLE DB dat a sources. The SQL Server provider
offers subst ant ial perform ance advantages because of it s opt im izat ion for SQL
Ser ver 7 and SQL Serv er 2000. I n addit ion, ASP.NET is a part of t he .NET
Fram ew ork t hat I I S host s. ASP.NET is t he next generation of dev elopm ent
techniques for t hose creat ing solut ions wit h ASP now. I n order for ASP.NET pages
to r un, t hey m ust be com piled by t he r unt im e. ASP.NET is an int egral part of I I S
4, j ust as I I S 3 host s the ASP obj ect m odel. I n addit ion, ASP.NET can int eract
wit h SQL Server t hrough t he .NET Fram ework dat a prov iders. ( See Chapt er 11.)
Figure 8-1 sh ows a sim plified schem at ic of the pat h from source code in Visual
Basic .NET ( or anot her runt im e- com pliant language) t hrough t o interact ions wit h
SQL Server and browser s on a Web. The com m on language runt im e t ranslat es
the source code t o m anaged code. This m anaged code can, in turn, int eract wit h
the Windows operat ing sy st em , SQL Server , and browsers. Wit h t he aid of a
m anaged provider, such as t he one for SQL Serv er, your solut ions can access and
m anipulat e dat a. You can use t he ASP.NET com ponent of t he .NET Fram ew ork to
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

creat e ASP.NET pages t hat reside on an I I S server. These pages can serv e
dynam ic elem ent s t o br owsers on a Web. I n addit ion, t he pages can offer t he
browsers t he opport unit y t o access and m anipulat e dat a on a SQL Ser ver.
Figu re 8 - 1 . A sch em a tic illustr at ing th e r ole of t h e com m on langu age
ru nt im e and it s m an ag ed code in in te ract ing w ith t he W ind ow s oper at in g
syst e m , SQL Ser ve r , a nd I I S.

Com piling Source Code
The .NET Fram ework support s m ult iple program m ing languages in a com m on
way. I n addit ion t o Visual Basic .NET, Visual St udio .NET support s the preparat ion
of source code in ot her languages, such as C# and Visual C+ + . Web developers
who are used t o building solut ions in JScript w ill appreciat e t he fact t hat they can
creat e ASP.NET solut ions wit h JScript .NET. I n fact, t hese dev elopers can use
JScr ipt .NET to im plem ent solut ions acr oss the full range of .NET Fram ework
capabilit ies because JScript .NET is runt im e- com pliant . I n addit ion, t hird- part y
vendors are readying ot her languages for runt im e com pliance. This proliferat ion
of languages will offer developers a wide range of options in which t hey can
program t he .NET Fram ework.
N ot e
JScript .NET is an extension of the Micr osoft JScript
language, which was based on ECMAScript ( ECMA- 262) .
ECMA is the European Com puter Manufact urers Associat ion.
JScript .NET is ex plicitly developed for use w it h the runt im e.
Since JScript .NET generally follows the ECMAScript
conventions, it offers a st andards- based rout e to cr eating
.NET Fram ework solut ions with a popular script ing language
am ong Web developers.
A wonderful t hing about t he .NET Fram ework is that all languages can have t he
sam e capabilit ies if t hey are fully r unt im e-com pliant . For exam ple, Visual Basic
.NET has t he sam e capabilit ies as C# (and so does JScr ipt .NET) . I n addit ion,

developers in one language can freely use obj ect s creat ed by developer s in ot her
languages. Th is cross- language funct ionalit y wasn’t always easy t o im plem ent
before t he .NET Fram ew ork because of slight incom pat ibilit ies in source code
language com pilat ion pr ocessing. The .NET Fram ework act ually readies source
code for execut ion t hrough a series of t w o com pilat ions. The first com pilat ion
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
conv erts t he source code t o Microsoft I nt erm ediat e Language ( MSI L). The second
com pilation converts MSI L t o CPU- specific code for t he com put er running t he
code.
The first com pilat ion from source code to MSI L generates a represent at ion of your
program t hat capt ures its program m ing inst ruct ions and m et adat a about t he
program . The com pilat ion st or es it s out put in a port able execut ion ( PE) file. MSI L
is a language- independent way of expressing your program m ing logic. The
m et adat a describes t he t ypes t hat your code cr eat es as w ell as t heir m em bers,
such as m et hods, propert ies, and event s. A t ype is an elem ent , such as a class.
Anot her im port ant m et adat a elem ent is the descript ion of t he assem bly for an
application. An assem bly is t he unit for st oring a solut ion in t he .NET Fram ework.
The assem bly descript ion in t he m et adat a includes an ident ity specificat ion for t he
assem bly, export ed t ypes, referenced t ypes, and secur it y perm issions needed t o
run. A reference t o a t ype is like a reference t o a class in a t ype library. Because
the m et adat a for an assem bly includes int ernal t ypes and ext ernally r efer enced
types, there is no need for r eferences t o t ype libraries in Visual Basic .NET and
ot her runt im e- com pliant languages.
The second com pilat ion from MSI L t o m achine code readies your code for
execu tion on a specific processor. The .NET Fram ework can accom plish t his w it h a
Just -I n- Tim e (JI T) com piler. JI T com pilers are specific t o each support ed CPU
archit ect ure. JI T com pilat ion com piles the cont ent s of t he PE file as a user
references it s elem ent s during a session. PE file elem ent s, such as a t ype
m em ber, aren’t com piled unt il a user references t hem . Aft er t he init ial
com pilation, t he runt im e aut om at ically refers t o t he com piled version, t hus

reducing t he t im e t o execu te t he code. This pr ocess also saves com pilat ion t im e
by not com piling those elem ent s that a user doesn’t reference during a session.
Unless an adm inist rator explicit ly designat es ot herw ise, the com pilat ion t o
m achine code exam ines t he MSI L and it s m et adat a t o det erm ine whet her it is
type safe. The t erm t ype safe r efers t o t he fact t hat a t ype accesses only m em ory
locat ions for which it has access perm ission. Th is securit y check allow s t he .NET
Fram ew ork t o enforce secur it y r est rict ions.
Assem blies a nd Ma nifests
Assem blies and t heir m anifest s are an excit ing innovat ion int roduced w it h t he
.NET Fr am ework. They are excit ing because t hey can clear ly elim inat e m any
opportunit ies for .dll conflict s— popularly referred t o as “dll hell.” A .dll conflict can
em erge when a user inst alls a new applicat ion t hat wr it es over an exist ing .dll file
wit h a new version that isn’t fully backward com pat ible. I f anot her, previously
inst alled, applicat ion relies on a t ype m em ber t hat is changed or elim inated in t he
new .dll, t he pr eviously inst alled applicat ion w ill fail. Assem blies and m anifests
offer a couple of workarounds t o t his problem for solut ions based on COM
com ponent s.
A .NET Fram ework solut ion ex ist s as an assem bly of one or m ore files. These files
can include t he MSI L as w ell as ot her resources, such as im age files or ot her
docum ent files t hat a solut ion references. An assem bly m ust include a m anifest ,
which cont ains m et adat a about the assem bly. Th is m et adat a describes t he files in
the assem bly . I n t he case of a single- file assem bly, t he m anifest resides wit hin
the solut ion’s .dll file, but ot herwise an assem bly’s m anifest resides in a separate
file. A solut ion’s assem bly can consist of up t o four t ypes of elem ents.
• The assem bly’s m anifest
• The MSI L code for the solut ion
• The t ype m etadat a for t he MSI L code
• Resource files required by t he solut ion
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
The assem bly is the deploym ent unit for solut ions in t he .NET Fram ew ork.

Because all t he elem ent s for a solut ion can exist wit hin a single assem bly , you
can deploy a solut ion by dist ribut ing t he solut ion’s assem bly of files. St ore t he
assem bly as a direct ory or subdirect ory on a t arget workst at ion. The com m on
language r unt im e m ust be inst alled on t he workst at ion in order t o transform the
MSI L t o nat ive m achine code. This approach is part icu larly convenient w here a
solut ion perform s t asks that you don’t care t o share wit h ot her solutions.
Som e solut ions are ut ilit ies. When t hese utility solut ions are likely t o be a part of
m any ot her solut ions, you can st ore t he ut ilit y solut ions in t he Global Assem bly
Cache (GAC) . There is one GAC per com put er. When you place an assem bly in
the GAC for sharing by one or m ore ot her solut ions, t he sh ared assem bly in t he
GAC m ust have a st rong nam e. The st r ong nam e uniquely ident ifies an assem bly
in t he GAC t o avoid conflict s from t wo assem blies t hat m ay have t he sam e t ext
for a nam e. Visual St udio .NET includes t ools to sim plify t he cr eat ion of st rong
nam es t hat are based on t he t ext for an assem bly’s nam e, it s version num ber,
cult ur e inform at ion, public key, and a digit al signat ure.
The .NET Fram ework SDK discourages locating assem blies in the GAC unless
essent ial because it can com plicate deploym ent and adm inist ration. For exam ple,
deploying a solut ion can r equire copy ing t wo direct or ies— one for t he m ain
assem bly and t he ot her for the shared assem bly in the GAC. I n addit ion, t he GAC
resides in the system direct ory. Th is direct ory often has rest rict ed access. These
access rest rict ions m ay necessitat e perm issions for copying an assem bly to t he
GAC t hat the user inst alling an applicat ion doesn’t hav e.
De ploy a Solut ion—X COPY a Folde r
You can create .NET Fram ew ork solutions for Windows that
are totally self- contained in a single folder. When y ou cr eat e
a .NET Fr am ework solution using t he Windows Applicat ion
tem plate, Visual St udio .NET by default cr eates a folder for
your solution in t he last direct or y in which you saved a
previous solution. This folder has a root folder and at least
two subfolders— bin and obj. You can st ore the resour ces for

your solutions, such as cust om classes, im age files, and XML
schem a files, anywhere you need in t he root folder ( or even
outside the root ) . The advant age of st oring all files for a
solut ion in t he root folder, or any of its subfolders, is that
you can t hen deploy y our solut ion wit h an XCOPY com m and,
or any equiv alent technique, t hat copies t he solution’s folder.
All t he Visu al Basic .NET solut ions included in this book’s
sam ple files are available as folders that you can copy to
your com puter. I f you copy t hem t o a m achine with the
proper configurat ion— for exam ple, one wit h t he com m on
language runtim e— y ou can run t he solutions from the folder
to w hich y ou copy them .
While I am talk ing about solut ion folders, it is probably worth
m ent ioning a couple of special files w it hin a solution folder .
The solut ion’s .exe file resides in the bin subfolder . You can
launch the solut ion by inv oking t his file. By default, t he .exe
file has t he sam e nam e as the solut ion. Therefore, if your
solut ion has the nam e WindowsApplicat ion1, t he .exe file for
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.