Thursday, January 25, 2007
Moving SharePoint Portal Server 2003 Service Pack 2(SPS-SP2) and Windows SharePoint Services Service Pack 2 (WSS-SP2) to a new server and url.
Tuesday, January 23, 2007
Wednesday, January 17, 2007
So, you think the new Visual Studio 2005 and ASP.Net are pretty nice. You get rapid development from drag 'n drop objects like ObjectDataSources, GridView, etc. Then the dreaded exception occurs in your business object. Where does that appear in all this? How do you get to that exception? Believe it or not, Microsoft did it right. They have an event called ObjectDataSource Selected event that you can tap into just like you would any other event.
To check for an exception you would do something like this:
protected void ObjectDataSource1_Selected(object sender, ObjectDataSourceStatusEventArgs e)
if (e.Exception != null)
if (e.Exception.InnerException != null)
if (e.Exception.InnerException is IOException)
// do something with the exception.
e.ExceptionHandled = true; // so it doesn't keep bubbling up
Tuesday, January 16, 2007
This assumes that you are using JAX-RPC which uses SOAP 1.1 to implement a web service, and that the web service is being consumed by .Net (1.1 or 2.0). If you are using WS 2.0 there are some different options.
While it is possible to just throw an plain old Exception in your java web service, it will show up your .Net client as a exception. The problem is determining what exception you have catch once you get it. In this situation we need a code that can be used in the client to identify the exception without try to rely on the message of the exception since this is typically semi user-friendly text. Exception class doesn’t have the concept of a code to identify the exception. The good news is SOAPFaultException has the concept of a code and it also allows you to attach any other data that may be useful.
Creating a SOAPFaultException can be a little messy, so I recommend created a convenience method to encapsulate this. In case this isn’t clear, this goes in your java web service.
// Creates and returns a SOAPFaultException. Throws one if there is an error creating
// Should be Client or Server
// If it is Client then message should NOT be resent without change
// i.e. Server.Fault or Client.Fault
public SOAPFaultException NewException(String faultType, String errorCode, String errorMessage, String webServiceOperationName) throws SOAPException
// The faultcode element provides an algorithmic mechanism for identifying the fault.
//SOAP defines a small set of SOAP fault codes covering basic SOAP faults.
QName faultCode = new QName("http://FrontLineWebService/" + webServiceOperationName, faultType + "." + errorCode);
// The faultstring provides a human-readable description of the SOAP fault and is not intended for algorithmic processing.
String faultString = errorMessage;
// The faultactor element provides information about which SOAP node on the SOAP message path caused the fault to happen.
//It indicates the source of the fault.
String faultActor = "http://FrontLineWebService/" + webServiceOperationName;
// The detail element is intended for carrying application specific error information related to the SOAP Body.
Detail faultDetail = SOAPFactory.newInstance().createDetail();
// Define what the body of the email should be in terms of XML. You can put whatever data you want here
// for more info on params: see http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383507
throw new SOAPFaultException(faultCode, faultString, faultActor, faultDetail);
Here is an example of how you would throw the SOAPFaultException in your web service.
public void testMethod() throws Exception, SOAPFaultException, java.rmi.RemoteException
throw NewException("Server.Fault", "TEST_CODE", "This is only a test description in English", "testMethod");
Now that you can easily throw a SOAPFaultException (SoapException in .Net), you are all set. Here is an example of catching it in your .Net client.
MyWS ws = new MyWS();
catch (SoapException ex)
if (ex.Code.Name == "Server.Fault.TEST_CODE")
// do stuff here
Friday, January 12, 2007
The new email funcationality in SQL Server 2005 is quite nice. Every time you call msdb.dbo.sp_send_dbmail it sends the email in the background. This is important when you are sending a lot of emails on a already busy server. The natural question then is, how can I see what was sent, and if it was sent properly. The answer is in msdb database.
To see all the email sent out and the contents just do the following:
select * from msdb.dbo.sysmail_mailitems
sent_status field: 0 = waiting to process 1 = success 2 = error with the smtp server
To see if there were any errors, you can check the log using:
select * from msdb.dbo.sysmail_log
If you want to check retries for sending, try this:
select * from msdb.dbo.sysmail_send_retries
There are other tables, but they seem to be managed by the Microsoft SQL Server Management Studio or other stored procedures. Feel free to take a look at them though:
If you need help setting up SQL mail in the first place, follow the link above.
Thursday, January 4, 2007
It appears that Microsoft SQL Server Management Studio (replacement for Enterprise Manager and Query Analyzer) in MS SQL Server 2005 does not support carriage returns (or any variation of it) using the Open Table view. This view allows for easy editing of data. The exception of this is data that has carriage return in it. You can’t paste, shift-enter or anything else using this interface.
The other annoying thing is that when showing the results of a query in the grid, if there is carriage returns in the data it simply ignores them when displaying the data. To see the carriage returns, you will need to change the results view from grid to text.
So, the question is, what is the easiest way to insert or update data that has carriage returns in it. The answer is simple. Use SQL, forget the easy to use GUI.
Below is an example:
insert into MyTable(MyCol) values ('line one
update MyTable set MyCol = 'line one
where ID = 1;