Conclusion

Choosing to use the flexibility of SQL Server is a smart and easy decision. What is surprising is the ease of use offered by today's developer tools. In years past, developing triggers and stored procedures was difficult work, and the tools available were not terribly helpful. SQL Server 6.5's Enterprise Manager offered developers little in the way of assistance when they edited SQL code.

Times have changed. Both SQL Server 7 and Microsoft Visual Studio offer tools for developing SQL code; these tools will seem familiar to developers who use integrated development environments for other languages. Niceties such as color -coded syntax highlighting have been joined by source-level debugging abilities .

While the server world has changed, the client world has not been standing still. Though supporting multiple types of clients has always been a problem, the Web has made that task an even more familiar scenario. This greater need to support multiple clients increases the need to offload processing to servers. Encapsulating business rules inside the database server is a natural solution.

Long-time SQL Server developers are already well aware of the joys of business logic residing on the server. These same developers might not be aware of extended stored procedures. Even those who know about extended stored procedures might have shied away from using them for fear of degrading SQL Server reliability. Unlike many of the projects for this book, the extended stored procedure xp_beep worked the first time and never caused any problem with SQL Server. Of course, an extended stored procedure could still damage SQL Server, but that fear has been overhyped. For SQL Server programmers who have hit the wall programming in T-SQL, extended stored procedures offer a flexible solution.