WS-FileConvertor 1.0c - Convert images to text and upload into SharePoint

Version 1

Version 2

I have made some changes in the previous version and now users can also upload the original files along with the converted text files into the SharePoint.

Click here to download this tool.

For your convenience, you can create two different views in SharePoint library to show image and text files separately. For example, if the source image files are of GIF type, then you can create a view with the following filter settings:

Show only items when the following is true:

Column Name: Name

Condition: Contains

Text: gif

You can make this view the default view and it will only show the image files. Similarly, create another view that will only show the text files.

What to expect next? Capability to extract metadata from the converted text files and uploading the original image files along with the extracted meta data. This will allow users to upload only the image files without the need to upload the text files. The common words extracted from the converted text files will be uploaded as metadata. This will allow users to search image files using keywords.

-SSA

Inspecting Logic and Checking Design of InfoPath Form It is easier to inspect the logic manually in simple forms but companies use InfoPath not to create simple forms but to create forms in an easy and simple way. These forms can get quite complex and large. Once developed and deployed, there are different techniques that developers can use to track down errors but even at design time inspecting and fixing errors in the form can be a tedious job. Forms can have hundreds of nodes or may be 20-30 fields in a single view. It's not easy to find problems with the data sources without the help of a tool. Unfortunately, logic inspector and design checker, tools that come with InfoPath are usually overlooked and not taken advantage of by the developers. Figure 1: Logic Selector can be selected from the Tools menu There are some errors that become evident only after when a developer tries to deploy the form. Large number of data sources or fields is not the only problem, no form is complete without the data validation checks, rules and business logic. Logic Inspector enables developers to find problems with the form before they try and deploy it on the destination server. It allows them to view the data validation checks, rules, calculated default values, and business logic, all in one place. Design Checker is another tool that can be used to check the form design for performance related issues before deploying the form. I admit, even I used to underestimate the power of this tool but It really helped me once to resolve performance issues in a large form that comprised of hundreds of nodes, validation checks, rules and thousands of lines of business logic code. Let's take a look at the Logic Inspector first before moving on towards the Design Checker. Figure 2: Logic Inspector inspects Data validation, Calculated Default Values, Rules and Programming Logic Inspector and Design Checker  can be selected from the Tools menu. Design Checker is also available in the Design Tasks pane. When you work on a large form, it is very common to delete fields and/or nodes from the form and at the same time adding new nodes or fields in the form. This can easily inject problems in your form because many of the fields are interdependent on each other. One field may be dependent on a value in another field. Now suppose you remove the field that had data that was being used in another field. You will not get any error message but when you will try to deploy the form, it will fail. Now imagine you have to find the problem manually in the form that houses hundreds of nodes and 30-40 fields in each view and there may be more than one view in your form. It will be a tedious task. Logic Inspector comes to your rescue at this point. Figure 3: Logic Inspector catches broken rules See Figure 3 above. "Invalid Field" message shown in red tells you that a field that was being used in a rule has been deleted. You will have to re-add the field, remove the rule or edit the rule in order to fix the problem. Your form will not publish unless you fix this problem.  You can run Logic Inspector to view the logic in the complete form or you can also invoke it to inspect logic in a single field.   Figure 4: Logic Inspector can be invoked for a single field To inspect a single field, right click the field and select "Logic Inspector". It will show you the complete details, for example, there will be a section called "Logic that depends on the value in this field group". There will be another one called "Logic that is triggered by a change in this field or group". (See figure 4). You can also view logic for a single field by clicking the "Field Name" hyperlink. It will open another pane to the right that will show you the details. Now let's turn towards the Design Checker. Design Checker is another very important tool that you should not miss when working on a complex form. Performance may not matter in case of small forms but it really matters when one is developing a complex form. Creating nested sections, nested tables, nested nodes is a very common scenario in complex forms. This is where developers usually make a mistake without thinking about the implications that will affect the form's performance. Especially if it's a web enabled form that will run in a browser, then of course you can not comprise on the form's performance. No one will know the difference when opening the form in the InfoPath client application but loading the same form in a web browser will show you why it is important to take care of the performance issues. Complex forms load very slow in browsers. It can take a complex form 2 to 20 seconds or may be even more to load in a browser. Well, that's a lot of time and you won't believe how annoying it becomes when the form takes so much time to load. You can reduce this loading time by fine tuning your form and resolving the performance issues. One mistake that developers usually make is that they don't take care of the hierarchy in which they insert the nodes in the data source. This can have serious implications. For example, if you have added fields to a section then in the nodes' hierarchy, fields' nodes should come under the section's node. Look at the figure below to get a better understanding of what  I mean. Figure 5: Locate node hierarchy inconsistencies with Design Checker "RelatedRecord" is a repeating table and is a part of "RelatedRecords" which is a repeating section and we can see this in the design view of the form but in the data source, if you notice, the "RelatedRecord" comes under "myFields" and not under the "RelatedRecords" node. This will work. Preview the form and everything will work as expected. This is a very simple example. In real life scenarios, some times we have to use nested tables that can go up to 5 levels deep and in such cases if a developer does not take care of the hierarchy in which the fields are added to the data source then this can have serious implications as far as form's performance is concerned. Form will load very slow.  If you want to read more about the performance related issues and tips on how to fine tune InfoPath forms, then there are a couple of very good articles available on Microsoft site: Improving the Performance of InfoPath 2007 Forms InfoPath Forms Services  best practices If your form has hundreds of data nodes then use Design Checker to check hierarchy related inconsistencies. Figure 6: Design Checker Pane All inconsistencies are shown in the "Offline Compatibility" section. To view a detailed message, click the message in this section. It will pop-up a message box that will show you the detailed message. Developers should always run Design Checker before publishing the form and should fix all issues reported by the Design Checker. Design Checker also helps in pin pointing "Online Compatibility" issues. Check the "Verify on server" option and click "Refresh". If the publishing location is SharePoint then the Design Checker will verify if the destination site or library still exists or not. This can also help if there is an issue with any of your promoted fields. If you change the data type of a field in your form that was previously promoted to be used in a SharePoint forms library, and you forget to remove the previously promoted field and re-add it, your form will not publish and will give you an error. Again, as I said, if your form contains many fields then locating such issues becomes easier with Design Checker. Design Checker will show you the source of the error which you can then easily fix before trying to publish the form again. All in all, Design Checker is a handy tool and lots of headaches can be avoided if developers use these tools to find and fix the problems at design time. We just saw why Logic Inspector and Design Checker are important tools for any professional developer working on complex InfoPath forms. I would also like to discuss two more tools very briefly that can be helpful in finding issues with complex forms. These may not offer help in finding the business logic issues but you can locate the javascript errors with these tools. One is Fiddler. Fiddler can be used to log all HTTP traffic between computer and Internet. Fiddler, when used with a browser, can be very useful in finding javascript issues with forms. Fiddler uses its own built-in inspector to analyze HTTP traffic.   Figure 7: Catch HTTP and javascript errors with Fiddler Another important tool is Internet Explorer Developer Toolbar. IE Developer Toolbar is a must have for every web developer. It is not meant for finding issues with InfoPath forms but because web enabled InfoPath forms load and run in a browser, developers can use it to find any javascript related errors. It allows users to explore Document Object Model (DOM) of a web page. And finally, if you developed a form using Visual Studio then you don't need any other debugger. Built-in Visual Studio debugger is enough to find business logic and javascript related errors in your web form. Javascript error will show you the filename that contains the source of the error. You can open that file in Visual Studio and put a break point in the function that you think contains the source of the error. Visual Studio will show the exact source and the error message that you can then fix easily.

