Tuesday, November 30, 2010

Adding records to SharePoint using MS Access - what about folders?

Situation:  we have some data gathered from SPSS for statistical research and this will be structured when it is spit out as a giant table of data.  We're trying to get all the data into SharePoint for evaluation and review by several departments in the university - which means we've used folders to separate the permissions in the list (this is just a custom list with 60-80 columns for all the data).  Beyond that, we've avoided the use of folders but here's the problem:  how do we import the records of data and place them directly in the appropriate folders?

Thought:  there's several columns that don't normally appear in Access like the "Path" and "Encoded Absolute URL"...if you use a simple query, you can display these columns and create new records here fairly easily...I was hoping that by setting the encoded URL and path that the items would appear in sharepoint in the appropriate folders.  Anyone have any ideas on how to use Access to add records but specify the folder they go in?

Monday, November 29, 2010

Managing SP processes instead of people

If you fix a process - you fix a problem, you make a system more efficient, and you make things overall "better"; however, what happens when the processes are perfect?  A truly well-oiled enterprise machine is cranking out quality material at great speed and then what?  I'm thinking about something:  a perfect process masks moral and ethical ineptitude in people.  This is a quandary for me:  should we focus on really trying to empower and encourage people and end users to be "better" or focus on fixing the process so that, no matter how bad a person one remains, the business and the processes run well?  This applies in regular business with IT, churches with pastors, political campaigns with staffers/candidates, etc.  I wonder if fixing the process doesn't really fix the problem some of the time if you really wanted better people in the first place.  What do you think?

Thursday, November 11, 2010

Limit the number of characters in InfoPath multi-line boxes

Situation: we have a textbox we made in InfoPath. We decide that this box should be able to type multiple lines. We open the settings for the box and change click the checkbox that says "Multiline". It then greys out our ability to limit the number of characters in the box. We want to still limit how many letters that they can type! Here's how:

Use Data Validation on the box (in 2007, right-click the textbox and then click "Data Validation", click "Add"; in 2010, click the textbox, click the Control Properties in the ribbon, and click "Manage Rules", then click Add -> Validation rule, then click the condition).
[Update: a comment from a user below highlighted a limit in the solution: line breaks. A better way to accomplish this is to use the 'the expression' in the first dropdown instead of your field and then type "string-length(.)>500" without the quotes]
Now that you have the data validation window open you should see the ability to set your condition. The first box should be your field, the middle box should say "Does not match pattern", and then you click "Select a pattern" in the third box -> click custom pattern, and then type this:


See, the Period stands for any character except new line breaks or carriage returns. Now, normally you would put an asterisk after that to mean that you can type as much as you want. Instead, the little braces allow you to place lower and upper limits for the number of characters. The 1 means that they HAVE to type at least 1 letter and the 500 means they get capped off at 500 for data validation purposes.

Now, this does NOT mean that the InfoPath box will STOP letting them type! It just means that, when they tab out of it, it will glow red and have a tooltip that you specify for them when they've typed too many characters. I tested this and it seems to work well for me; give it a try and tell me your results with it!