SoftTree Technologies SoftTree Technologies
Technical Support Forums
RegisterSearchFAQMemberlistUsergroupsLog in
Automatic add aliases to all sql and the use of "..&quo

 
Reply to topic    SoftTree Technologies Forum Index » SQL Assistant View previous topic
View next topic
Automatic add aliases to all sql and the use of "..&quo
Author Message
maxpesola



Joined: 26 Nov 2007
Posts: 51

Post Automatic add aliases to all sql and the use of "..&quo Reply with quote
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
Mon May 09, 2011 10:30 am View user's profile Send private message
maxpesola



Joined: 26 Nov 2007
Posts: 51

Post Reply with quote
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)
Mon May 09, 2011 11:22 am View user's profile Send private message
SysOp
Site Admin


Joined: 26 Nov 2006
Posts: 7842

Post Reply with quote
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
Wed May 11, 2011 12:57 am View user's profile Send private message
maxpesola



Joined: 26 Nov 2007
Posts: 51

Post Reply with quote
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 ".."
Wed May 11, 2011 3:21 am View user's profile Send private message
gemisigo



Joined: 11 Mar 2010
Posts: 2102

Post Reply with quote
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.
Wed May 11, 2011 3:37 am View user's profile Send private message
SysOp
Site Admin


Joined: 26 Nov 2006
Posts: 7842

Post Reply with quote
"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
Wed May 11, 2011 10:08 pm View user's profile Send private message
jeffw8713



Joined: 17 Nov 2010
Posts: 19
Country: United States

Post Reply with quote
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.
Thu Sep 01, 2011 4:59 pm View user's profile Send private message
gemisigo



Joined: 11 Mar 2010
Posts: 2102

Post Reply with quote
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.
Thu Sep 01, 2011 5:22 pm View user's profile Send private message
SysOp
Site Admin


Joined: 26 Nov 2006
Posts: 7842

Post Reply with quote
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.
Thu Sep 01, 2011 11:10 pm View user's profile Send private message
Display posts from previous:    
Reply to topic    SoftTree Technologies Forum Index » SQL Assistant All times are GMT - 4 Hours
Page 1 of 1

 
Jump to: 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

 

Powered by phpBB © 2001, 2005 phpBB Group
Design by Freestyle XL / Flowers Online.