Beginning Microsoft SQL Server 2008 ... - S3 Tech Training
Beginning Microsoft SQL Server 2008 ... - S3 Tech Training Beginning Microsoft SQL Server 2008 ... - S3 Tech Training
Chapter 12: Stored Procedures 408 feed or stock quote), even though the structure and complex communications required would have ruled out such a function in prior versions. Without going into too much detail on them for now, let’s look at the syntax for adding an assembly to your database: CREATE ASSEMBLY AUTHORIZATION FROM WITH PERMISSION_SET = [SAFE | EXTERNAL_ACCESS | UNSAFE] The CREATE ASSEMBLY part of things works as pretty much all our CREATE statements have — it indicates the type of object being created and the object name. Then comes the AUTHORIZATION — this allows you to set a context that the assembly is always to run under. That is, if it has tables it needs to access, how you set the user or rolename in AUTHORIZATION will determine whether it can access those tables or not. After that, we go to the FROM clause. This is essentially the path to your assembly, along with the manifest for that assembly. Finally, we have WITH PERMISSION_SET. This has three options: ❑ SAFE: This one is, at the risk of sounding obvious, well . . . safe. It restricts the assembly from accessing anything that is external to SQL Server. Things like files or the network are not available to the assembly. ❑ EXTERNAL_ACCESS: This allows external access, such as to files or the network, but requires that the assembly still run as managed code. ❑ UNSAFE: This one is, at the risk of again sounding obvious, unsafe. It allows your assembly not only to access external system objects, but also to run unmanaged code. I cannot stress enough the risks you are taking when running .NET assemblies in anything other than SAFE mode. Even in EXTERNAL_ACCESS mode you are allowing the users of your system to access your network, files, or other external resources in what is essentially an aliased mode — that is, they may be able to get at things that you would rather they not get at, and they will be aliased on your network to whatever your SQL Server login is while they are making those accesses. Be very, very careful with this stuff. .NET assemblies will be discussed extensively in Professional SQL Server 2008 Programming.
Summary Wow! That’s a lot to have to take in for one chapter. Still, this is among the most important chapters in the book in terms of being able to function as a developer in SQL Server. Sprocs are the backbone of code in SQL Server. We can create reusable code and get improved performance and flexibility at the same time. We can use a variety of programming constructs that you might be familiar with from other languages, but sprocs aren’t meant for everything. Pros to sprocs include: ❑ Usually better performance ❑ Possible use as a security insulation layer (control how a database is accessed and updated) ❑ Reusable code ❑ Compartmentalization of code (can encapsulate business logic) ❑ Flexible execution depending on dynamics established at runtime Cons to sprocs include: Chapter 12: Stored Procedures ❑ Not portable across platforms (Oracle, for example, has a completely different kind of implementation of sprocs) ❑ May get locked into the wrong execution plan in some circumstances (actually hurting performance) Sprocs are not the solution to everything, but they are still the cornerstones of SQL Server programming. In the next chapter, we’ll take a look at the sprocs’ very closely related cousin — the UDF. 409
- Page 395 and 396: 3 8 More Than One Apart 2 2 Ends Wi
- Page 397 and 398: Now, I don’t know about you, but
- Page 399 and 400: The WAITFOR statement does exactly
- Page 401 and 402: IF @ErrorNo = 2714 -- Object exists
- Page 403: Chapter 11: Writing Scripts and Bat
- Page 406 and 407: Chapter 12: Stored Procedures Creat
- Page 408 and 409: Chapter 12: Stored Procedures Dropp
- Page 410 and 411: Chapter 12: Stored Procedures Suppl
- Page 412 and 413: Chapter 12: Stored Procedures 374 [
- Page 414 and 415: Chapter 12: Stored Procedures Confi
- Page 416 and 417: Chapter 12: Stored Procedures Now,
- Page 418 and 419: Chapter 12: Stored Procedures SQL S
- Page 420 and 421: Chapter 12: Stored Procedures 382 c
- Page 422 and 423: Chapter 12: Stored Procedures It wo
- Page 424 and 425: Chapter 12: Stored Procedures 386 r
- Page 426 and 427: Chapter 12: Stored Procedures 388 -
- Page 428 and 429: Chapter 12: Stored Procedures Note
- Page 430 and 431: Chapter 12: Stored Procedures 392 n
- Page 432 and 433: Chapter 12: Stored Procedures All t
- Page 434 and 435: Chapter 12: Stored Procedures Sproc
- Page 436 and 437: Chapter 12: Stored Procedures When
- Page 438 and 439: Chapter 12: Stored Procedures 400 @
- Page 440 and 441: Chapter 12: Stored Procedures I’d
- Page 442 and 443: Chapter 12: Stored Procedures match
- Page 444 and 445: Chapter 12: Stored Procedures There
- Page 449 and 450: 13 User-Defined Functions Well, her
- Page 451 and 452: types!), except for BLOBs, cursors,
- Page 453 and 454: We get back the same set as with th
- Page 455 and 456: AS RETURN (SELECT BusinessEntityID,
- Page 457 and 458: in your relational database. These
- Page 459 and 460: AS BEGIN ( EmployeeID int NOT NULL,
- Page 461 and 462: So, as you can see, we can actually
- Page 463 and 464: Despite being schema-bound, this on
- Page 465 and 466: 14 Transactions and Locks This is o
- Page 467 and 468: we are unable or do not want to com
- Page 469 and 470: Figure 14-1 Data needed Data in cac
- Page 471 and 472: Transaction 4 This transaction wasn
- Page 473 and 474: Oops — problem!!! Transaction 2 h
- Page 475 and 476: The only cure for this is setting y
- Page 477 and 478: Exclusive Locks Exclusive locks are
- Page 479 and 480: Also: ❑ The Sch-S is compatible w
- Page 481 and 482: The syntax for switching between th
- Page 483 and 484: As with most things in life, howeve
- Page 485 and 486: purchased. Process 2 records sales;
- Page 487: Chapter 14: Transactions and Locks
- Page 490 and 491: Chapter 15: Triggers the world’s
- Page 492 and 493: Chapter 15: Triggers WITH ENCRYPTIO
- Page 494 and 495: Chapter 15: Triggers FOR|AFTER The
Chapter 12: Stored Procedures<br />
408<br />
feed or stock quote), even though the structure and complex communications required would have<br />
ruled out such a function in prior versions.<br />
Without going into too much detail on them for now, let’s look at the syntax for adding an assembly to<br />
your database:<br />
CREATE ASSEMBLY AUTHORIZATION FROM <br />
WITH PERMISSION_SET = [SAFE | EXTERNAL_ACCESS | UNSAFE]<br />
The CREATE ASSEMBLY part of things works as pretty much all our CREATE statements have — it indicates<br />
the type of object being created and the object name.<br />
Then comes the AUTHORIZATION — this allows you to set a context that the assembly is always to run<br />
under. That is, if it has tables it needs to access, how you set the user or rolename in AUTHORIZATION<br />
will determine whether it can access those tables or not.<br />
After that, we go to the FROM clause. This is essentially the path to your assembly, along with the manifest<br />
for that assembly.<br />
Finally, we have WITH PERMISSION_SET. This has three options:<br />
❑ SAFE: This one is, at the risk of sounding obvious, well . . . safe. It restricts the assembly from<br />
accessing anything that is external to <strong>SQL</strong> <strong>Server</strong>. Things like files or the network are not available<br />
to the assembly.<br />
❑ EXTERNAL_ACCESS: This allows external access, such as to files or the network, but requires<br />
that the assembly still run as managed code.<br />
❑ UNSAFE: This one is, at the risk of again sounding obvious, unsafe. It allows your assembly not<br />
only to access external system objects, but also to run unmanaged code.<br />
I cannot stress enough the risks you are taking when running .NET assemblies in<br />
anything other than SAFE mode. Even in EXTERNAL_ACCESS mode you are allowing<br />
the users of your system to access your network, files, or other external resources in<br />
what is essentially an aliased mode — that is, they may be able to get at things that<br />
you would rather they not get at, and they will be aliased on your network to whatever<br />
your <strong>SQL</strong> <strong>Server</strong> login is while they are making those accesses. Be very, very<br />
careful with this stuff.<br />
.NET assemblies will be discussed extensively in Professional <strong>SQL</strong> <strong>Server</strong> <strong>2008</strong> Programming.