Home/ Questions/Q 458241
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T22:39:06+00:00

I’ve got a distributed deployment of ±20 clients using the same stored procedure to

  • 0

I’ve got a distributed deployment of ±20 clients using the same stored procedure to create a record and then attach detail records. We’ve noticed gaps in the identity fields of the master record. We are not using a transaction in this instance so the only reason we can come up with for the gaps is that one of the developers is swallowing an exception somewhere. Is there a list of failed queries or queries that threw an exception logged somewhere?

Are there any other suggestions to get to the problem queries besides:

  • Using SQL Profiler
  • Creating a mirror table that has the same signature but with all fields nullable and without references, then expanding the stored procedure to insert into that table first and then seeing if some of the input is blank/bad
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    SQL Server 2000 (and later) does not automatically log queries that generate mere “data” errors. It will log queries that generate serious errors (e.g. RAISERROR level 20 and up), and any such errors will be logged in the Windows Application Event log. However, it seems very likely that whatever is causing your games will not be generating these kinds of errors, as you’d have probably noticed other problems by now.

    One way to try and locate this activity is, as chadhoc said, to set up a trace to watch for it. Doing so acrosss 20+ servers across [how many?] days, and then analyzing the results, qualifies as a non-trivial task. (I’d configure a first pass with Exception events and, depending on your application, one of Batch Start, stored procedure start, or RPC start.)

    Another tactic: rather than a mirror table populated by “expanding” your stored procedure(s), try an INSERT trigger on the table that populates a log table. (This would catch all inserts, not just those done by your stored procedure.) The log table would track the ID, time of insertion, and any additional information you might find useful (who performs the login, the calling application, whatever other data be useful for debugging). It may end up looking like a mirrored table, but it doesn’t have to be. If gaps still appear, then you’d know for sure you had transactions being rolled back. (And remember, if just that first INSERT statement fails and the row is never inserted, it still “uses up” an identity value.)

    • 0