Renaming the changed Title field back to 'Title'

Title field once changed can not be renamed back to 'Title' through UI. I had to make a change in the DB to forcefully rename the field but there is an easy solution also. Today while browsing the net, I found this interesting post that discusses in detail the cause and the solution for this problem:

http://sharepoint.microsoft.com/blogs/fromthefield/Lists/Posts/Post.aspx?ID=15

Title is a reserved word and once changed, can only be renamed back to 'Title' through programming.

SharePoint file uploading problem

Sometimes strange things happen after applying security updates to the SharePoint server. Recently a friend told me that after applying a security update, users in his company complained that they were no longer able to upload files to the SharePoint. If this happens to you, make sure it's not because of transaction log. Usually when transaction log is full, users get these types of errors. Also, run following command and it should solve the problem:
stsadm -o setsitelock -url http://yoursiteurl -lock none
lock types: none, noadditions, readonly, noaccess

Enabling Anonymous access in surveys

I am asked quite often about the anonymous access in surveys. This may be because I wrote a couple articles about surveys in MOSS 2007 some time ago.

Creating a survey in MOSS 2007
Creating a survey in MOSS 2007 programmatically
Writing an event handler for a survey

If you have a subscription to Advisor magazine, you can read a more refined article here.

Enabling anonymous access in surveys is easy. All you have to do is make some changes in the SharePoint Central Administration and the site where the survey is hosted. Following are the detailed steps required to do this:

