We are having issues with the MOSS 2007 Web Service. Specifically, the Query/QueryEx method of the API.
We are using the SQL Syntax to query sharepoint, and for most cases, our search execution time is very fast. However, when we add filters and sorts, things start slowing down. In some cases we even get an error.
For example, this MSSQLFT query will give a System.ServiceProcess.TimeoutException exception about 50% of the time. The timeout will occur around the 10 seconds mark.
SELECT WorkId, Rank, ... , PerforceFolder, PerforceDateSubmitted FROM SCOPE()
WHERE "scope"='Tech_Depot' AND (FileExtension = 'cpp' )
ORDER BY PerforceDateSubmitted, Rank DESC
Is there any settings / query parameter / etc... we can use to allow a bigger SEARCH execution time on the sharepoint back-end?
This could have many causes:
The property used in the search is not indexed, therefore, the search takes longer
The result set is too big, try specifying a row limit
These tools can help you with development:
- SharePoint Search Service Tool`
- SharePoint Search Bench
Hope that helps.
http://msdn.microsoft.com/en-us/library/microsoft.office.server.search.query.query.timeout.aspx
believe it or not this 10 second limit is hard coded. The only way round it is to write your own version of the web service. I've done this and the results are here:
http://eliasbland.wordpress.com/2009/12/10/search-webservice-for-sharepoint-search-server-with-configurable-timeout/
Hope this helps,
Rupert
Related
Is there a way to set a max run time or a timeout factor in Power Query so that after a specified period the query would terminate itself regardless of whether it was successfully executed or not?
This is important for me because I have built various queries at my workplace that usually run fine (as in I have been running it daily without issues for months and years) but occasionally, they would hang (likely because of clashing with another process on the server at that moment, when the server was under heavy load) and keep making read requests on the server indefinitely - One time IT have told me they logged more than 7 million reads from my machine into the database within a few hours. In cases, these have caused the servers to crash which leads to extensive downtime.
So I would like to know if there is any setting, or any thing that I can build into the query itself to ensure it terminates after a certain period of time.
I'm proficient with the M Power Query langue.
Thanks.
[Update 1]
Thanks Alexis for the suggestion below regarding setting a CommandTimeout value when coding the connection. It's a great pointer.
I'll try it out, do some tests and report back if it conclusively fixed the issue or not.
But in the meantime, I've done a bit of digging into Microsoft's Power Query documentation and found that the CommandTimeout argument itself already has a default value of 10 minutes built into it, so theoretically even if we didn't specify that argument, the query should have terminated itself. But that wasn't the case. It ran for hours.
I wonder if it is a bug with Excel version of Power Query? Because I do use Power Query within Power BI as well, and over there I haven't seen it crashing and hanging yet (admittedly I've been using the Excel version more frequently than I did Power BI).
However, if anyone has any other suggestions on potential fixes for this problem, that would be much appreciated. Thanks.
I found a pretty decent answer to this here. Here are the steps posted on that forum:
Have the Power BI Desktop file open and in Report View
Click on the arrow for "Edit Queries" (in the External Data section)
A dropdown will appear - then click "Data Source Settings"
Data source settings pop-up window will appear
Click on "Change Source..."
Another pop-up will appear
Click on Advanced Options (a drop-down of sorts will appear within the pop-up)
"Command timeout in minutes (optional)" will be the first option
Enter a value - I chose to enter 60 minutes but feel free to enter any value
Then apply the query changes and wait till the refresh is complete
This was written for Power BI, but it works in the Excel query editor as well. In summary,
Open Query Editor
Choose File > Options and settings > Data source settings
Select your source and click on Change Source...
Expand Advanced options and enter a Command timeout value
When I tried this with a connection to a SQL server it added a CommandTimeout argument to my Source step. You can just use this code instead and skip all the clicking:
= Sql.Database("server", "DB", [CommandTimeout=#duration(0, 0, 15, 0)])
Doing it via the Data source settings may be preferable if you aren't connecting to a SQL server as the parameters might be different. E.g.
= Web.Page(Web.Contents("URL", [Timeout=#duration(0,0,15,0)]))
or
= OData.Feed("http://some.url/service.svc/", null, [Timeout=#duration(0, 0, 15, 0)])
Is there a way to have user selected records remain selected as the pages are changed in the view? Currently, when changing pages in the view, the selection is lost.
For example, the user is looking at the Accounts entity, and wishes to select a few records from the first page of results and other records from subsequent pages.
I have explained that this is standard behaviour and that they should further filter their results but they are insisting that I try to find a solution.
There isn't a supported solution to your problem other than writing custom web-resource pages that will do exactly what you need.
I'm sure you've already told them to set their "records per page" to 250 in their Preferences.
In CRM 4.0, I once figured out where this "records per page" setting is stored in the database and I was able to change it to 5000 directly in the database. It did work (I think I had to iisreset as well), but it is obviously unsupported and could cause massive performance issues.
hi I'm having troubles with the SharePoint list, I've got the list connected to a Visio, and when I'm on-premise, it update fast, I mean I change the list, click refresh in the Visio app and it's updated, but on the Visio web access from SharePoint, It takes too long, I can be pressing refresh, but its like it has a timer, every 2 or 3 minutes it updates, every change I do so far. The problem is that I need to be instant, sometimes its is instant because I luckily change the list when its about to refresh.
Is there any configuration in the server to me updates that fast?
English is not my native language, so I'm sorry
If you want your changes to be shown instantly, you can set Minimum Cache Age to zero in SharePoint:
http://technet.microsoft.com/en-us/library/ee524061.aspx
Note that default value (a few minutes) provides a better rendering performance in multiuser scenario.
Also note that this seetting does not seem to be available in SharePoint Online / Office 365 (please correct me if I am wrong).
My boss has asked me to look into setting up a copy of sharepoint on our server and creating a dashboard that allows employees to view their tasks, punch in/out, etc.
At this point, I have VERY little experience with sharepoint. I've seen sharepoint tutorials that seem to be simple non-coding setups & I've seen some that involve creating sharepoint pages from code. What's the best approach for creating this time entry page? Is there something already built that I can just plug in and modify or is it best to code it from scratch? Just looking for some good starting points.
Thanks
Don't code from scratch, you could find a site template (.stp) somewhere which is free or costs 50 CUR and which you can install in your SharePoint server and modify further to your liking.
For example see whether "Case Management" below satisfies more than half of your (boss) requirements or not: http://sp2010teamplates.codeplex.com/ If not, Google for more.
I agree with #RoManiac. Don't get to code from scratch.
As an alternate, SharePoint is a great platform for quickly creating data entry / manage data apps like the one you mentioned using "Lists".
Consider every SharePoint list as a "Virtual table" in an SQL Server with CRUD screens getting auto generated. That means that if you create a list (table) called "TimeSheetEntry" with fields (Columns) called Project Name (Text), Project Task (Text), DateWorked (DateTime), HoursWorked (Integer), SharePoint will automatically generate Data entry screens for this list. You can expose this list to your end users and they can start entering their time sheets. CreatedBy field is an automatic field that should track who entered the data.
You can create views (Like SQL views) that allow users to see only their time records.
Hope that answers
Cheers
VJ
I'm trying to use SQL, REST or the Jira Api to find out what the velocity of a project is at any current moment in time. Right now I am trying to find the total number of story points assigned/completed for each sprint and version and from this calculate the velocity of the overall project.
The problem is that Greenhopper is an addon to Jira and does not change the Jira database in anyway, so it must store this information about scrum/agile projects elsewhere. Any ideas where this information might be located?
Thank you!
I finally worked it out!
So here is some of the techniques that we use to access data from Jira.
SQL
This SQL statement for example counts all the issues from every point in Jira for each priority.
SELECT
project.ID AS id,
project.pkey,
project.pname AS projectname,
jiraissue.PRIORITY AS priority,
COUNT(*) AS total
FROM jiraissue
LEFT JOIN project ON jiraissue.PROJECT=project.ID
GROUP BY project.ID,jiraissue.PRIORITY
ORDER BY project.id
Also check out... http://confluence.atlassian.com/display/JIRA041/Example+SQL+queries+for+JIRA
REST Api
I have not tried this properly but there is also a set of REST api that you can use to access some of the data from Jira. This documentation is available here: http://docs.atlassian.com/jira/REST/latest/
An example link: https://JIRA_LINK/rest/auth/1/session
Java
Also another useful link for JIRA Java api: http://docs.atlassian.com/software/jira/docs/api/latest/
I use an older version of jira & greenhopper.... but in that version, greenhopper allows you to choose the field you "burndown" by. In my case it's a field (i believe a custom field) called "Likely". So it should be there in the DB/API somewhere. good luck.