Can you control the capitalization in version 3?

montek

I'm having several issues I did not encounter with the previous version. The first of which is that it is capitalizing words that I don't want capitalized, such as NAME and ROLE. These are object and column names for us, and I don't want them capitalized but cannot find a way to fix it.

In addition, the autojoining syntax used to be fantastic and now I get all sorts of suggestions, most of which are not actually correct. Dunno about this one.

Thanks in advance.

Bart Read

Hi there,


As far as the capitalisation goes you can actually switch off the auto-caps behaviour entirely, although this probably isn't what you want. You can also choose to wrap identifiers in square braces, which will stop SQL Prompt trying to capitalise them, although this may not be what you want. The problem is really the reserved words that aren't always reserved, so what we might do s at some point in the future add a list of words to ignore for auto-capitalisation. If you want to change this behaviour go to the "Style" tab in the options dialog: you can independently set the auto-caps behaviour for reserved words, functions, and data types.

Join conditions are generated based on (i) foreign key relationships, (ii) matching column names, (iii) matching data types. If you're only interested in (i) then go to the "Candidates" tab in the Options dialog and uncheck "Include matching column names" and "Include matching data types".

As far as the foreign key join condition generation goes we've matched the behaviour of SQL Prompt 2, which generally gave conditions on only single columns within compound keys. However, we also generate join conditions for all columns in the key and other combinations of the key column. In the future its likely that we'll add an option to filter out these additional join conditions, however for now if you're using compound keys you'll get them all.

Hope that helps.


Thanks,
Bart

montek

Thanks for your help, Bart. Some follow-up issues/comments:

1. So on the capitalization thing, there's no solution for reserved words (NAME, ROLE). Ugh. I've noticed that even INSIDE text strings, it wants to capitalize these words, which is extremely frustrating. Wasn't there a list of words for auto capitalization in the previous version?

2. I've changed my settings to ignore the other candidates per your suggestion. This helps already. Thank you.

3. The automatic suggestions (from 2 above) seem to prepend the table owner to the joins, which is not desired. Is there a way to remove this?

4. Is the final, released version different from the one I am using (3.0.0.768)? Is there a list of issues that were addressed in the final version somewhere?

Again, thank you.

Bart Read

Hi there,


I notice your build number is somewhat old, the final release version is 3.0.0.868 so you'll probably find downloading the latest version improves things significantly.


Thanks,
Bart

Bart Read

Sorry, I had to write that reply in some haste. As above you should download the release we made available via the website yesterday. As far as the qualification goes just switch off object name qualification in the options dialog. We'll also probably add a list of words which should be excluded from auto-casing at some point in the future.

Hope that helps.


Thanks,
Bart

asentell

Bart,

This is a *tremendous* improvement over version 2. I am very impressed thus far after using it for only one day. I have to agree with montek, however, on the keyword capitalization. I noticed it capitalizing these keywords as I was typing comments. It would be nice if there was any way to avoid this capitalization in comments and text strings. That being said, I know there's a lot going on behind the scenes just to get it to do what it does well already. Great job!

Aaron

Bart Read

Hi Aaron,


Thanks for your kind compliments - I'll pass them on to the rest of the team. Regarding the capitalisation in comments could you let me know what version number is in the About box please? It should be 3.0.0.868. We did see that behaviour in one of the later betas but spent some time improving it and haven't seen it since.

If you are using the release version do you think you could post an example where keyword capitalisation occurs in comments please? If it's still happening we'll obviously want to get it fixed as soon as possible.


Thanks,
Bart

asentell

I have the same version as you. Type "replace" or "with" in the comments below, and you'll see intellisense pop up and/or the word will be automatically capitalized if they are on a blank line.

CREATE PROC usp_TestSproc
AS
/* replace with
REPLACE()
WITH
*/
BEGIN

-- Insert sql here

END

GO

raibeart

I also have the recent release. I am getting the capitalization problem in comments also.

Bart Read

I'm on vacation next week but I'll get on it when I return. Expect to see this fixed in the first point release.
Thanks,
Bart

Oliwa

I wanted to chime in with my $0.02.

I also find the capitalization annoying at times, but I would like the ability to set the capitalization for reserved words on an individual basis.

For example, I use smallint rather than SMALLINT, but I use Scope_Identity() rather than SCOPE_IDENTITY(). I prefer to use sentence style casing for reserved words.

Since we all seem to have our own personal preference it would be nice to have a way to set the capitalization for each word. This would give the greatest flexibility. I could make tinyint be TiNyInT if I wanted to.

ffaint

Love the final release, heavily addicted to it, but pull my hair out every time it tries to format/suggest/etc when typing in comments (especially headers). Such a patch would be tremendously helpful. Keep up the good work!

asentell

I also find SQLprompt suggesting words within INSERT strings, such as:

INSERT MyTable (MyColumn) VALUES ('')

When I start typing within the single quotes, the suggestion box comes up. Also very annoying.

You guys are doing a great job. Almost there with this challenging SQL intellisense thing!

Tilman

Hi,

sorry for the late reply.

I also find the capitalization annoying at times, but I would like the ability to set the capitalization for reserved words on an individual basis.

I've added a suggestion to our list.

pull my hair out every time it tries to format/suggest/etc when typing in comments (especially headers).

Not quite sure what you mean by 'headers'. Could you explain a bit more? (We are aware of an issue with comments inside stored procedures.)

I also find SQLprompt suggesting words within INSERT strings, such as:

INSERT MyTable (MyColumn) VALUES ('')

When I start typing within the single quotes, the suggestion box comes up.

I wasn't able to reproduce this. Could you give me the exact syntax where things go wrong?

Regards,

Tilman

asentell

Tilman,

I'm using version 3.0.0.868, and I can easily reproduce this every time, even using the Northwind database.

@DATEFIRST')

I know this is an invalid statement, but SQL Prompt let me choose it from the drop-down list.

Tilman

Hi,

Afraid I still don't get it. Do you have other statements in your script which could somehow confuse Prompt? If so, could you send me the whole script?

Regards,

Tilman

asentell

That's the only line in the entire window. It's weird that you can't reproduce it because it *always* occurs for me, every time.

Bart Read

asentell wrote:

Tilman,

I'm using version 3.0.0.868, and I can easily reproduce this every time, even using the Northwind database.

@DATEFIRST')

I know this is an invalid statement, but SQL Prompt let me choose it from the drop-down list.

@DATEFIRST is a built-in function so appears in the candidate list in upper case if you've chosen to force built-in functions to upper-case.

@datefirst and you hit SPACE even if it isn't set as a completion key@da in the quotes with the candidate list visible and then add a space immediately after this the candidate list doesn't disappear, even though it should do.

So what we have here is a raft of small issues that we'll probably need to look at for the point release. Part of the problem is that it's actually sometimes very difficult to detect whether or not you're in a string literal because what actually happens is that an unterminated quote simply breaks the parsing entirely. I therefore have to do a few checks that aren't always 100% accurate.

What I would suggest as a workaround is that if you are entering a string literal then you should surround with single quotes first as this makes the determination of whether or not you're in a string much more reliable, although other syntax errors elsewhere can still cause problems.

Hope that helps.


Thanks,
Bart

[/b]