Comments
Sort by recent activity
Thanks for the continuing reports.
The only answer to this set of issues is that with the current release of SQL Prompt, any invalid or illegal SQL will break the parser. This will have undesired effects when writing comments, strings etc.
This was originally thought of as something that was not going to fixed as it was viewed that not much can be done about parsing invalid SQL.
However, this seems to be quite an issue for quite a lot of users so the development team are going to take steps to address this issue in a future version. It is curently under review, and for your reference the bug tracking number is SP-793.
If you would like to run through your script to see the code that SQL Prompt has a problem with, SQL Refactor should be able to help. / comments
Thanks for the continuing reports.
The only answer to this set of issues is that with the current release of SQL Prompt, any invalid or illegal SQL will break the parser. This will have undesired e...
Thanks for the reply.
Is it possible that there is some invalid SQL above the string that is confusing the parser? Simply having the string as the query is invalid SQL and would stop the parser functioning correctly, but you may be experiencing the same symptoms in real world examples.
For example, an unclosed comment block could cause this, or something like an un-commented-out <more code here> reminder in the script could break the parser.
If you have experienced this issue with a valid script, then could you please send me an example (here or by pm) and I will continue to investigate.
Thanks, / comments
Thanks for the reply.
Is it possible that there is some invalid SQL above the string that is confusing the parser? Simply having the string as the query is invalid SQL and would stop the parser fun...
Thanks for your post.
Would you be able to show me some example syntax that recreates this problem. I don't experience the same symptoms when I tested it here, so there must be something else confusing the parser.
Also, could you let me know which version of SQL Prompt you are using. I tested this in SQL Prompt 3.6. / comments
Thanks for your post.
Would you be able to show me some example syntax that recreates this problem. I don't experience the same symptoms when I tested it here, so there must be something else confu...
Hi Andrew,
Could you try the code with the latest version (SQL Prompt 3.6). I can't reproduce the problem with 3.6. You can download it by selecting SQL Prompt > Check for Updates
I know this isn't proof, but this is what happens when I write a query aginst the Advetureworks database:
USE [AdventureWorks]
SELECT * FROM [Person].[Address] a
WHERE a.[AddressID] IN / comments
Hi Andrew,
Could you try the code with the latest version (SQL Prompt 3.6). I can't reproduce the problem with 3.6. You can download it by selecting SQL Prompt > Check for Updates
I know this isn't...
Sorry for the slow response.
When you type LEFT, do you only get the suggestion for the function left? When I try I also have the option to select the keyword LEFT. The function is listed first, but below that I can choose the keyword - and continue to type LEFT JOIN, or LEFT OUTER etc
The reason the function is listed is because functions are valid SQL in a FROM clause, so they will appear in the candidate list. In this situation I would agree that the use of the keyword would be more common than the function, but it is by design that functions are listed before 'other candidates' when creating the list.
I hope this helps clarify the issue a little. / comments
Sorry for the slow response.
When you type LEFT, do you only get the suggestion for the function left? When I try I also have the option to select the keyword LEFT. The function is listed first, bu...
Dave Pendleton wrote:
It does not matter what SQL I am working with at the time--it does it all the time.
I can type GO in an empty Query Analyzer window and it will behave this way.
Thanks for your reply.
I have informed the development team about this issue. The problem is logged under the bug tracking code of SP-836.
I will update you once the report has been reviewed.
AndrewMurphy wrote:
I get something similiar with the keywork "IN"...brings up INFORMATION_SCHEMA.xxxx
PITA to deal with.
Andrew,
Sorry for the slow response.
Can you give me some example SQL that will reproduce this issue? As far as I can tell, IN will only be suggested as a candidate when it is valid in the query.
For example, if I type 'Select * from table WHERE column IN' then IN will be a valid suggestion and presented in the candidate list, but if I type IN somewhere that is not relevant then it wont be suggested in the candidate list. If you could give me an example where IN is not suggested when it should be, I can pass the issue on to the developers.
Thanks / comments
Dave Pendleton wrote:
It does not matter what SQL I am working with at the time--it does it all the time.
I can type GO in an empty Query Analyzer window and it will behave this way.
Thanks fo...
Thanks for your post.
I have to admit that I have encountered this issue myself on several occasions, but never reliably enough to log a bug report. I thought it was probably a mistake (bad syntax) on my part that caused the problem, as I have never been able to recreate the issue after.
Do you happen to have some example SQL that reliably recreates this issue? / comments
Thanks for your post.
I have to admit that I have encountered this issue myself on several occasions, but never reliably enough to log a bug report. I thought it was probably a mistake (bad syntax)...
Thanks for your post.
Both the suggestions you have made are actually features that the development team are already thinking about implementing.
The feature to include server/instance level information was originally logged under the code: SDOC-764.
The feature to set a project to not print certain extended properties was logged under the code: SDOC-726.
I'm not sure of an exact timescale as to when these can be expected, but I have added a watch to the features, so I can update you whenever the status changes. / comments
Thanks for your post.
Both the suggestions you have made are actually features that the development team are already thinking about implementing.
The feature to include server/instance level inform...
Thanks for your email and your post.
You should be able to reference another table in the where clause by using a nested select statement. It seemed to work ok in a quick test I completed here.
For example, you could construct a where clause similar to:
id > 3 OR id = (select id from othertable where id > 3)
I hope this is helpful.
Let me know if you need anything further. / comments
Thanks for your email and your post.
You should be able to reference another table in the where clause by using a nested select statement. It seemed to work ok in a quick test I completed here.
For...
Thanks for your post.
It sounds like a great suggestion, and I don't think it has already been raised. I have logged the feature request as SP-811.
Once the request has been reviewed by the developers we will be able to update you on when/if it is going to be included in a future version of SQL Prompt. / comments
Thanks for your post.
It sounds like a great suggestion, and I don't think it has already been raised. I have logged the feature request as SP-811.
Once the request has been reviewed by the develop...