I'm new at sharepoint and having and issue in an existing site, users are asking a link that appears to be there but is not any more, so looking in database table AllDocs and filtering by DirName I see the files in database but in sharepoint site does not exists so how can I fix this so it shows in the web site?
Thanks
This is the solution I implemented if someone have a similar issue some time: I wrote a program that extract the files I needed from Content database (AllDocs and AllDocStreams tables) and save it to my computer, after that I uploaded the files again to sharepoint.
Related
I have a windows form application that requires users to log in to access the information. I have created a local compact database file for the credentials to be stored. I added the database file to my the folder but when I open my application and try to log in it tells me that it cannot find the database file.
Should the file be stored on a different folder, or should I need to install an instance of sql on the user computer.
This is my first deployment so I am not sure how to go about it. I have done some research on the subject, but it does not seem related to my issue. The help section of Intallshield was not clear either.
I am looking for some resources on how to accomplish this.
I figure out the issue, in order to work all files, including the database files need to be dumped under the userprofile folder.
I've upgraded a SharePoint WSS 3.0 farm to SharePoint 2010 Foundation.
Now I got a strange problem in a web part that modifies and creates Content Library files.
The user is only allowed to modify a file if he also got Contribute/Full access on site level (might be enough to have these permission on List/Library but I haven't tried). The user already got contribute permissions on the parent folder and on the file (inherits).
Another problem on the same site but on a different Library. All users on the site can read all files in this Library but when i try to copy a file from one list to another using the following code i get access denied when OpenBinaryStream is executed.
SPFile newFile = SPContext.Current.Web.Lists["ToLibrary"].RootFolder.Files.Add(folder + "/default.aspx", oldFile.OpenBinaryStream());
Both the problems only occurs on the upgraded farm and works fine on the WSS 3.0 farm.
Does anyone have any idea what's going on?
I had a similar issue which turned out to be a setting for lists/libraries. In the Advanced Settings for a list/library, there is a section labeled "Item-Level Permissions" - this setting can be used to deny access for anyone without Full Control rights to the item. Unless there is a specific need, Read Access should be set to Read all items and Create and Edit access should be set to Create and edit all items.
I had the same issue and resolved it by going to Site Settings > Edit Permission Level > and giving the 'Contribute' permission level the ability to 'Open Items - View the source of documents with server-side file handlers'
I've got a DotNetNuke system (v 5.6) that's hosting several different portals, and I'd like to move one of them to another hosting provider. What's the easiest way to do this?
Every web site I find that claims to explain how to move a DotNetNuke site essentially says "Copy the entire database over to the new system." That's great if you've only got one portal in the database, but I've got a dozen of them. I only want to move one portal, not all of them.
Exporting the site to a .template is another popular suggestion. This exports the structure of the site (all the tab definitions, for example), but it doesn't include any of the actual HTML content. As such, that's essentially worthless.
There must be a reasonable way to do this short of trying to strip one individual portals data out of every single DNN table. Right?
When you export a site template, you can include the content of the site, as well (for the modules that support portability, which includes the standard HTML module). This is how the default site template has all of its content. When you do this, there will be a .template.resources file that you'll need, as well as the .template file.
The other option is to do a full backup and restore, and then remove the other sites once you've restored. If you have significant content in a module that doesn't support portability, I think this will be your best bet.
FYI, I did find a solution from someone over on the DotNetNuke forums.
Create a 2nd version of that install, then delete all the other
portals. Move the install with the one portal. We've done this several
times with installs with lots of portals and it works just fine. Yeah
there's still some noise left in the db, but it's a quick and
effective way of doing things.
Edit note that this will give you an install with 1 portal. You can't detach a portal from one install and reattach it to an existing
install (well, you can, but basically you have to export the portal as
a template and that isn't 100%)
This is the approach I took, and sure enough, it works.
In a nutshell:
Mirror the files for the web site to another server.
Mirror the DNN database to another server.
Log in a Host on the new setup and delete all the portals but the one you want to migrate.
Delete any module definitions that are not in use by the remaining portal.
Open up your favorite SQL tool and delete any entries in the Users and UserProfile tables that no longer have a matching row in the UserPortals table. DNN does not remove these by default, which is frustrating.
Hop in to Windows Explorer and delete all of the Portal folders you no longer need (ie: /Portal/1, /Portal/2, etc.)
Back up the database using Enterprise Manager to create a .bak file
Make a .zip of the entire DNN installation folder.
You now have a .bak that contains the database and a .zip that contains the files. Send those off to the new hosting company, and you should be all set. Just make sure to update your web.config to set the connection string properly to point to the new database server at the new hosting company.
It's just that easy. ;)
Recently my Windows Sharepoint Services 3.0 server went down, and all I have is the mdf and ldf. Am I correct in assuming that the aspx files are embedded in these database files? I have attached the db to a local sql, and have access to it. However, I need to access some of the aspx files that were created in sharepoint. How do I go about extracting these files? I've been using MS SQL Manager Studio Express to sift through the data. However, the ASPX pages that have the real content (not the structure of SP) is needed.
Thank you
Yes, all your content is in the content database. Don't bother trying to pick apart the database structure - there is an easier way:
You will need a WSS 3.0 farm, perhaps a clean install on a new machine. Then attach your mdf/ldf files in SQL Server (use Management Studio or T_SQL). Then create a web app in WSS and attach the database to the web app in SharePoint Central Administration. You will probably also need to change the site admin in Central Administration. You can then go back into your site and get at your aspx files.
You need to restore your site from the database. There is no need to extract files from the database. Once you set up a site, all content will appear again.
I haven't done this for some years, but articles like KB 833797 show you the basics
It's also effectively the same as a SQL Server migration so this too
And some Google links
I have an active sharepoint farm already built and I am wanting to create an exact mirror copy of the sites and all its contents into a different domain for develpoment and testing. The share point site is live and can not be brougt down I have tried using sharepoint designer to migrate the sites but this comes up with a multitude of errors. I have also looked at stsadm.exe but I am not sure what commands i need and can I use this on a live site.
I have also tried the inbuild backup restore tool within sarepoint but this sill comes back with an error. I am using sharpoint office 2007 with sharepoing central admin 3.0.
Thanks
Andy
It is possible to create a "live" backup of the content database in SQL level (do not try to move configuration database). This can be don by SQL management studio.
Then copy it to the other domain, restore SQL database and attach it to sharepoint.
Do not forget to stsadm -o migrateuser -oldlogin <DOMAIN\name> -newlogin <DOMAIN\name> [-ignoresidhistory] to migrate the users.