Ron Talmage

Ron Talmage


Ron Talmage is a mentor and co-founder of Solid Quality Mentors. He is a SQL Server MVP, a PASS Regional Mentor, and current president of the Pacific Northwest SQL Server Users Group. He has been writing white papers and articles on SQL Server since way back when.

Articles Authored

  • Designing for Database Movability

    Last updated: Wednesday, February 20, 2019

    Published in: SQL Server Observer

    Eventually SQL Server databases in a production environment must move from one server to another. It’s important to plan for eventual database moves when architecting a database solution.Designers and developers often overlook the eventuality that a database will need to move to a different server. This month’s column is the first of three dealing with the issues surrounding database moves. In this first part, you’ll learn about the reasons why you should plan for moving a database when you design and architect your application.

  • Handling SQL Server Errors in Nested Procedures

    Last updated: Tuesday, February 19, 2019

    Published in: CODE Magazine: 2003 - May/June, VFP Conversion Papers

    Basic error handling in SQL Server's programming language, Transact-SQL, is straightforward.But when you nest calls to stored procedures, and the procedures have SQL transactions, error handling becomes much more complex. In this article I'll show you some tried-and-true models for how to handle errors in nested stored procedures with transactions.

  • How Developers Can Avoid Transact-SQL Cursors

    Last updated: Wednesday, February 20, 2019

    Published in: SQL Server Observer

    Ron Talmage discusses how developers can avaiod Transact-SQL Cursors

  • Methods for Moving a Database

    Last updated: Wednesday, February 20, 2019

    Published in: SQL Server Observer

    Moving a SQL Server database from one server to another is simple-initially. But there are various methods for moving a database, and some have more advantages than others. Investigating the types of moves ahead of time can make planning for a database migration easier.It takes essentially three steps to move a database from one server to another: take the database out of production, copy it to another server, and then bring the copy back into production. While you can choose from many methods to accomplish these steps, it can be difficult to complete the move given all the database’s dependencies. In this article I’ll describe the methods for moving the database. In my next installment I’ll discuss the dependencies and additional related objects that you must also move along with the database data.

  • Moving a Database: Dependencies

    Last updated: Wednesday, February 20, 2019

    Published in: SQL Server Observer

    xIn the past two installments of this series I’ve discussed two key aspects of moving a SQL Server database from one server (or instance) to another. First I covered the advantages of designing databases to make them easier to move, and then I looked at the methods that you can use to move a database. Now it’s time to look specifically at the types of database dependencies that you must account for after you move a database.

  • Performance Counters on the 64-bit Road Less Travelled

    Last updated: Wednesday, May 11, 2022

    Published in: SQL Server Observer

    Ron Talmage discusses performance counters in SQL Server.

  • Resolving Deadlocks in SQL Server 2000

    Last updated: Tuesday, February 19, 2019

    Published in: CODE Magazine: 2003 - September/October

    Your application can detect a deadlock and resubmit its transaction, but a better approach is to resolve a deadlock by changing the conditions that lead to it in the first place. In this article, you'll learn how SQL Server deadlocks arise, what types of deadlocks there are, and how you can resolve them.

  • Scaling Out Database Writes

    Last updated: Tuesday, February 19, 2019

    Published in: SQL Server Observer

    Ron Talmage discusses scaling out database writes.

  • Scripting SQL Server 2000 Indexes

    Last updated: Wednesday, February 20, 2019

    Published in: CODE Magazine: 2003 - January/February, VFP Conversion Papers

    Adding indexes to tables is the most effective way to optimize your SQL Server query performance. Tables that you query often may require several indexes in order to handle the various search arguments you send. There is one particular situation where indexes on large tables are a hindrance, though. When you're bulk-copying data into the table, it's best to have either no index at all, or just a clustered index. For those situations it is best to use Transact-SQL scripts to remove and add those indexes. In this article you'll learn how to use Transact-SQL stored procedures to generate Transact-SQL indexing scripts that are more robust and less laborious than SQL Server's Enterprise Manager scripting tool.

  • Securing Your SQL Server

    Last updated: Wednesday, February 20, 2019

    Published in: CODE Magazine: 2002 - November/December

    SQL Server, like most complex databases, has potential security holes. This article discusses these security holes and how to close them.

  • Snapshot Isolation in SQL Server 2005 "Yukon"

    Last updated: Friday, February 22, 2019

    Published in: CODE Magazine: 2004 - July/August

    Snapshot isolation is a new isolation level that reduces blocking reads and allows transactions to read previously committed versions of data, instead of uncommitted data.SQL Server's default isolation level of READ COMMITTED restricts transactions to reading only data that has been committed. This isolation level has the effect of blocking a transaction's read operation when the data is exclusively locked by another transaction. A lower isolation level called READ UNCOMITTED allows your transactions to read another transaction's uncommitted data while it is locked, but the values are not stable because the data is uncommitted. SQL Server 2005 introduces a new isolation level that provides a middle way between READ COMMITTED and READ UNCOMMITTED. The SNAPSHOT isolation level allows your transaction to read the previously committed version of the data that is currently being changed, so that your transaction's view of the data is consistent with the state of the data when your transaction began without being blocked by the other transaction. Snapshot isolation has the benefit of reducing blocking and deadlocking in your transactions that is due to blocking reads, without having to let your transactions read uncommitted data. (Note: this article is based on a pre-Beta 2 version of SQL Server called IDW3, build 9.00.790. Some details about the operation and behavior of snapshot isolation may change before the final version of SQL Server 2005 ships.)

  • SNAPSHOT Isolation in SQL Server 2005, Part II

    Last updated: Wednesday, February 20, 2019

    Published in: CODE Magazine: 2005 - January/February

    In addition to the transaction-based SNAPSHOT isolation level, SQL Server 2005 Beta 2 also introduces a statement-level variation of the READ COMMITTED isolation level called READ_COMMITTED_SNAPSHOT.Part I of this article (see "Snapshot Isolation in SQL Server 2005," July/August, Volume 5, Issue 4) described the transaction-based SNAPSHOT isolation level. At the time Part I was written, just prior to the release of Beta 2, only the SNAPSHOT isolation level was fully documented. With the release of SQL Server 2005 Beta 2, a fuller explanation of a second type of SNAPSHOT isolation behavior has come to light.

  • SQL Server 2000 Replication 101: Replication Agents

    Last updated: Tuesday, February 19, 2019

    Published in: CODE Magazine: 2004 - May/June

    Replication agents are the basic components of SQL Server 2000 replication.Before you settle on the type of replication you want in your application architecture, it is important to understand how each type of replication works and what agents they use. Since the different types of replication use different combinations of replication agents, understanding what those agents do helps clarify the resulting SQL Agent jobs when you install replication. For example, snapshot, transactional, and merge replication all use the Snapshot Agent to initialize the subscriber's data. Then they employ other agents to implement the replication process. In this article, you'll learn about the roles of the replication agents and learn how to inspect the properties and profiles of the Snapshot and other agents.

  • SQL Server 2000 Replication 101: Terminology, Types, and Configuration

    Last updated: Wednesday, February 20, 2019

    Published in: CODE Magazine: 2003 - November/December, VFP Conversion Papers

    Replication figures as one of the more prominent features of SQL Server 2000.Replication is a complex application that uses a combination of stored procedures and executables to distribute and copy data between SQL Server databases. If you take care not to get lost in the details and confused by occasionally misleading terms, replication can be an important component in the database architecture of a SQL Server application. In this article, you'll learn about the terminology surrounding replication, the types of replication available in SQL Server, and how to configure (that is, install) replication.

  • SQL Server 2005: Scaling Up and Out

    Last updated: Friday, February 22, 2019

    Published in: SQL Server Observer

    Ron Talmage discusses SQL Server 2005 in this introductory SQL Server Observer Newsletter

  • SQL Server 2008: Two Winning Features

    Last updated: Friday, February 22, 2019

    Published in: CODE Magazine: 2009 - September/October

    SQL Server 2008 has been out for more than a year, and perhaps an overview and assessment is due. From a database administrator’s point of view, what features are standing the test of time?

  • SQL Server Database Mirroring Roles: Instance versus Database

    Last updated: Wednesday, February 20, 2019

    Published in: SQL Server Observer

    Ron Talmage discusses the roles of SQL Server databases and instances in high availability scenarios.

  • Testing SQL Server 2000: Inspecting Configuration Information

    Last updated: Wednesday, February 20, 2019

    Published in: CODE Magazine: 2002 - March/April

    Testing SQL Server is an often-overlooked area of the software development process, because programmers primarily place testing focus on code residing in the middle tier or the client desktop, rather than the database. However, as SQL Server databases become a more important component of applications, they cannot be left out of the developer's testing process. An important place to start, to ensure your code works the way you want it to, is with SQL Server configuration.The focus of this column is to examine issues dealing with testing SQL Server 2000 databases using SQL Server's built in language, Transact-SQL, as the primary testing tool.

  • Testing SQL Server 2000: Testing Database Options

    Last updated: Wednesday, February 20, 2019

    Published in: CODE Magazine: 2002 - July/August

    Testing SQL Server 2000 applications begins with making sure your production server is configured properly.You generally do this by verifying that the server's settings match a properly configured target computer. After configuring your server, you can go to work on validating your database configuration. This article will continue the theme of creating and implementing a Transact-SQL stored procedure to test a database's options for deviation from the default settings.

  • The x64 Path Less Travelled

    Last updated: Wednesday, May 11, 2022

    Published in: SQL Server Observer

    Ron Talmage discusses 32-bit vs. 64-bit version of SQL Server 2005