hi all
added to the above... i got SP3 of AS installed but when i use the same
expression to filter the members in the person_role_success dimension
using the NT login i get the following error:

"Unable to bind name.. the <name> is unbindable in the current context"

here is the expression i used in allowed members block of the custom
dimension security wizard

StrToSet(StrToMember("[PERSON_ROLE_SUCCESS].["+right(username,len(usern-
ame)-instr(username,"\"))+"]").Properties("Prs Login"))

is the syntax OK.. please help me out with this..

Thanks in advance

--
Posted via http://dbforums.com

Depending on the size / complexity of your cubes, you could have
performance issues with using external functions in your dimension
security - as they would be called constantly. SP3 greatly enhanced a
major external function bottleneck, which may explain why it now
works. Here is my "lecture to myself" that I created so I could keep
track of all of the issues. I would imagine the impact of dimension
security calculations to be at least similar to Calculated Members.

Bob.
----------------------------------
Function calls in MDX in MS Analysis Services

MDX Session
An MDX Session is a connection to the server. At the server there are
worker threads that server the connections. If a query has parts that
can be executed in parallel, a worker thread is spawned for each such
part. Thus, you can have multiple worker threads for a single
connection.

Query Processing
A query is processed in two discrete, sequential stages: first it is
Parsed, then it is Executed.

Query Parsing
Only one worker thread can access the MDX Parser at a time - all
access to the Parser is serialized.

There is the appearance of an exception to this during Remoting.
Remoting is when the Execution Location has been set explicitly (e.g.
via the connection string parameter) or implicitly (by other
server/client configuration or logic) to the client. Access to the
Parser is still serialized, but the Parser is running on the client
side. However, with XML for Analysis, the client to Analysis Services
is XML/A, so the client is the server, just a different tier, and the
scalability / gating issues still exist.

Query Execution
Access to the "execution engine" is NOT serialized, but is
multithreaded as discussed above. There can be a caveat with external
functions – see Function Execution below.

Function Resolution
During Parsing, function calls have to be resolved.

For Internal Function (Native Function) calls, this is no problem. If
there are internal functions and external functions with the same name
and signature, the internal function will be used. This has been
confirmed explicitly with Microsoft for IIf(), which is a supported
VBA function as well as an internal function. I don't know how to
force calling the external function version. Perhaps if the external
function had the same name but a different signature, the signature
would allow the Parser to resolve the call.

For External Function (User Defined Function) calls, the libraries
(DLL, OCX, etc.) and the functions to be used have to be registered.
The Excel and VBA function libraries are automatically registered, but
only functions that have been used will show up in the MDX Builder.
Even for registered function libraries, the Parser must load the
library before the function call in the MDX Query can be resolved.
· Up through Analysis Services 2000 sp2, the Parser would load, and
then unload every library at Parse time solely for the purpose of
resolving the function calls.
· In sp3, this has been fixed such that the Parser only needs to load
a library that has not already been loaded, and it does not unload the
library. As of sp3 the only thing that unloads a library, is memory
demand against LRU code.

Function Execution
Worker threads executing functions from single-threaded libraries will
have their access to functions from those libraries serialized across
all worker threads.

In the Microsoft document "Creating and Using User-Defined Functions
in MDX" (http://msdn.microsoft.com/library/en...sp?frame=true),
in the first sentence of the section "Other Considerations" says:
"...; external functions lock MDX sessions while executing." It says
this by way of warning that calling an external function with user
interaction is dangerous - a dialog box will halt the query processing
until it is dismissed.

Given the above information about MDX Sessions and worker threads, the
parser, etc. the "locking" described in the above document also means
that the Parser access is serialized for potentially longer than
normal when using external functions (much improved with sp3), and
that depending on the library being single-threaded, execution can be
serialized.

It has been confirmed with Microsoft that Apartment Threaded libraries
(such as the VBA library, msvbvm60.dll) Analysis Services does NOT
load another instance of the library per worker thread (consistent
with the parser now loading the library only once, globally).
Therefore, execution of external functions in Apartment Threaded
libraries is serialized across worker threads.

Calculated Members (Measures)
Calculated members are Parsed at run-time. Therefore, calculated
members calling functions incur exactly the same overhead issues as an
external MDX Query using functions. So again, sp3 comes seriously to
the rescue here considering the potential number of calculated members
and the complexity of their interactions. I think it is safe to
assume that calculated members have always been parsed once per query,
not once per cell. However, loading the libraries only once is still
a big gain here.