1. Go to IIS settings. Select the SharePoint site for which you want to enable anonymous access. Select "Properties".  Select "Directory Security" and enable anonymous access by checking the "Enable anonymous access" option. Use "IUSR_MACHINENAME" as the user (If your machine name is "DEV", this user name will be "IUSR_DEV".)

2. Go to SharePoint Central Administration. Select "Application Management". Select "Authentication providers" under "Application Security".

3. Select correct web application from the drop down. Click "Default" zone.

4. Check "Enable anonymous access" option.

5. Create a group for anonymous users at site level and assign "Contributor" rights.

Creating a group for anonymous users: a. Open SharePoint site that hosts the survey . b. Go to Site Actions > Site Settings and select "People and groups" from the "Users and Permissions" section. c. Select New > New Group. Give this group a name, for example, "anon users". Scroll down and check "Contribute" option in "Give Group Permission to this Site" section. If you don't want the users to have the "delete" right, create a new permission level and use that instead of the "Contribute" option.

6. Open your survey. Go to "Settings". Click "Permissions for this survey" (under "Permissions and Management").

7. Click "New" and add the anonymous group that you created for this survey. Alternatively, you can also define anonymous permissions directly. Select "Anonymous Access" from "Settings" drop down. Select permissions that you will like to give to the anonymous users and click OK.

8. Log out and access the survey list without logging in again and test the user access. You should be able to respond to a question without logging in.

KB934525: Database issue!

KB934525 is required to fix a vunerability in Sharepoint. Read security bulletin for more information.

Information about KB934525 can be read at http://support.microsoft.com/kb/934525

Many people have reported that their SharePoint broke after installing this security update. This can happen if the security update fails to install properly. People have reported different issues and errors. One of the common errors if this update fails is:

'SharePoint_AdminContent_GUID' on SQL Server instance 'XXXXXXMicrosoft##SSEE' is not empty and does not match current database schema.

Another error is:

The specified SPContentDatabase Name=SharePoint_AdminContent_GUID Parent=SPDatabaseServiceInstance Name=Microsoft##SSEE has been upgraded to a newer version of SharePoint. Please upgrade this SharePoint application server before attempting to access this object.

How can you fix these errors?

First, restart the SPWebService. You can do it manually from the "Services" mmc. You can also run the stsadm command to restart this service.

Then, run the following command:

PSCONFIG -cmd upgrade -inplace b2b -wait -force

You must perform b2b (build to build) upgrade.

Hopefully this will fix your database problem.

WS-FileConvertor 1.0b - Tool for converting images into text readable format and uploading into SharePoint

I have modified the first version. It can now upload converted files to the SharePoint. You can download it here. This application uses WSUploadService web service to upload files to the SharePoint. You can download WSUploadService here. Select Image Folder: This is the folder where source images are stored. Enter SharePoint Site: This is the library URL where converted files will be saved. If you are saving files to a document library, the URL will look like: http://server/sites/doclibrary ("http://" is required). Enter Service URL: This is the web service URL. "http://" is required at the start of the URL. Suppose you are uploading files to the following document library: http://server/sites/site1/doclibrary Then the web service URL will be: http://server/sites/site1/_vti_bin/Files.asmx This is just an experiment. Currently it works with GIF files and converts them into TXT format. I am still working on it and intend to expand it by including more useful features and formats. Download Tool -SSA

Tip: SESSION_STATE_PASCAL_CASED is not configured properly

Error Description: InfoPath Forms Services has detected a mismatch between the user's data in the browser and on the server. This may indicate the SESSION_STATE_PASCAL_CASED is not configured properly on a multiple front end farm or that a malicious user is trying to tamper with client data.

 Possible Fix: Clear browser's cache and try again and if that doesn't solve the problem then run the following command:

 stsadm -o reconvertallformtemplates

Read more about this command.

-SSA

Seasons Greetings

Seasons Greetings,

I would like to wish a wonderful holiday season to all my blog readers.

Merry Christmas and Happy New Year!!

SSA