Owssvr.dll

[Hedvig Horning]

Iget back an xml-based list of field metadata for the default view and a list of records in the list. But when I try to use another guid for a separate list, I get an empty response from the web server. It's a 200 response code, but the other headers look like:

1. That supplying GUID in the querystring of your URL works for one list and does not for other is probably because the lists are on different sites. Verify that the sitename is correct and that GUID is a List ID indeed.

Be wary of the fact that, however, above applies to both SharePoint 2007 and 2010, for SharePoint 2010 additional measures might be required depending on context from which you execute commands on owssvr.dll.

2.query=* is not a filter parameter; it shows schema as well as data for all available columns in the list, including SharePoint internal columns, which normally you never get to see in ways other than programmatic access.

So I have used owssvr.dll before to export excel documents of lists etc on the fly but the other day when I was exploring InfoPath workarounds for SharePoint lists (related to issues with Managed Paths and a bunch of other things) I found out that there are even more functions to the wonderful URL protocol!

This is specified as the source in a new data connection which retrieves data. Complete the data connection wizard (after adding the url) and you should now have the SharePoint data available for use in the InfoPath form (this can be used in expression controls, drop downs and other fun InfoPath controls).

To retrieve the list GUID or the view GUID for use in the url command simply navigate to the list of choice, select list settings and in the top URL bar will be the List GUID (converted for web etc) and if you scroll down to where views are listed in list settings you can click on any specific view and you will get the view GUID showing in the top URL bar (again converted).

For any SharePoint list, when I click on the 'Export to Excel' button on the 'List' ribbon, I am prompted to download the owssvr.dll file. When it download it will download as owssvr.dll instead of owssvr.dll.iqy. When I try to open owssvr.dll, I get the following error in Excel.

Should we, who use SPServices, be concerned at all with Microsoft recommending not to use either the ASMX web services in SharePoint 2013 ( -us/library/office/jj164060.aspx#DeprecatedAPIs) or the owssvr.dll (I used this one a lot when doing InfoPath stuff) for development purposes?

That said, deprecated is deprecated. If you build your solutions with the data access layer separated out from the business logic layer, you should be able to replace the calls if and when it becomes necessary.

I am not aware of any official specific time frames for the SOAP services going away, and the Product Group would need to give us a good, long lead time because lots of code depends on it, SPServices or not. Many people have built managed code-based solutions which use the SOAP Web Services as well. GetListItems is a workhorse operation no matter how you build your solutions.

The link on technet is blank. I've tried editing DynamicsHelpViewer.exe.config file in client bin folder. When i run Filemon I see AX client trying to access a non-existent .ini file ("DynamicsHelpViewer.ini").

"The Module DLL 'C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\isapi\owssvr.dll' could not be loaded due to a configuration problem. The current configuration only supports loading images built for a x86 processor architecture. The data field contains the error number. To learn more about this issue, including how to troubleshooting this kind of processor architecture mismatch error, see go.microsoft.com/fwlink

2 - Copy and past the URL from System Administration > Setup > Help System Parameters dialog and paste it into your IE and navigate to the page. You should get a page with the supported service definitions.

I then installed the Help Server using the new site I just created and changed the Help Parameters in the system as laid out in your answer. When I restart AX and open the Help viewer, I get a "Unable to connect to Help server".

3. Enter the URL of the service that you want to use eg :/DynamicsAX6HelpServer/HelpService.svc. If the Help server is installed on the default port (80, you can ignore the portnumber part of the URL.

3- Click the Feedback link on the left to navigate to the feedback area, and click Submit Feedback to enter the information and log your feedback. You will need to complete a survey prior to your first feedback submission. *Which bug form should be selected?

4. After you create your feedback item you can attach a file to it. Screen captures are most helpful in illustrating what you've done as well as any error messages. Attach any relevant log files as well.

NOTICE: Due to this being a Beta release there will be no formal support provided. Your feedback will be reviewed and you may be contacted by Microsoft if more information is needed regarding your submission.

Since the product has not yet shipped, we are unable to provide any additional information at this time. My assumption is that the documentation will be ready by RTM, so we may have to wait until that time to determine more on this issue.

As you are aware the gateway to doing anything in SharePoint is the SPSite object. In order to get to any other objects that reside in a site collection such as SPWeb, SPList, SPListItem, SPFile and others we first need to obtain an SPSite and there is a very good reason for that. Every SPSite instance holds a reference to the unmanaged WSS world in the means of a field member of type SPRequest which is called m_Request. The internal SPRequest class has an unmanaged reference to a COM object called SP.SPRequest and having a ClassID of BDEADEE2-C265-11D0-BCED-00A0C90AB50F which is implemented in and exposed by the OWSSVR.DLL class library.

ISPRequest is actually a COM interface and the public SPRequestInternalClass from the Microsoft.SharePoint.Library.dll is a wrapper to it. The ISAPI extension /_vti_bin/owssvr.dll can be used to do various things as documented in the Windows SharePoint Services URL Protocol.

If you try to allocate too many SPRequest objects (create too many SPSites) without releasing them you will start getting medium severity trace messages in the ULS Log similar to the one below:

} Additionally to this the SharePoint Object Model may be also caching the opened SPSites when running in a web context. This caching is done with the help of the SPRequestContext class which single instance is stored in the HttpContext per server thread that processes the request.

When you are using SPUtility.RunWithElevatedPrivilegies() this will simply revert the current user identity to the identity of the current application pool, and if this identity is not a farm administrator then your SPSite _will_ be cached in the SPRequestContext. This is done when the SPSite object is created:

As you see one of the classes I added on the above diagram is the SPFeatreManager class. This class can be actually called from the unmanaged world to activate features when you are provisioning a WSS site and this is when a cached SPSite may get reused. Here is what will happen every time you create a site or a web from a Web-based SharePoint application (web part, aspx page or SharePoint itself) if the WSS site definition you are using has some features to be activated:

Now if you are using custom site definitions and depending on how complex are they i.e. how many features do you have and what they are doing, in some cases because the cached SPSite will be reused, you may get some very weird errors particularly when trying to provision two sites at the same time. Some of those errors which I have seen at least a couple of times each include:

Also remember that you may be getting those errors for a different reason that is completely unrelated to the SPRequestContext cache. For example if you really are trying to reuse SPWeb or SPSite on a different thread or if you are not disposing properly the SPSite/SPWeb.

And finally lets recap the story about the SPRequest. Almost all read/write content/metadata operations that you do using the .NET SharePoint object model use unmanaged class to do the job. This unmanaged class is called SP.SPRequest and is used from .NET via the SPRequest internal class. The class is implemented and exposed by the OWSSRV.DLL library and has almost 400 methods. Because the SPSite and SPWeb objects have a reference to unmanaged objects you must keep the number of SPSite/SPWeb objects that are active at the same time to a minimum and should dispose them as soon as you have finished using them. You can monitor the creation and disposal of SPRequest objects via the ULS log. In order to minimize the number of SPRequests used in a HttpContext application, SharePoint uses internal cache. It is possible your SPSite objects to be reused when you are creating a site or a web from a web application which site/web is based on a custom WSS site definition that contains custom feature receivers. In rare cases you may be getting errors because of this so if you are using custom WSS site definitions then keep the complexity of your custom feature receivers to a minimum. Consider creating your sites from a non HttpContext application such as an STSADM command, Windows Forms application or a OWSTimer job.

3a8082e126