here we go, just some simple upload code that uploads documents into a document library.
It also checks if the same file exist in the destination library before upload.
SPSite site = new SPSite("http://mysharepointsite");
SPWeb web = site.OpenWeb();
web.AllowUnsafeUpdates = true; // i always add this in to prevent security errors
Stream fStream = postedFile.InputStream;
byte[] contents = new byte[fStream.Length];
fStream.Read(contents, 0, (int)fStream.Length);
fStream.Close();
string newFilename = System.IO.Path.GetFileName(postedFile.FileName);
SPFile fileExist = web.GetFile(destFolder + "/" + newFilename);
if (fileExist.Exists)
{
Response.Write("<font color='red'>Error: A file exist with the same filename. Please Rename this File.</font><br />");
}
else
{
web.GetFolder(destFolder).Files.Add(newFilename, contents);
completed.Text = "<br /><font color='green'>Successfully uploaded '" + filename + "' to: " + destFolder + " </font><br /><br /><br />";
}
MSCRM-Admin Sharepoint document library upload, Sharepoint, sharepoint upload, wss, wss upload
After doing some development/webpart work on our sharepoint server, the log file to grew to 3.5GB - we have 0.99MB of free space of a 20GB disk (this is a dev/test Virtual server).
Anyway after searching, i came across this blog: http://blogs.vertigo.com/personal/steventap/Blog/archive/2007/01/19/managing-sharepoint-2007-moss-application-log-size.aspx - thanks Steven!
Apparently you can manage how SharePoint logs it’s events:
The Problem:
SharePoint 2007 by default stores 48 hours worth of logs in a directory buried in your program files folder (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS\ !). Very few events get logged to the application event log.
Expect each log file to be at least 200 megs (a log file being generated every 30 minutes by default), or 19 GB of space at the minimum being used by SharePoint logs.
Solutions:
Go to your central administration server web site, and open up the Diagnostic logging:
Central Administration -> Operations -> Logging and Reporting -> Diagnostic logging
In the Diagnostic logging page, focus on the following categories:
- Event throttling: how much you log
- Trace Log: where you store the logs
Event Throttling:
- For a Dev/staging server server, you should log all or “medium events”
- For a Production server, only log errors
- The search crawler will take up most of the log space
Trace Log:
- By Default, logs are sent to: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS\
- Store the logs on a separate drive so that at worse your drive gets full and your application stops logging, but still functions. It’s a pretty standard practice for SQL server installations for instance.
- Reduce the number of log files. The default is two days worth of logging (96 files x 30 min intervals). See if this is too much for you; it might depend on how much you chose to log in the Event Throttling.
MSCRM-Admin Sharepoint disk space, logs big, massive logs, purge logs, Sharepoint
I too have dreaded this error - it means nothing to me and just pisses me off especially when developing webparts.
You can remove this by opening the web.config,
Search for <customErrors mode=“On“ /> and change it to <customErrors mode=“Off“ />
To see the call stack and trace information. Find
<SafeMode MaxControls=“200” CallStack=“false” DirectFileDependencies=“10” TotalFileDependencies=“50” AllowPageLevelTrace=“false“>
and change the value of “CallStack” to true.
<SafeMode MaxControls=“200” CallStack=“true” DirectFileDependencies=“10” TotalFileDependencies=“50” AllowPageLevelTrace=“true“>
Finally, don’t forget the set debug=”true” in the web.config or it won’t matter whether you put the assembly in GAC or not without it the breakpoints will turn all nice and red, but it won’t stop anywhere. If you want to enable generation of debug symbols for just in time compilation Find
<compilation batch=“false“ debug=“false“>
and change it to
<compilation batch=“false“ debug=“true“>.
Although none of these are appropriate for a production environment, but they all make development much easier.
-Ibrahim Sukari
MSCRM-Admin Sharepoint error, Sharepoint, unknown error occured
Hi All,
I want to publish the backup script i use to backup sharepoint every night. It is a very basic BATCH script (.bat) which uses STSADM sharepoint command line tool to backup sharepoint then uses winrar to zip and compress the file in date format then copy to the destination drive.
# setting a the variable stsadm as the location of the command line tool
set stsadm="C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\stsadm.exe"
# set the variable %todaysdate% as todays date
set %todaysdate%=%date:~7,2%_%date:~4,2%_%date:~10,4%
# make a directory for today's sharepoint backup
mkdir E:\Backups\Sharepoint\File\%todaysdate%
# we are using the STSADM tool to make a full sharepoint backup
%stsadm% -o backup -directory E:\Backups\Sharepoint\File\%todaysdate% -backupmethod full
# this is zipping up the sharepoint backup as SharepointBackupXX_XX_XX.rar from contents of E:\backups\sharepoint\file\
"c:\program files\winrar\winrar.exe" a -u -r -m5 "E:\Backups\Sharepoint\Zip\SharepointBackup%date:~7,2%_%date:~4,2%_%date:~10,4%.rar" "E:\Backups\Sharepoint\File\%todaysdate%\*.*"
# this is copying the contents of "ZIP" to the destination backup drive which is mapped as S:\
xcopy "E:\Backups\Sharepoint\Zip" "S:\Sharepoint\" /Y /E
Any comments or suggestions are welcome.
-Ibrahim
MSCRM-Admin Sharepoint, backup backup, bat, batch, compression, Sharepoint, winrar, xcopy, zip
You recieve the event (17137) in the eventlog when you migrate the databases to a different disk or partition (in this case i moved it to a different partition).
The description for Event ID ( 17137 ) in Source ( MSSQL$MICROSOFT##SSEE ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: WSS_Content.
The problem here is that when we re-attached the database to the SQL server the ‘AutoClose’ option (this option when ON closes the database cleanly when the last user logs off) is set to true.
FIX:
- Start SQL management studio and connect to the MSSQL#SSEE instance (this is the default sql instance installed by WSS for windows server 2003) - Server name should be: np:\\.\pipe\MSSQL$Microsoft##SSEE\sql\query
- Select the database from which the event in the event viewer is complaining about and go to properties > options and set the ‘AutoClose’ option to ‘false’
MSCRM-Admin Event Viewer, Sharepoint 17137, autoclose, Event Viewer, Sharepoint, sql
Recent Comments