Are embedded spaces ever valid in non-delimited names?

  • Hello experts

    I am trying to debug a procedure which is timing out, not in every case, but in some cases.

    During my perusals, I note that there seems to be a stray space in the 3rd line of following fragment of an UPDATE statement in the procedure:

    ...

    FROM dbo.LoadMedicationsGP LMGP

    INNER JOIN dbo.Patient P ON LMGP.PatientId = P.PatientId

    INNER JOIN dbo. PatientMonths PM ON P.PatientKey = PM.PatientKey

    AND LMGP.DatePeriodKey = PM.DatePeriodKey

    ...

    SSMS seems to parse the statement perfectly OK, but to me it looks as if it ought to be wrong.

    I suspect that the space has no material effect, but I just wanted some confirmation one way or the other. A quick search in BOL didn't reveal anything, but feel free to correct me.

    Thanks in advance.

    Mark Dalley

  • You can check for yourself.

    SELECT TOP 100 *

    FROM dbo. LoadMedicationsGP

    It should work.

    John

  • Hello John

    You're right, it does work. To my mind, it oughtn't to, though. The parser should throw out the "dbo. " as an incomplete name.

    Makes me nervous when stuff like this gets accepted without a murmur of complaint. You wonder what else it is swallowing and maybe interpreting differently than you expected.

    MarkD

  • The parser is very forgiving of formatting. If you think of 4-part names as each part being independent and as overriding a default scope, it will make sense to allow spaces between object names. There are plenty of anachronisms in mssql left over from the sybase days.

    SELECT TOP 10t. *FROM sys.tables t

  • Bill Talada (8/29/2014)


    The parser is very forgiving of formatting. If you think of 4-part names as each part being independent and as overriding a default scope, it will make sense to allow spaces between object names. There are plenty of anachronisms in mssql left over from the sybase days.

    SELECT TOP 10t. *FROM sys.tables t

    Ugh! How readable is that! Sure it works, but how dare it. Aesthetically, it is a reeking mess.

    A little more strictness in the parsing process would (a) enforce greater readability; and, (b) make it easier to enhance syntax if a new feature needs to be added. The current approach is too context-sensitive for my taste.

    MarkD

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply