Is there a way to trace the actual MDX generated by querying a Cube in Excel, and get the actual MDX used ?
I've tried using SQL Profiler, and while that does return the MDX, it doesn't take into account the role that the connection is using (it's passed in a separate PropertySet).
I'm just wanting to get the MDX that the query is using, as it doesn't appear to be filtering correctly using different roles (but the same base MDX query).
Update: Ok, maybe I need to be a bit clearer. I'm trying to get the resulting query that is firing at the Cube, after the Role has been applied.
SQL Profiler gives me the MDX, and the name of the role in a PropertySet, so is before the Role is applied.
Update 2: In case it helps, this is an MDX query that I've been using to test the functionality.
select {[Measures].[Company Value]} on columns,
{[Dim Model].[Title Name].Members} on rows
from [DWHName]
You might want to try the following add-in from codeplex. http://olappivottableextend.codeplex.com/ It just gives you what was sent to the OLAP server. BEWARE though, it adds a bunch of extra mdx that does UI display.
I'm pretty sure you can't actually get what you're after. The security role is a property of the connection or of the user running the query and the various restrictions put on the resultset are applied in the query engine. So you never get to see what restrictions are applied (which, I suppose, could be a security issue in itself)
I'm not sure whether I've properly understood your question, but it is possible to get the MDX generated by Excel using a macro to query the PivotTable.MDX property.
See here for an example implementation.
Not sure I understand either. Are you saying that you want to see the results that role will see? (The MDX in the trace is exactly what was submitted, no?)
Have you tried executing the captured MDX through MDX Studio (where you can set the Role for your connection)?
Related
I need to make identical changes to hundreds of reports, and I was hoping to do this via SQL instead of each indvidual report and it's query. I can extract the report query via xml and generate my list of reports, their location, and the query being used. But what I cannot figure out is how to update the report query and then get that updated back into the Catalog? database so that the report itself reflects the changes when executed? I have never seen where this is possible, but maybe someone on here has tried to do this or knows that it's flat out not possible.
I could use SSIS and do this, but I would prefer not to download all the RDLs and then update, and then redeploy/upload the reports. Was hoping to update in place the reports/RDLs.
You shouldn't have to download the RDLs, they should already be in your source control system, and ideally collected and grouped into project(s). If so, you are in luck - you can use the global search/replace capabilities of Visual Studio (BIDS) or Notepad++ to make your change.
If your change was to the structure of the report then you could simply write a quick nasty console app to load the RDL and manipulate the XML structure. But things like the report query are held as free-form text in a node, making it harder to apply mass updates in a reliable way.
You could look to refactor the report queries into stored procedures and/or functions, this will make future updates a bit easier. In any case if you change the report RDLs you've got no option but to republish the modified ones - there's no such thing as an in-place change on the server (having your queries as stored procedures would have avoided this issue).
I have an access form with a fairly complex query displaying raw test values and the resulting test calculations on a large MS Access Form that was created in access 2007. Every once in a while my data entry guys are complaining that upon leaving and returning to their database form they see an error with text "This expression is typed incorrectly or it is too complex to be evaluated. For example, a numeric expression may contain too many complicated elements...". After this error appears every textbox is populated with the "#NAME?" error code.
I am curious if anyone has experience with this. I recently migrated the backend table from another MS Access database to SQL Server. My table has a primary key in SQL Server and also a timestamp column. Lastly, I have tried to reduce the size of the query that produces the calculations displayed on the form. On top of that not working, it previously worked within Access , so I don't see how simply moving the table to SQL server would cause the size of the query to now be too much.
Any help is appreciated, thanks.
This is a late response but I've recently experienced a similar issue and found it to be data type related.
Check if your SQL Server table's primary key data type is "bigint". If it is this may cause problems reading the data in Access. Access 2016 supports large number types but it needs to be set in Options-->Current Database-->Data Type Support Options. Note that setting large number support will prevent your Access app from working in version prior to 2016.
One suggestion, which may actually speed up the forms as well. Is to rewrite the query you are using as your bound data source for the form as a view on the SQL server.
Then link this view to your MS Access front end and use it as the bound object.
Depending on your requirements, Read/Write, and experience in SQL this may be an easy thing to do or a moderately tough thing to do.
Access is pretty greedy with the network connection so any processing you can move server side is fantastic.
I am using MS Access as a front-end and using an ODBC SQL Server Driver for data.
How is that I can parameterize my query using a field from an MS Access form?
Here is my current working query (however, I need DALLAS to be a parameter I can pass from a MS Access form):
Select LPID,Name_Long, MR_Markets from baf_center
Where Guild_Markets = 'DALLAS';
Should this be handled in VBA instead?
Any help would be appreciated.
If I understand you correctly, you have field in a form and you want to use that in the where clause of a query. If so, you could reference the form field like so in the criteria of the query designer:
[Forms]![Your Form]![Your Form Field]
Let me know if I'm off-base about what you're trying to do.
Are you using linked tables to a SQL Server database. If so, it is an actual ODBC query.
You might be able to reference [Forms]![Your Form]![Your Form Field] in the criteria window entry under the Guild_Markets column. However, you have to do something with the results?
You can also execute the query via VBA.
I guess the main question is what are you trying to do?
I'm trying to debug a deadlock with SQL Server Profiler 2008. I know how to get a graph of the deadlock in the profiler, but when I hover over one of the two statements in shown in the graph, the "Statement" tooltip that appears only contains the query with parameter names, not values.
In other words I get tooltips like this:
DELETE FROM users WHERE id = #id
How can I see the corresponding parameter values? This screenshot:
shows what I would like to see, so there must be a way.
Your best bet is probably to also include "SQL:StatementStarting" in your profile and then just scroll up the list looking for the SPIDs that were part of the deadlock. That's not an easy way to do it, but SQL Profiler records the statements differently if they were parameterized SQL vs. a regular statement. In your photo, it looks like it's showing a non-parameterized statement, but your question seems to be about one that's parameterized.
I've had this problem before with trying to figure out exactly what an application was sending to SQL Server - all I could see was the parameterized query, and that wasn't helping me at all.
We have an application that has 1000+ databases and 600+ sprocs. Each database represents a different client.
Problem: We need to move this to a single database while creating as little effect on the ui as possible, meaning dont change all the sproc signatures at 1 time.
The connection string currently sets the database attribute, a proposal is to move that to the user attribute. This attribute (using SYSTEM_USER) could be used to determine the site identifier which would be used on the where clause.
The above would not be final solution, but allows us to make changes to the sproc signature at a slow controlled pace. Once all are done we can correct the connstring and get some connection pooling.
Are there any limitation to the number of logins/users that we can have on sqlserver 2005/8. Or has anyone been down this path that could shed some light on a better option.
See my answer here
Ideas for Combining Thousand Databases into One Database
Sounds like you two are working the same project. YOu will need to change every proc before you can move to one datbase or each client will see the others' data.
As for the number of logins on SQL Server 2005 / 08 - I don't think anyone has ever run into a hard limit here. A few thousand will NOT be any problem at all.
What you could consider for this scenario might be one schema inside your single DB per customer, e.g. customer "Miller" has a "miller" schema, with its objects inside, and customer "Brown" will have a "brown" schema.
And contrary to what HLGEM just responded - no, customers won't see each others data, if you specify proper permissions - each customer (and its users) into its own schema only - should work just fine.
Marc
You might also consider setting a distinctive application name in the connection string rather than using a distinctive user, which you can get into your where clause using APP_NAME(). I'm sure that SQL Server won't have a problem with thousands of logins, but you may prefer not to have to create them.