Formatting issue -- uppercasing non-keywords
dbrinkerhoff
Posts: 7 Bronze 1
Let me start by saying I don't have a good example to reproduce. This issue is happening with long scripts that rely on in-house tables, etc. If it is needed I will take the time to find one.
What is happening is that, when using the same script and the same server and the same formatting style, different databases will behave differently when I use SQL Prompt to format. Something like:
(Again, this exact script doesn't cause the error, but it's similar in style to the ones that do.)
If I reformat the script in one database, nothing is changed. If I reformat in another database, SQL Prompt changes the SELECT statement to DEBUG.NAME, which is then an error. I have seen this for columns called Name, Active, and Section. Those don't appear to be reserved keywords by SQL Server (source: https://msdn.microsoft.com/en-us/library/ms189822.aspx ), and if they were, I would expect the behavior to be the same for all databases.
For our style, we use UPPERCASE for all of Reserved Keywords, Build-in functions, and Built-in data types. We are leaving "Use object definition case" unchecked. Any thoughts?
What is happening is that, when using the same script and the same server and the same formatting style, different databases will behave differently when I use SQL Prompt to format. Something like:
SELECT DEBUG.Name FROM (SELECT 'BLAH' AS Name ) AS DEBUG
(Again, this exact script doesn't cause the error, but it's similar in style to the ones that do.)
If I reformat the script in one database, nothing is changed. If I reformat in another database, SQL Prompt changes the SELECT statement to DEBUG.NAME, which is then an error. I have seen this for columns called Name, Active, and Section. Those don't appear to be reserved keywords by SQL Server (source: https://msdn.microsoft.com/en-us/library/ms189822.aspx ), and if they were, I would expect the behavior to be the same for all databases.
For our style, we use UPPERCASE for all of Reserved Keywords, Build-in functions, and Built-in data types. We are leaving "Use object definition case" unchecked. Any thoughts?
Comments
Firstly, could I check which version of Prompt you're using?
Name is considered a "semi-reserved" keyword as it can be a keyword depending on the context (such as in ALTER DATABASE MODIFY NAME or inside a backup statement). Would it be possible to provide us with the script where the error occurred? I'm wondering if Prompt has mis-parsed the script and thought that it was meant to be a keyword in that specific context?
Thanks,
Aaron.
There are several different scripts that are producing similar errors. They depend on tables created in other scripts, and they are not short. I will give you this one, which is 613 lines. Reformatting only changes the case of the second instance of IPP.Name to IPP.NAME, and only when formatted in "master" as opposed to any other database. I will try to find a better example.
I can reproduce the issue here on the latest version of Prompt and I'll have a look into a fix for you now.
Thanks,
Aaron.
I have cut out a lot of the script, so what is left will not actually run correctly. But it does format, and both instances of DEBUG.Section become DEBUG.SECTION. However, if the statement that begins "IF @QRDA3 <> 'Y' " is commented out, the formatting does not change the case. And, as before, this only happens in certain databases. In this case it is not only "master" that causes the issue.
I think what's happening is on some databases it may not be able resolve some of the identifiers to the database objects and so it's interpreting the script slightly differently depending on if it has those objects there or not.
I've made a first attempt at a fix for you in this private build, could you give it a go and let me know if it helps with the cases you've got?
I'll continue to investigate to see if this might be affecting anything else.
Thanks,
Aaron.
EDIT: Apologies, the fix may have introduced a knock on, i'll look into another possible fix.
Thanks!
Aaron.
Thanks again for your help!
Aaron.