Alias Unfriendly

• 
  I see where you're getting the issue, but I don't get it if I build my FROM clause first, with aliases. Then, when working on the SELECT or WHERE clauses, the alias is picked up by the tool.
  The problem is, more often than not, that's not the way I build a query. I tend to, and I think everyone else does to, type "down." Meaning I type the SELECT list, then the FROM list, then the WHERE clause.
  Still, maybe making an adjustment in how I type up the queries is worth the use of the tool.

  Grant Fritchey May 24, 2006 08:23

  - 0 +
• 
  I have the same problem.
  
  With the following SQL code:
  SELECT * FROM SomeTable s
  WHERE s.
  
  When I type "s." it would fill in the first result that starts with an "s".
  
  It seems like the period is also a key to trigger the selection for the intellisense.

  inV1NC3ble May 24, 2006 18:52

  - 0 +
• 

  RogueDog wrote:

  ...So my suggestion is to give SQL Prompt the ability to recognize when aliases are being used and then if they are being used to require them prior to each field.

  
  I think this is a style issue, and I disagree with it.
  
  SQL Prompt recognises aliases (e.g. x.), and prompts for field names for the given alias on join or where clauses - which is what I expect.
  
  I don't want to be forced to use aliases for every column, only for those that are ambiguous.
  
  Here's what I tend to do, and why I prefer this idea...
  
  I tend to start a complex query with

  top 10 *
  

  as my select list, while I then set up the from clause with it's joins. I use aliases there, and then in the where clause as I refine it. Given that I have the aliases defined by the time I type my where clause, SQL Prompt is all good at that point, with good intellisense prompting.
  
  I find that having all fields from all tables visible initially helps me visualise the data that I'm retreiving, and helps me spot where my join or restriction criteria aren't quite right.
  
  I then create my select list once I'm happy with the rest of the query, and at that point have a pretty good idea of which columns need to be disambiguated (because I've already used them to join).
  
  I tend not to use aliases for other columns - both because their owning table is self evident, but also because I want SQL Server to let me know if I've got an ambiguous column - because that indicates to me that I don't yet fully understand the underlying tables and views in a query I'm writing. In other words, if I get a warning that a given column is ambiguous (and I didn't expect it), it makes me review a given query. Perhaps I'm joining a table that I don't require (because it is already joined inside a view that I'm using). Perhaps I've not specified my join criteria correctly (and so I haven't actually specified a true inner join).
  
  If SQL Prompt forced me to always qualified aliased tables, then I'd never get the chance to see ambiguous columns. The fact that I do alerts me to the possibility that I haven't written an optimal query.

  Bernard Sheppard May 31, 2006 23:34

  - 0 +
• 
  Hi there,
  
  
  Thanks for your feedback. Aliases are a bit of a thorny issue, and there are definitely two sides to the debate. In an ideal world what we'd do in SQL Prompt 3 is provide some sort of option to select between different behaviours for this, although at this stage we're still very much figuring all of this out so I can't promise anything.
  
  
  Many thanks,

  Bart Read June 02, 2006 05:14

  - 0 +
• 
  I agree with inV1NC3ble. It wouldn't be a problem for me if the period did not trigger the selection. As it is now, you have to choose aliases that, for the number of characters they are long, will not match the same number of leftmost characters in the name of any columns of any of the tables in the query.

  BEACHDBA June 28, 2006 11:56

  - 0 +
• 
  Will version 3 allow us to turn off the "period" triggering the selection for the intellisense?

  paytonc September 18, 2006 16:59

  - 0 +

Add comment

Please sign in to leave a comment.