I can’t resist responding to *this*:

Just because something *can* be done in one framework doesn’t mean it should *always* be done in that framework. Sites is cool but doesn’t fit every purpose. Some of us are working with more than just Salesforce integration in our applications, and I highly doubt that PHP integration with Salesforce will become obsolete just because Sites exists (although it’s also nice to have Sites as an option).

And I’ve also heard of the 3-character “prefix” but no one I’ve ever discussed it with has ever called it an “object code”… if we’re going to be purist about nomenclature let’s see it referenced in the docs and not just some other guy’s blog.

2. I went to the URL, and saw several examples of forms implemented using Sites. I guess I’m just refuting your comment ‘Though Sites will render PHP-integration obsolete…’. Honestly, I really only care about a specific layer on the server side. I hereby suggest that anyone who wants to know anything about Apex, VisualForce, or Sites check out http://www.x2od.com/.

Until Salesforce improves their uptime, it’s a moot point. It’s not even worth discussing, IMHO. I get exception messages from Salesforce in my mailbox every single day, sometimes many per day. That doesn’t even include scheduled maintenance. If I want to retrieve my license keys from Salesforce during an outage, how do I do that with Sites? Perhaps there’s an answer to that question, but if there’s not, maybe you should try to develop a CRM framework that builds in redundancy and handles keeping your second datastore (memcached/bdb/SQL/flat files) in sync while users are making changes in the UI. I’ll be discussing ways to do this soon.

1. Just because someone calls it a prefix on a discussion board does not mean that it is a prefix. It really is an object identifier.

2. I’m sorry to see you say that Sites is geared towards form management and will never replace web applications. That is just false. To see the amazing things that have been done with Sites, visit the Sites Gallery at http://developer.force.com/sitesgallery. You’ll see that entire web applications are created on Sites. There is even an AppExchange CMS package that was just released. Sites CAN replace entire websites, so let’s watch the word “never.”

Remember: It was once said that humans would never fly, that Einstein would never amount to anything, and that the American people would never be interested in movies with sound.

The gotcha I was referring to in the Excel Connector is when using the case-insensitive format, I was only talking about being able to use the two formats interchangeably. The issue, as illustrated here, is that VLOOKUP is case-insensitive. Excel issues are generally out-of-scope for this blog, I happened to be aware of this particular issue and mentioned it. There certainly are work-arounds.

According to David Claiborne, you can indeed refer to it as a prefix. See this post. I think we all understand what I’m talking about here.

As discussed before, Sites is geared toward form management, it is never going to replace web applications.

-p

The 15-character ID is case-SENSITIVE, and the 18-char is case-INSENSITIVE. There is no additional information in the ID other than to make it case-insensitive.

Excel Connector will return the 18-char ID when querying data, and so will every other API-using tool such as Apex Data Loader. There is no “metadata” in the ID, and neither is newer or previous – they are interchangable. In fact, there is a FIXID() formula installed by the Office Toolkit into Excel that will let you switch between the two.

The reason there’s nothing returned for “salesforce id prefix” is that the three characters are not an ID prefix! They are called “object codes” and there are great posts about them at http://salesforce.phollaio.com/2007/01/11/salesforces_url_structure/, among other places.

Security tokens change automatically, but once you set a security token, Salesforce will email you a replacement token every time you change your password.

Welcome to the Salesforce world. Though Sites will render PHP-integration obsolete, eventually, customers with existing PHP implementations that they do not wish to migrate completely to Sites/Visualforce will still need to know this. Thanks for writing.