A few more notes on the differences between a drop-down list in SharePoint vs. Notes.

1) In SharePoint, when you select a field to list choices, it assumes you are going to hard-code the list. If you want a dynamic list of choices, it is a different data type when setting up the column –the lookup type. At first glance, this seem like no big deal – just make your selection for what you want.

But – what happens in 6 months when the list changes, if you hard-coded it. That first time you are asked to changre the list, you will say to yourself, “Ah, I should make this a lookup.” Now you have to go write code to update all the existing data to support that change. This is nowhere near as easy as Domino, where you simply change the list to a formula.

2) As a symptom of the above problem, you need to create your source data lists to support your lookup lists before you create the form. This to me seems very unintuitive. I tend to get requirements from the end users, prototype a form with basic fields, then go back in and build the supporting lookup documents. Because both Notes and SharePoint are rapid, document-driven platforms, I am surprised that SharePoint is coded in such as way that it punishes you for quick prototyping of a form before all the details are put together.

You can certainly still make up a form, and make changes later, it just becomes more tedious. And as mentioned above, if you make changes after data exists, you may end up writing code to fix the data. (And agents don’t exist… that code must be custom .NET apps. Even for basic data updates.)

3) How many people remember the days of Notes R2/3, when almost every new developer asked the question of how to make a drop-down list generate itself based on the already existing data in the app? When a user entered a new item in the list, the next user got that new item in their drop-downs. In later versions, as we added more features, this wasn’t the standard newbie question anymore, but it does illustrate a good concept:

How would one answer that question in SharePoint? I may have to try setting a lookup field in a document to its own list, and see if it works. If it is that simple, great — because trying to dynamically update a secondary list based on a new data value in a document doesn’t seem like it would work very well.

5 Responses to “More on Drop-Down fields in SharePoint”


  1. [...] More on Drop-Down fields in SharePoint « Notes Migration Blog Posted October 13, 2007 More on Drop-Down fields in SharePoint « Notes Migration Blog [...]

  2. Ian Morrish Says:

    Hi,
    (And agents don’t exist… that code must be custom .NET apps. Even for basic data updates.)

    Access is the perfect tool for performing these updates. Access can use SharePoint lists as data sources. This allows you design/run insert and update queries very simply.

  3. migratenotes Says:

    @2) Oh, I hadn’t even thought of that. That is a much better answer. I’ll update my thinking on that point from here on out. :)

    Thanks for pointing that out…


  4. I’ll admit I’m not extremely familiar with Sharepoint, but doesn’t it store its data in SQL Server? If that is the case, why not use stored procedures or SQL Management Studio to do updates? SQL Server has a scheduler built in, too, and there is Database Mail that you can use to do automated e-mails.

  5. migratenotes Says:

    @4) Your lists, fields, and values are stored in SQL Server, yes — but as metadata, not directly as database data. So it isn’t as simple as just writing some SQL code to do an update.

    Every Microsoft programmer, trainer, and rep I have talked said that one should NEVER directly manipulate the SQL database. So while I’m sure you could go view the database directly and figure out how to make the updates, I’m taking everyone’s advice at face value and using the APIs instead.


Comments are closed.