Link to home
Start Free TrialLog in
Avatar of mkmks
mkmks

asked on

Sharepoint, WebDAV and timeout

Hi all,
we need to access data in a Sharepoint database from outside an app, and the app developers gave me instructions on how to access those data via WebDAV. But they also told me that some 'folders' within the data structure are too big and WebDAV (or Windows) might throw an error due to timeouts. And here we go - some folders are fully accessable because of less data content, but our main folder is not. We try to access the file structure either by explorer or by command line. Both fail on large folders.
But I hope that there's a way to adjust some timeout values - in SQL server (Sharepoint) or in OS. Any ideas ?

TIA
Michael
Avatar of Vitor Montalvão
Vitor Montalvão
Flag of Switzerland image

Can't you just query the database directly with SSMS?
Avatar of mkmks
mkmks

ASKER

Vitor,
I have no idea which table(s) i should try to query because I'm not a sharepoint insider. I was given just an URL/URI to use for WebDAV. The sharepoint database is open in SSMS and all tables are visible and accessible for me (being logged in as SA). I don't know if there are 'standards' in sharepoint data population. The database here has the name 'WSS_Content'. Could you please give me an idea which table(s) I should try to query?

TIA
Michael
Unfortunately I don't have much knowledge with SharePoint.
Would this article help?
Avatar of mkmks

ASKER

Vitor,
thanks for the link, this is a quick and useful overview. I tried to find out which of those tables are 'huge', and I found the [AllUserData] table having over 2 million records, the [AllDocs] having about 1 million records.
When I try to execute a full SELECT * FROM table, it executes within 2 minutes for [AllUserData], in 1 minute for [AllDocs].
The timeout doesn't seem to appear within the database engine (for the basic queries, as long as I don't join some related tables).

Michael
More information about the tables can be found in MSDN.
Avatar of mkmks

ASKER

After analyzing some tables, I found that there is a very large table called [mssqlrbs_resources].[rbs.internal.blobs], which seem to hold some binary data (or at least references to data). This table has more than 18 million records. I can query this table (SELECT *) in SSMS in less than 3 minutes.
Trying to access the largest folder from within WebDAV issues an error in less than 10 seconds. Error message is 'Windows can't access this disc. The disc might be corrupt. Make sure that the disc uses a format that Windows recognizes. If the disc is unformatted, you need to format it before using it.'

This is only with the largest folder. Other folders with much less content work. I dragged a PDF into some object's archive in our application and this document appears in the WebDAV folder immediately.

So basically it works. I just need to find out why it won't with large folders and how to workaround it.

Michael
Do you know the size of the folder?
Avatar of mkmks

ASKER

The only information I can get is the size values from database properties. Here, the WSS_Content database is listed with 413,203 MB and the RBSFilestream has a size of 278,130 MB. Gives a total of about 700 GB.

Just for information: This database is used mainly as some kind of archive system, where users drag files into categories, like incoming invoices etc. to orders, photographs to graphical plannings... Some files are graphic (.jpg/.tif), some are .pdf, others are .msg when users drag complete mails into the archive. And we need to access the file structure from outside the application.

Michael
I'm asking because this might be some kind of WebDAV's limitation. Maybe it can't handle big files.
Avatar of mkmks

ASKER

The files itself aren't that big. Maybe there are some 'bigger' graphic files, but I guess these are not more than 20 MB each. If WebDAV treats folders including their content as file, you could be right.
I'll ask our software developer if they have some idea regarding file or folder size limits. But I doubt they have any clue....

Michael
ASKER CERTIFIED SOLUTION
Avatar of Walter Curtis
Walter Curtis
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of mkmks

ASKER

Walter,
please note that we don't want to change data in the sharepoint database - neither by SSMS, nor by WebDAV. We also won't query data by SSMS. This was only to see how big some tables are and how fast an unconditional query could be.
Our goal is to access all the data (in the worst case without the original application) by WebDAV - as a file structure. This way we would be able to copy one or some files from the data store to our file system. This is due to fiscal rules and requirements in Germany, and the application doesn't comply with those rules entirely.

And thanks for the useful links :)

Michael
Thanks for the information. Glad to hear you won't be touching the database directly. Using WebDAV uses IIS so you may be able to adjust the timeout values there to improve performance.

Viel gluck...
Avatar of mkmks

ASKER

Thanks Walter :)

Do you know which site (or application pool) is used by WebDAV for database access? I have 3 of them - 'SharePoint - 80', 'SharePoint Central Administration v4' and 'SharePoint Web Services (Root)'.

TIA
Michael
SharePoint - 80 is your SharePoint site. The other two are for the system and administration.
Avatar of mkmks

ASKER

Well, I tried to take a look for the log files, and there's really a bunch of data logged! I could narrow down my failed accesses to a few log entries. It doesn't seem to be a timeout issue, because access fails within a few seconds (4-7 seconds) and all timeouts I could find are set to larger values.
The logged entries contain sc-status=207, sc-substatus=0, sc-win32-status=64. Afaik, the 64 is the numeric error code for the displayed error text 'Windows can't access this disk, the disk may be corrupt...'.
The logs don't give me an idea what the source of my problem is. But maybe the log entry could help to better narrow it down.

Michael
Information is accurate and correct. The information about querying the data directly with SSMS is a very risky approach when dealing with SharePoint and should never be recommended, therefore no acknowledgement of correctness for those well intended answers.