DROP IF EXISTS syntax doesn't appear to be supported
See original GitHub issueSQL Server 2016 introduced DROP [VIEW|TABLE|PROCEDURE|FUNCTION] IF EXISTS syntax.
TSqlLint is reporting these as syntax errors i.e.:
NoticesView.sql(1,11): error invalid-syntax : Incorrect syntax near IF..
and this isn’t configurable via the rules.
It looks like the TSqlLint tool uses the Microsoft.SqlServer.TransactSql.ScriptDom package so it might be that this cannot actually be solved without Microsoft updating their package unfortunately, and I’m not sure that is even still maintained…
Issue Analytics
- State:
- Created 5 years ago
- Comments:6 (4 by maintainers)
Top Results From Across the Web
sql - An error appear when I use "DROP TABLE IF EXISTS" ...
Incorrect syntax near the keyword 'IF'. What is the problem? I'm using a specific database of Microsoft to work with SQL Server 2016...
Read more >SQL Server DROP TABLE IF EXISTS Examples
Learn various ways to check if a SQL Server table exists before trying to drop the table to avoid the table does not...
Read more >drop # table if exists statement does not ...
Hi All, I have this in my store procedure. DROP TABLE IF EXISTS #TMP_TABLE_01 SELECT GETDATE() [TODAY] INTO #TMP_TABLE_01 DROP TABLE IF ......
Read more >DROP VIEW IF EXISTS failure
The <name> that you are trying to DROP does exist, therefore the clause part "IF EXIST <name>" is true. So then the command...
Read more >DROP TABLE IF EXISTS does not work - Databricks - 28269
The command works when the table does exist. I am using Python3 in an Azure Databricks notebook, Databricks runtime 5.2 on a high...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Hi, very much appreciate you putting in the work to implement the configurable parser feature! Myself and a colleague had identified that TSql120Parser was being instantiated in FragmentBuilder; we downloaded your source code, saw that there was a TSql140Parser class as well, rebuilt with that change, and it worked for us… I was about to reply on this thread to suggest this but you fixed it already 😃 Just wondering if there is a reason why your compatibility level list only covers up to 130 and not 140 (although this should be fine for us since that 130 = SQL Server 2016 I believe)?
140 (sql server 2017) was not intentionally left out, I just pulled the levels from an out of date chart. 140 should be supported as well, #172 for tracking.
I very much appreciate you bringing this to our attention!