reduce size of the wss content database LOG

– Truncate the log by changing the database recovery model to SIMPLE
ALTER DATABASE WSS_Content
SET RECOVERY SIMPLE;
GO
– Shrink the truncated log file to 5 MB

use wss_content
DBCC SHRINKFILE (WSS_Content_Log, 5);
GO
– Reset the database recovery model.
ALTER DATABASE WSS_Content
SET RECOVERY FULL;
GO

NOTE: Don't leave ur db Recovery in SIMPLE mode...this will cause some problems when u try to delete site collection from sharepoint central admin.
ALWAYS keep it in FULL mode.

SSE Express issues searching local sharepoint site with no top level site created

Current state of my sharepoint site collection has a sub site root/sites/portal but no top level site as such ..i deleted it i think to clean things up. When putting the top level address in SSE express content source for local sharepoint sites it failed to find the object , seems you need a top level site..even if its blank.
Not a problem created a wiki with just permissions for me , set SSE content source to search sub sites as well under this adress and all works. Ideally will move sub site to top level to sort whole thing out finally.

Slow load of WSS pages

Found easy solution to slow loads of WSS pages, GET RID OF TEMP FILES ...KILLS WSS PERFORMANCE!

Suspect WSS search database

Had my normal search database for wss (not SSExpress 2008) go suspect for some reason

Found this


As usual I was doing things on my VPC and I noticed that one of my SQL database was marked suspect. After some thought I guessed that the reason for the database to be marked suspect is because of me turning off my VPC without proper shutdown. The same reason why a DB can be marked suspect after a power failure. Now I was in a fix because I didn't had backup (Another dumb thing to miss on my part). So what should I do now? Well some research brought me good results, ended up framing following query:

EXEC sp_resetstatus ‘DBname’;
ALTER DATABASE DBname SET EMERGENCY
DBCC checkdb(’DBname’)
ALTER DATABASE DBname SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DBCC CheckDB (’DBname’, REPAIR_ALLOW_DATA_LOSS)
ALTER DATABASE DBname SET MULTI_USER

So all you have to do is copy and paste above query in query analyzer and replace DBName with your database name. And you are good to go now!

server returns a non-specifc error to get data from datasource when convert document library webpart to xlst

Have document library loaded with 3k of files, when tried convert web part showing library to xlst view returns "non-specific error".

SOLUTION: BUILD BASIC LAYOUT ETC IN TABLE VIEW FIRST , THEN DO A TEMPORY FILTER ON IT TO SHOW ONLY A FEW ITEMS AND DO CONVERT TO XLST. ONCE DONE CLICK ON PROPERTIES AND TICK 'SHOW SAMPLE DATA' AND JUST TO BE SAFE IN THE DROP DOWN BOX NEAR IT 'SHOW 10 ITEMS'. THE DATAVIEW SHOULD NOW SHOW IN XLST DESIGN VIEW ONCE YOU HAVE TAKEN THE TEMP FILTER OUT SO ALL RECORDS ARE SHOWN.


Why this happens is explained here




I'm developing some applications using SharePoint 2003 and Microsoft Front Page. I find that it is very useful when I convert a list view to xslt data view and customize it. But, recently, we've had a problem. When the data volume in a list is large, the performance of "converted to xslt data view" list view is very bad.
I don't know if it is a limitation of SharePoint (acceptable performance for less than 2000 items in a list) or due to "Convert to XSLT data view". Could you pls tell me the reason. I really appreciate!

Nguyen Minh Dung


Top.
--------------------------------------------------------------------------------

Re: Convert to XSLT data view
Monjo



This makes sense because the filtering/sorting is done at design time, thus it is applied at browse time. The performance hit comes because the entire XML is loaded before these are applied. To get around this, you may be able to add a filter/sort from the Data Source Properties dialog. Note, when you do it from this dialog you are actually modifying the source control. When you have view on a page you can modify the source control, but you can also write a filter to the XSLT source (what you are doing). The difference here is performance. Applying the filter at the Data Source layer will make the query more performant. If you apply a filter at the XSLT layer (like you are), the filter will be applied AFTER all of the data is returned and is starting to render in the browser.


This is a limitation/by-design of XSLT, not necessarily SharePoint.


-Monjo