$OBJECT$ still faulty

$OBJECT$ still omits database name if the selected object is reached through database.schema.object or if the database is the object selected. Even $OBJECT(ins_db)$ does not return the database name in the latter case.

Adding ins_schema, ins_db, etc. to $OBJECT$ was a nice touch but I cannot find them in the docs. Is it possible that the help is not updated?

Thank you for the info. I wasn't aware of that functionality, and it appears to be undocumented. I will need to check with developers to find out more. Will get back to you as soon as I know what that is.

How did you find out about ins_schema, ins_db, etc. in $OBJECT$ macro?

I inserted one of my rarely used snippets that selects a database for $OBJECT$. It failed for the reason stated above. I tried to rewrite it (failed, by the way) and though I usually just type $OBJECT$ this time I selected it from the menu:

[/img]

I was just staring when I got the following dialog instead of simply inserting $OBJECT$ into the editor:

The radiobutton in Insert section specifies which part of the object name will be inserted, that is, adds ins_schema, ins_db, etc. to $OBJECT(...)$. The checkboxes add proc, func, schema, etc. to $OBJECT(...)$ and they act as a filter(s) and constraint(s) to the popup items. These are quite sophisticated. I mean selecting columns inserts $OBJECT(column)$. When inserting the snippet the popup omits stored procedures/functions/etc. and shows tables/views/table functions (filter part) which are required to select a column (constraint part) but only selecting (pressing ENTER or double-clicking) a column does trigger the $OBJECT$ macro evaluation. Using $OBJECT(proc)$ shows nothing but procedures, databases and schemas, of course, to be able to select a procedure from another database or schema, and so forth.

Hats off to the developers, I must say.

I know there have been some changes in release 6.1 related to handling of $OBJECT$ macro. At least the hidden features are now documented. Please check the latest build 6.1.35, which is available for download (right-click SQL Assistant icon in the system tray, click Check for Updates menu)

$OBJECT(login)$ does not filter objects to logins. It only shows database and schema objects but those are not relevant in this context.

Also, there are two checkboxes named Record in Columns / Arguments. The first one resolves to $OBJECT(recordType)$ and the second one to $OBJECT(unknownType)$

I'm trying to make sense of login and other filters. It looks like some of these filters are rather late binding filters; it isn't they filter the content of the popup window, but rather what can be selected in it. Here is my theory. The content of all popups is driven by database queries in SQL Assistant options, I see that the only query returning logins is Schemas (MSSQL), specifically this part

Code:

select
   name collate Latin1_General_CI_AS, 'SC', schema_id
from
   [$DB_NAME$].sys.schemas
where
   schema_id < 16384
union all
select
   name collate Latin1_General_CI_AS, 'SR', principal_id
from
   [$DB_NAME$].sys.database_principals
where
   type in ('A','R')
union all
select
   name collate Latin1_General_CI_AS,
   case when type = 'R' then 'SR' else 'SL' end,
   principal_id
from
   [$DB_NAME$].sys.server_principals
where
   type in ('S','U','G','R')

So, in order to get logins in the popup list, that "schemas" query need to be executed to pupulate the list and that's why it returns more than just logins. Yet, only items with 'SL' value in the 3rd output column could be selected. Does that make sense?

Just a second, let me check.

In regard to "records" that is for Oracle only, may be that's why it returns unknownType when used with MSSQL, I'm not really sure.

Yes, it perfectly makes sense. I checked DB Queries for MSSQL schemas and the first part of it matches your code. I suppose the second part is here for server versions older than 2005. Your explanation is clear and having schemas and databases in popup is fine. My problem lies in popup not showing logins at all. Only schemas and databases.

Ah... now I understand. I think I see the same here, even though my db query surely returns them. I will need to log this issue to get input from the team.