Automatic add aliases to all sql and the use of "..&quo

Is it possible to add or change aliases automatically to all the sql selected?
Like the ctrl+f11 formatting.
If is it not possible, can it be a new feature?
Also, if a column use a global type i can't view the real type of that column (varchar(50), int etc), is it possible to add/view the real type also?
Thanks

Last edited by maxpesola on Mon May 09, 2011 11:36 am; edited 2 times in total

Also, is it possibile use ".." instead of ".dbo." for the objects?
I see that i use ".dbo." for the tables (for example, "dbname.dbo.tabname"), sqla takes right all the columns and properties, instead if i use the generic ".." it does not return nothing.
(sql server 2005)

Hi,

SQL Assistant is not currently supporting ".." notation for omitting schema names.
Sorry, it is also not currently possible to add aliases to object names in the existing code, and display base data type of a user defined data type in column definitions

	SysOp wrote:
	Hi, SQL Assistant is not currently supporting ".." notation for omitting schema names. Sorry, it is also not currently possible to add aliases to object names in the existing code, and display base data type of a user defined data type in column definitions

Now I'm working on a database with many and long sps that were written with the "..", no aliases and using many custom types, sqla does not help me much ...
Do you have plans to develop them in the (near) future?
At least the ".."

Yes, the '..' is extremely useful when creating queries/views/sps that yield results depending on who is running/viewing them.

Perhaps you could implement some kind of voting system for feature requests here on forum. I would certainly vote for this one. Unfolding user-defined types could also come in handy.

"Unfolding user-defined types could also come in handy" - this will be available in version 5 within the new Object Info tab. Just in case, version 5 beta is expected any day now.

We are reviewing options for supporting ".." notation, enhancement request #SA14130. From the notes in that request record, I see that developers have found lots of functional dependencies and adding support for ".." is difficult, it is unlikely to be implemented in 5.0, but might be added in one of the following releases

	gemisigo wrote:
	Yes, the '..' is extremely useful when creating queries/views/sps that yield results depending on who is running/viewing them. Perhaps you could implement some kind of voting system for feature requests here on forum. I would certainly vote for this one. Unfolding user-defined types could also come in handy.

Be careful with this request - in later versions of SQL Server you will be required to schema qualify the objects and using this notation will break. Also, using this notation can lead to multiple plans in cache for the query based upon the users default schema.

I would recommend changing that habit and to start schema qualifying all objects.

jeffw8713 wrote:

	gemisigo wrote:
	Yes, the '..' is extremely useful when creating queries/views/sps that yield results depending on who is running/viewing them. Perhaps you could implement some kind of voting system for feature requests here on forum. I would certainly vote for this one. Unfolding user-defined types could also come in handy.

Be careful with this request - in later versions of SQL Server you will be required to schema qualify the objects and using this notation will break. Also, using this notation can lead to multiple plans in cache for the query based upon the users default schema.

I would recommend changing that habit and to start schema qualifying all objects.

I always qualify objects with schema at least. But having that as a requirement is constraining versatility, that is, losing function. I consider that as a step taken backwards. Also, having multiple plans for different executions is clearly desirable (in case different default schema results in different execution).

By the way, my request was regarding some voting system and unfolding user-defined types :) I was just taking a note about '..' being useful when accomplishing something complicated in a somewhat flexible way (like templates in C++). Not the simplest solution for every problem, of course. Besides, I only used it twice or thrice so far. They are working flawlessly and I don't think they will be ported to later versions. Still, it's sad this 'tool' will no longer be available.

Support for ".." is already in the list of requested enhancements and queued. Unfortunately it cannot be implemented easily and won't be implemented likely until the next major version. Database/schema/object/column/parameter name parsing is at the core of most SQL Assistant functions. It expects name parts to be canonically separated; I mean 1, 2, 3, or 4 parts, it is currently unable to recognize names with missing middle parts, it can only guess names with optional leading parts based on the current connection context. In this sense the use of ".." violates the concept of the database context.