I have the following 2 queries from SQL Server. Is it guaranteed that Query1 will always execute before Query2? Namely when I hit the refresh button. I am updating a table in Query1 so I want that to run first before Query2 runs. Let me know if this is bad practice.
Open Power Query and click View > Query Dependencies. If they have any kind of dependency it will be shown in this visual. If they don't, the order of execution is not important and it doesn't matter whether one is executed first.
I have the issue described in this post. I have two cubes with the same data backing them, one a Multi-Dimensional cube, the second a Tabular cube. If I connect to the cubes with excel and drag the top level of a hierarchy(in this example "Company" into my filter category in the Multi-Dimensional cube, then enter some text in the search bar in excel:
(Hierarchy - In Excel)
(Hierarchy - In Visual Studio)
(MultiDimensional - In Excel as a filter)
The level below will be filtered by the text and the results will be returned. However if I filter the same hierarchy in the tabular cube, the results are different:
(Tabular - In Excel as a filter)
I receive no results, the search doesn't appear to function correctly. I can get it to work if I'm looking at the leaf level of the hierarchy, but it appears as though the node level of the hierarchy search feature for tabular cubes in excel doesn't work.
Has anyone else experienced this issue before, I'd love to post the model of the cube but it's rather proprietary, I have experienced the same issue in multiple types of proprietary cubes on multiple servers and clients. Is this some sort of configuration in the model I can change? Or something in excel I can change?
Update 1
I've been doing a bit more digging, I setup SQL Profiler to run against my SSAS server while I performed the search, seems it's generating a MDX query(this time on my "item" hierarchy):
WITH MEMBER [Measures].cChildren As 'AddCalculatedMembers([Item].[I1 - Category].currentmember.children).count'
Set FilteredMembers As 'Head (Filter(AddCalculatedMembers([Item].[I1 - Category].[Category].Members), InStr(1, [Item].[I1 - Category].currentmember.member_caption, "Per")>0),10001)'
Select {[Measures].cChildren} on ROWS,
Hierarchize(Generate(FilteredMembers, Ascendants([Item].[I1 - Category].currentmember))) DIMENSION PROPERTIES PARENT_UNIQUE_NAME,
MEMBER_TYPE ON COLUMNS FROM [XXX_Test_TabularPro]
But it appears to be erroring out (would explain why I'm not getting any results in excel) when run against my cube:
Either you do not have permission to access the specified member, or
the specified member does not exist.
It's a interesting error message, I've actually never seen it before, and there's not much on the internet about it, just a few dead ends. I'm quite sure I don't have a permission issue, I can reproduce the error by running the query as an admin on that server. I think it's related to something in the query or the format of the cube but I'm not quite sure which is the issue, and I'm not super familiar with MDX. Has anybody seen this before? Is there something I can change with the cube to not have this occur? Is it a syntax issue with the query, if so why would excel generate an invalid query?
Another interesting item of note, I noticed that the search function for a leaf level hierarchy works in excel(as noted above) so I swapped out "I1 - Item Category" for "IA - Item Name" and the query runs without issue (of course we're now searching the leaf level), it's something about running this query on a non-leaf level in this case "I1 - Item Category" that is causing this error to occur.
Update 2
Ok I've made a bit of a breakthrough, I've altered my query to see if any combination of input would allow it to work, and I've found one, if I change my filter from "Per" to "GL" I get a result, it turns out that the query outlined above is actually NOT returning results from "I1 - Item Category", it's actually returning results from "[Item].[IA - Item Name].Members" which contains a distinct list of item name's.
I can actually demonstrate this in excel as well:
This makes no sense what so ever, nowhere in my query shown above(the query generated from excels search) do I mention the item name, and you clearly see what "[Item].[I1 - Category].[Category].Members" should be returning in the screenshots above(and what is returned by the multidimensional cube), it just doesn't in tabular, worst of all I captured(with SQL profiler) the query from excel on searching the item hierarchy of both my identical tabular and multidimensional versions of my cube and they generate the same exact MDX query with the only difference being the name of the cube.
I'm forced to come to the conclusion that if one generates two identical cubes(identical as possible), one being tabular, the other multidimensional, and run the above query on them(assuming this hierarchy exists), they return different results, and tabular one will return incorrect results.
Has anyone seen this issue before? I feel the tabular cube is returning a incorrect record set for the specified MDX, how would this occur, is there anything I could do to modify the query or cube to resolve this issue?
Update 3
The saga continues, one of the core questions I'd like to answer here is: Is this something specific to the cubes I generate, or does it affect all cubes, I believe I have the answer to this...
Steps To Reproduce:
Open Visual Studio, New Project, Select "Analysis Services Tabular Project", Next, Create, (A popup will display "Tabular Model Designer" I selected "Workspace Server" point it at my tabular cube server and set compatibility model 1200)
Add the following data to a CSV file or by putting it in a SQL table:
Category_Description Sub Category_Description LeafName
Professional 10 Series Filter
Performance 10 TTR GL
Professional 10 Series Series 1
Unassigned Unassigned AUTOMOTIVE
Performance 500 S RACING
Right click on "Data Sources" select "Import from Data Source", navigate through the menus to import the data source defined above.
As part of item 3 you should've imported the table listed in step 2, you should see this in your tables the new table from your data source:
Open your new table and create the following hierarchy:
Right click on your "TabularProject" in VS, select "Analyze in Excel", this should bring up a excel window
Pull the "Hierarchy1" hierarchy into "Filters", drop down this hierarchy in excel and attempt to search for "Per": You'll see that no results are displayed.
IMPORTANT Note: If I change the workspace to "Integrated", rebuild and process the cube, I no longer see the bug, it must be related to how the server is processing this model, in someway it must be different then how VS does it locally.
Ok, I think I finally understand what is occurring here, I checked my SSAS version number:
15.0.32.55
This is quite old, so I updated to "15.0.35.15" and it appears as though the issue is now resolved(search in excel now works), I believe this version upgrade introduced a fix that resolves this bug, most likely either this one, or this one.
I tested this with a slightly different environment. I used Power BI to build the model and there, it works like a charm.
I uploaded the model then to SSAS and tested again and it still works out for me. I am SQL 2019 an Power BI.
Finally, I tested with VS 2019 native developed model and workspace server. Also, this works out without any problem.
there are 2 different experiences i have seen while using "Query to PowerBI" from tools menu in kusto explorer. image of both
I am getting the fist one, but want to use second one(query? with additional details/options). How do i get it in second format
You can control the behavior of PowerBI query using Tools->Options->Tools->PowerBI Export To Native Connector.
We are reviewing in term of storing a business data into Sharepoint List againts tradional SQL database. We noticed that there is limitation on the view (5000 records) in Sharepoint List within Sharepoint itself.
My question is there any tools that we can view/edit/delete records for Sharepoint List as if like SQL Server Management Studio where you can filter the data and then delete/edit the data in bulk ?
I'm appreciated your input.
If Microsoft Access can access the list (as per above) and I assume that the SQL Management can access this also then? Is that correct?
Yes, you can increase the list view Threshold limit beyond 5000 but it is not a best practice and it is recommended that you should not alter this value, as it may degrade the performance.
Instead there are many ways to handle this like :
Create Indexed columns
Limit items on display
Create folders to organize items
Create filtered views (as suggested/commented by vinayak hegde)
Please refer these links :
https://support.office.com/en-us/article/Manage-lists-and-libraries-with-many-items-11ecc804-2284-4978-8273-4842471fafb7
https://blogs.technet.microsoft.com/quentin/2014/07/15/the-list-view-threshold-stop-dont-change-it/
https://technet.microsoft.com/en-us/library/cc262813.aspx?f=255&MSPPError=-2147217396#Throttling
SQL Management Studio cannot access list in SharePoint!
(Well, actually... you can access items with SQLMS directly in the tables in the database, but that is strictly forbidden by Microsoft and doing so breaks the support of the product and can cause unexpected behaviour and errors. Just don't do it!)
You can safely use the lists own Quick Edit mode, where you can do bulk editing similar to editing an Excel sheet.
Quick Edit can be done in a list with more than 5000 items.
Enable Quick Edit by going to
List settings > Advanced Settings > Quick Edit and tick "Yes" to allow items in list to be edited using Quick Edit.
SSRS Version 2008 (Not R2)
Hi all.
I am trying to implement custom security within a report being used for call center managers and agents. Here are my requirements:
Agents can see their own stats and no one else's stats.
Managers can see anyone's stats
I have a report that shows basic call center stats like # of dropped calls, on hold time, etc. The report has two parameters. One for #Date and one for #AgentID. We want to make sure the managers can view this report for any agent and the agents can see their stats and only their stats. I have tried a few techniques and would like to accomplish this within the report logic (stored procedure). My latest attempt involved capturing the current user's login (SELECT CURRENT_USER) and then bumping that up against a WHERE clause in the report's main SELECT statement. This seems to work fine in SQL/SSMS but does not seem to catch on when deployed as an SSRS report.
-- Sample user table
SELECT DISTINCT
ManagerID
,ManagerName
,LoginID
,'Manager' AS LEVEL
INTO #user_SOURCE
From dbo.AgentTable
UNION
SELECT DISTINCT
AgentID
,AgentName
,LoginID
,'Agent'
From dbo.AgentTable
UNION
SELECT
1
,'My Name'
,'mylogin'
,'Tester'
-- Then i have my simple SELECT statement that is inside a stored procedure and called by the report.
select top 1000 *
from dbo.CallCenterReportTable
where CURRENT_USER IN
(
SELECT
LoginID
FROM #user_SOURCE
)
The interesting thing is that i can do testing fine in SSMS, and i can even test it successfully in my local BIDS, but it only works in BIDS if i slightly adjust anything inside the report like page size, etc. Anything that would require a re-save of the RDL seems to make the security function as it should when viewing locally. That being said, the security will not work once deployed to the SSRS server. Even if I change the RDL slightly and redeploy, it does not work.
My last resort would be to create two reports that are almost identical. One would restrict use to only call center managers by AD role. The other would be open to agents and would utilize the USERID internal parameter in SSRS (WHERE USERID=#AgentID). I would really like to avoid having two reports if at all possible.