I have been using this method for some time now and decided to make a slight change to it. I have been using the PowerShell method found here to find the internal column names for my lists and libraries. It works great. The only problem with this is that I have to modify the script each time I need to change the value of the list or site. This is usually not a big deal since I generally am only looking at one list. This was not the case the other day. I needed to look at many different lists in the same site. Instead of having to modify the script each time, I added a set of parameters to prompt me at the command line. The code looks like this:
If you need to have more than one workflow for a particular list/library, DO NOT copy a SPD workflow and paste back into the same library.
What happens is that even if you change all of the properties of the files (names, etc.), there is still a hidden property that SharePoint likes to hold on to and uses to identify the workflow. Think of it as an ID.
Basically, you will have two different workflows with the same ID. When you publish one of these to a list/library, everything works fine. When you go to publish the second one, everything seems fine but after close evaluation, you will notice that the first workflow that you published is no longer attached to the list/library.
Moral of the story, don’t be lazy. Create a new workflow even if all of the information is the same.
I was faced with this task recently. Let me paint the picture for you.
I have a document library with over 1,000 items in it. I added a new column (Named) that needs to have the same information as an existing column (Name). For whatever reason, the web part I am using for my list search does not recognize the existing column. I created a SP Designer workflow to copy the contents from the ‘Name’ to the ‘Named’ on creation or edit.
To do this, there are a couple of options.
The long drawn out option – Edit each file individually
The best option for me – Content and Structure
Power option – SharePoint Designer
I went with option 2 because I did not want to lag the server with a whole lot of who ha. Here are the steps I followed to make this happen.
Go to the site, Site Settings, Content and Structure
Expand the library to perform this action
Place a check into the ‘Select All’ check box
Click on the ‘Actions’ drop down and select ‘Check Out’
Once checked out (you may have to do this twice), click the ‘Actions’ drop down and select ‘Check In’
Make sure to check that you have performed this action for all items in your view. Mine were in groups of 100, which is generally the standard view. The fasted option for me would have been the SharePoint Designer route but I did not want to take a chance of checking out over 1,000 items at once and then check them back in. We already have enough load on the servers from all of the other users accessing SharePoint.
There may come a time when you will need to move data from one source to another. You could always use Windows Explorer to do this, but you will not be able to retain any metadata in your library.
Recently, I needed to move around 1,200 files (680 MB) from a folder into a new document library. I tried using Windows Explorer but as I stated earlier, it would not copy over the metadata. Then, I tried using Content and Structure. This has worked for me in the past and it will preserve your metadata. However, this time around, I was unable to copy the files. Not sure why, could have been file size or just the environment.
After all of this, I ended up opening my site inside of SharePoint Designer. Within 2 minutes, I copied all of the files and preserved all of the metadata associated with the files.
To quote an old southern saying, there is always more that one way to skin a cat. Just got to find the right one.
Go to the list or library that you want to resize and add a Content Editor Web Part.
From the script below, I am referencing jQuery from my internal site.