We have a sharepoint website and as part of functional process across the website where there are lot of documents been uploaded. Currently they are been stored into database which results in very bulky table in terms of size. My initial approach was to utilize sharepoint to store the documents into file library. Does anybody think database is the wiser options and why or any other approach which is performant and better to store confidential files?
Using a database for storing documents is not a recommended approach, not only it will have large size but will be hard when it comes to maintenance and performance.
If you have a SharePoint server, why not go with a library or multiple libraries to store documents. You will get the below advantages when using SharePoint.
1.Permission management : you can set up access to documents and choose who access what.
2.Search : if there is a search service running you can search through your libraries.
3.OWA : office web apps can be used to open documents on the browser.
4.Audits : You can enable audit logs to see who does what.
Remember, SharePoint is a CMS and there are other options like MMS etc, but it stores the documents in a database too, its designed well so you dont have to worry much about it. If you go with your custom solution you will have to do a lot of custom development and testing.
I never recommend saving files in the database. The easiest approach is to store them on the server in a directory and only save the file names in the database. This makes it easy to show them via a URL in a browser as well. Create a table with a column for the OriginalFileName and one for the ActualFileName. When i save a file to the server after its uploaded i usually change the name so you never have complications with duplicate file names. I use a GUID as the actual file name when its saved and save the original file name in the database along with the actual so you can get both back.
Related
Is Sharepoint my best option to replace an aging network of fileshares? There's approx 1TB of data residing among 3 fileshares (1 DFS, 2 NAS boxes). A document management system is in place for new things - the file shares are now just read-only archives/legacy. Our users would simply need to be able to search for and open the documents.
Users are finding it difficult to locate their documents in the file shares and windows search does not often help. Sharepoint was suggested as something which would play nicely with Office documents (99% of the content) and have a good search facility.
Not being a Sharepoint Developer or having had any training on it, I'm getting a little lost. I have set up a test server to try it out using SP2013. I have managed to index each of my file shares and have created a search page. However, results aren't consistent with the indexted items. I assume I need to somehow get the relevant metadata from the files but I have no idea how to go about this.
Could anyone suggest some resources for help on this subject (my searches have mainly turned up paid-for Sharepoint addons or outdated blogs) and any experience of doing something similar? Also happy for any suggestions on ways to achieve this using other software/platforms.
I went with Microsoft Search Server 2010 in the end.
Sharepoint is basically optimized to be a document manager. I think you don't need to buy or donwload addons.
For your problem, metadata are the key! You need to properly specify the metadata.
I give you the theory of a plan document management in SharePoint 2013 :
https://technet.microsoft.com/en-us/library/cc263266.aspx
A nice introduction to metadata :
http://fr.slideshare.net/gzelfond/document-management-in-sharepoint-without-folders-introduction-to-metadata
Be careful to use the Microsoft documentation for the beginning. From my experience, its difficult to start with this documentation because you have several things in it. There is also good books/ebooks that you can find easily to start well, and probably more simplified than MS documentation.
I'm looking at the architecture for a DW project and there will be the need for some manual collection of [structured] data eg the monthly accounting results from a country manager where they need to complete a form and fill in half a dozen values etc.
I really like the idea of using SP and InfoPath for this as it gives the security, the workflow and the customisability etc that mean it can be easily deployed as the client already has SP rolled out. The bit I am less clear on is how, technically, we might interface to the SP workflows and the forms themselves. Ideally the data would end up dropped into a database and we would use our [their!] standard ETL (DataStage, possibly sat on a linux server) via ODBC and pick it up like any other datasource but I am not sure what this requires on the SP side. The alternative would be to get at the XML of the individual forms and pull the info from there.
Are these appaoches feasible? What would need to be set up on the SP side in order to make this integration as robust and seamless as possible? Can anyone point me at docs/reading matter that might give me some more background info?
Thanks,
Dex
First up, accessing sharepoint's databases is never the answer to any integration question. You should treat it as a black box.
So, how should you get the data? Web Services + HTTP. SharePoint offers a large amount of Web services to get at the data you need. If you're working with IP forms, then ultimately you will need to grab the resultant XML file from the document library and parse it to get the data you need. The Web services can be used to enumerate the IP forms, and you can use straight HTTP to grab to xml file. This is probably the approach that would be offered by most experienced sharpepoint people.
I have a piece of data, a simple string containing the server name that the SharePoint solution is deployed to, that I retrieve from a configuration store in a helper method in a common DLL used throughout my solution. This helper method is used throughout my custom pages and web parts, to build a number of URLs, etc.
I would like to persist this string, and prevent it being repeatedly retrieved from the configuration store. My Sharepoint installation is currently on a single server, but will be migrated to a SharePoint server farm in the near future, so simply determining the server name of the current request, etc isn't an option. I have looked at caching as described in the best practices for SharePoint, but unless I use a coherent cache like NCache or Velocity/AppFrabric, I will again have issues when the move to server farm occurs. Given that this is a single string, adding a full caching solution such as Velocity seems like overkill.
Does anyone have any suggestions on the best way to persist this data? Am I missing something obvious here?
Thanks, MagicAndi
Look into using the Property bag that is exposed by all major SharePoint objects to persist information. i.e.
SPFarm.Properties
SPWebApplication.Properties
SPSite.Properties
You could:
Store the string in web.config. You can programatically change the web.config on all the farm's webservers using a SPWebConfigModification
Store the string in a SharePoint list and read from it. I usually use this solution because I have more to store than a single string. The list is 'available' on all web servers and I cache its values in an ASP.NET cache object. Someone made this concept into a solution you can download and install: SPConfigStore
This article may be of use to those looking at storing configuration data in SharePoint:
Six ways to store settings in SharePoint
You can use SPPersisted to do such kind of operations.
To quickly summarise my question:
Is it feasible to programmatically change the name of a directory (with both files and sub-folders) in SharePoint? I am expecting that users will have files checked out on at least some occasions what I am attempting the rename.
The background:
I am currently contracting for a company that produces web based software (ASP.NET) with a configurable document management system. The system can be configured to use different underlying systems, with the most common environment being SharePoint (WSS 3).
I have been assigned a task to extend what has to now been a fairly simple system (simply output files into a fixed directory structure, occasionally read). Having never worked with SharePoint before I am doing some research on best practices, and am attempting to work out what is viable. At this stage I do not have access to a testing environment myself, so am limited to reading up online.
One request is to have the directory structure reflect the name (as one example) of the current client - so all documentation for a client will be in one place, and can be accessed externally via SharePoint or other compatible applications. The specification cites that if the name of the client changes then the directory structure should immediately update. My concern is that this will either directly cause errors (eg. Permission denied) or indirectly cause errors (loss of work for users who have externally checked out files).
As a follow up question if there are concerns with the above, is there a better way to implement the above? I have looked at suggesting the users use views to access the structure in SharePoint, however there is a concern from our BA that users will not be able to directly upload new files into this structure.
Thanks
The issue with Folders in SharePoint is that they are not really folders in the way you would expect of a file system. All files in a SiteCollection are stored in one big-assed table on the Database (checkout the AllDocs table).
I cannot categorically say it is safe to rename the folder without doing a bit of testing, I know that the folders "name" is not the key to accessing the document, despite it appearing to be based on the Url you see in the browser.
The best bet is to do a quick test, but I am pretty sure that your plan will not be a problem.
The potential issue is if any Content Query Web Parts etc rely on specific folders to exist or if any other "code" or "pages" look for that folder and not the folderId.
Save the content of the list before you "attempt" it in production. You don't want to loose data.
Checked out documents will still work the way you expect them to.
You may however have to run a crawl again.
I'm using the built-in Domain Catalog database to list all the databases on a particular Domino server. I'm creating a custom view to show certain information about each database. What I'd like to have is a column that displays the creator of each database. However, if the Domain Catalog is keeping track of this information, I can't find it.
Is there a field in the Domain Catalog that provides this information that I just haven't been able to find? Is there some other way I might find this information and get it into this view? #DBlookup and related functions don't work in column formulas.
That information is not stored in the catalog, and is probably not stored in the database either (It's not shown on any of the property tabs).
You would probably need to get/write a server add-in to monitor database creation and store that data somewhere. Then you'd need to account for databases created by adminp/replication - your add-in might pick them up as having been created by a server.
This question was also asked in the R4/R5 forums in 1998 and received no answer.
Interesting question. There is no such attribute for database, but you can dig for some clues.
New databases: use NotesNoteCollection and look for some specific design element (icon, for example) and look for first element in $UpdatedBy field.
New copies/from templates: above mentioned method won't work. It will return info from original/template, not current database. In this case, try using Created property of DB and check user footprints after that date - in ACL log (he probably altered ACL immediately after copy), new design elements (probably made new view, folder, agent...) or profile documents.
What Frantisek said. Looking in the log archive (ugh!) may tell you who deployed it, but in a well run environment that won't be who developed it. A list of $UpdatedBy(0) for all design notes should give you a good idea. The catch will be that it mayl be people who left the company years ago. : )