From: mat on
In article <Xns9CD97D9B71655Yazorman(a)>, esquel(a)
> mat (mat(a)notarealdotcom.adr) writes:
> > In SSMS (2008) the line that an error is reported on has basically
> > nothing to do with the line the error is on in the sql editor window.
> > The error is reported on some idealized line number skipping whitespace
> > and who knows what else. So while the error is reported on line 15, it's
> > on line 24 in the sql editor, where I need to fix it. There is no
> > pointer to line 24 that I can find...if I select Edit Go To line 15, it
> > goes to line 15 in the editor, not line 15 in the sql (according to
> > whatever standards it uses to compute a line of SQL).
> >
> > It's a very annoying aspect of SSMS. I want to know on what line in the
> > editor the error is on. There must be a simple workaround for this?
> >
> > Why would Microsoft has the error reported in such a useless manner
> > after so many editions of SSMS? So far I've not found anything on this
> > by googling but maybe...
> You need to keep in mind that there are two applications here: SQL
> Server and SSMS. SQL Server reports error number in its context, and
> SSMS displays them unchanged. SQL Server does not know about your
> editor window, it only knows about the batches sent to it.
> Now, in most cases this is easy: you just double-click on an error message
> and SSMS will take you to that line, because SSMS is able to correlate
> the line SQL Server reporter, with the line in the editor window.
> However, this only works out if the error is in the top-most scope.
> If the error occurs in a batch of dynamic SQL invoked by sp_executesql
> or EXEC(), or in a stored procedure, the error number no longer has
> any relation to the query window at all. In this situation, you need
> to look at the code for the procedure, or debug output of the dynamic
> SQL.
> And, yeah, SQL Server is not very accurate when it reports the line
> numbers. It has gone better, but there are still situations where
> it will point to the first line of a 50-line statement, telling you
> that there is an non-existent column.
OK, thanks, double clicking the error message does seem to work pretty
well, at least in the cases I've tested with. Getting pointed to the
general area of an error is much better than the simple and very
inaccruate line number.