I receive calls daily about my availability as a SharePoint developer. Are you seeking employment? Are you presently available? Can you talk? All of these questions I am sure are a result of my continually updated resume on Dice.com. As a SharePoint Consultant, I am always interested in talking to people about new opportunities. It’s how I make my living. I love talking to people about SharePoint and I spend quite a bit of time developing a network of personal and professional contacts.
I employ many different techniques. From social networking sites like Twitter and Facebook, to writing on this blog or living blogging at different events, I try to promote my interest in SharePoint. I like to help people discover the exciting world of SharePoint and so I participate in User Group meetings and attend different conferences. Most recently, I attended the Microsoft SharePoint Conference 2009 in Las Vegas. You can read my post about that experience here.
Inevitably, the question comes. Are you willing to relocate? Now – I have to ask you. If you are recruiting for a SharePoint Developer position in Chicago, are you telling me that there are not any SharePoint developers in the Chicago area willing to look at an opportunity? Will a company actually move a person just to fill a developer position? Maybe I’m naive. I was just talking to someone about a couple of positions in Washington DC. I continually see positions out there. Are there no developers in the DC area? Now – for short-term projects, I will travel – no problem. For a long-term situation – I would need to be able to telecommute. But please don’t ask me to move my family to New York, New Jersey, Washington DC, California, Seattle, Denver or St. Louis. I’m sure they are all nice cities, (I’ve visited most of those), I’m just not interested in moving there.
But – if you want me to move to the Springfield, Missouri area – then let’s talk!
If you have list data that you want to use in another application, what are some ways to get to that data? That was the question posed by a recent requirement from a client. Fortunately, SharePoint presents us with some creative ways to get to the list data.
- Export to Excel. This is a good, and quick, way to export data out of SharePoint so that you can use it in other programs. Once you have it in Excel, you can further export it into different formats. The most common is as a comma-delimited text file. I am not an Excel expert but it is quite easy to Export To Spreadsheet from the Actions menu and then save the Excel file in, say, a CSV format. From there, many applications can import that text file. But what happens if one of the SharePoint fields are large text fields that could contain commas and line feeds?
- Export to Access. For quite a few data export requirements, I tend to use this way. Access has better import/export functionality. I can save the exported list data in many formats. How do you do this? From the Actions menu, select Open With Access. [Note: this isn’t available in Document Libraries]. From there you can decide whether you want to maintain a local copy or just link to the list. Once you have it open in Access, you can export it in a number of different formats.
- If your third part application can call Web Services, SharePoint exposes a lot of functionality via Web Service. Web Services are beyond the scope of this article but you can find plenty of information on MSDN, like Windows SharePoint Services Web Services.
What are some of the ways you deal with the requirement of external applications using list data? I would love to hear your comments!
Cpl. Paul Flewwellin and Sgt. David Petersen
Yesterday was the Marine Corps 234th Birthday. As our custom, I called my bro’ Paul and wished him a Happy Birthday. We hadn’t talked for about a year but it was as if we were still onboard the USS Raleigh in the middle of the Persian Gulf talking about our dreams, goals and our wives. We didn’t know each other very well before that deployment but by the end of the deployment, we became brothers. It’s been about 16 years since I’ve seen him. When we talk, we speak about how fun it would be to get back together. Another year passes and we do it all over again. Our kids grow older, our hair gets grayer (or in Paul’s case – becomes non-existent). But one day a year, we are back on that ship. Laying on the deck staring up into the vast theater of stars provided by God, talking about life and solidifying our bond as brothers.
It is with this fond memory that I wish all who served a Happy Veterans Day. The bond we share is deep and only fully understood by those who have served. God Bless those who are standing in harms way today – forming the bonds that will last them for the rest of their lives.
Semper Fi. I Love Ya ‘Bro.
Today I was presented with a problem that I thought should have been easy. Create a calculated field that displayed the number of days that had passed from an [EndDate] field. My first thought was to use a calculated field with a function =[Today]-[EndDate]. When I got that, I was informed that calculated fields could not use [Today] or [Me].
A quick Bing informed me that a number of people had run into this same problem. There were references all over of a hack that would have me create a field called [Today] and then use it in the calculated field and then delete the bogus [Today] field. That was really a hack since it didn’t fully work. That hack only calculated [Today] based on when the item was last modified. It wasn’t dynamic. You could have saved a lot of trouble by just using the [Modified] field.
More searching didn’t turn up any other solutions. I tried various vbscript/excel functions in the calculated field to no avail. Then I started thinking clientside. I figured that if I could identify the fields in the list display, I should be able to manipulate them with jQuery. A quick search turned up a nice little piece of code by Paul Grenier on EndUserSharePoint.com. He has written a series entitled jQuery for Everyone and one of his articles was on Replacing [Today]. In his article, Paul talks about replacing a DateTime field with an Aging calculation. His article calculates a DateTime from the last modification date. That works – but it didn’t work for me. What I needed was to calculate the difference between any date set by the user and the current date. My solution was to create an [Aging] field of type Calculated. The formula that I used in the calculated field was =[EndDate] which is the date I need to calculate the difference on. I then modified Pauls code to use the [Aging] field and I also modified his date calculations to only calculate for the date and not hours or minutes. The result ended up looking like the illustration below. Thank you Paul for your awesome tutorial on jQuery in SharePoint. I learn so much.
Comments (0) 
Themocracy