Become a Columnist Microsoft Exchange Site Microsoft Support SiteMSDN Exchange Site

   

Subscribe to OutlookExchange
Anderson Patricio
Ann Mc Donough
Bob Spurzem
Brian Veal
Catherine Creary
Cherry Beado
Colin Janssen
Collins Timothy Mutesaria
Drew Nicholson
Fred Volking
Glen Scales
Goran Husman
Guy Thomas
Henrik Walther
Jason Sherry
Jayme Bowers
John Young
Joyce Tang
Justin Braun
Konstantin Zheludev
Kristina Waters
Kuang Zhang
Mahmoud Magdy
Martin Tuip
Michael Dong
Michele Deo
Mitch Tulloch
Nicolas Blank
Pavel Nagaev
Ragnar Harper
Ricardo Silva
Richard Wakeman
Russ Iuliano
Santhosh Hanumanthappa
Steve Bryant
Steve Craig
Todd Walker
Tracey J. Rosenblath
 
   

Webstore is just a danged database!

Page 1 | Page 2

URL (Universal Resource Locator)

So, let’s begin at the TLH and construct a URL to the Fish table:

Apple/Carrot/Fish

Simple, right? But, the URL isn’t complete because we need to include instructions in the URL where the TLH is located. And now it gets tricky, because there are two ways to include the TLH’s location, by using the “file:” scheme or the “http:”scheme.

file://./backofficestorage/domainname/Apple/Carrot/Fish

http://servername/Apple/Carrot/Fish

Awwww, dang! More big words! More arbitrary rules!

When do I use File://?

When do I use Http://? 

What the heck is “backofficestorage”?

Well, let’s start at the top. File:// or Http://?  This is actually a fairly easy question. Just keep a few simple rules in mind.

1.                  File:// is much faster than Http:// so use File:// anytime you can.

2.                  File:// only works if you’re referencing something LOCALLY on the same server where your code is running!

3.                  Http:// must be used for all WebDAV calls.

4.                  Http:// can be used to reference anything, anyplace in the world, on any server, anywhere.

There are other rules too, but these give you a good guideline.

Question:        What is “backofficestorage”?

Answer:           Don’t know! Don’t care! Just use it!

I’ve never taken the time to figure out officially what “backofficestorage” means nor why it’s necessary. I DID wondered why Microsoft decided to use a 17-letter word rather than a 3 or 4 letter word. (Microsoft must be filled with great typists). But what, exactly, is it? I don’t know and I don’t care. I just know it’s necessary when using a File:// URL. My guess? I think it’s a keyword that is recognized by either Active directory, Exchange, or maybe even IIS, that tells the engine to look in the Web Storage database. But, I’m not sure. So, don’t ask, don’t lose sleep, just use it.

file://./backofficestorage/domainname/Apple/Carrot/Fish

http://servername/Apple/Carrot/Fish

Also notice File:// needs a Domain Name and Http:// needs a Server Name. Think about this a moment. Why is this important? Because it helps you remember that http:// is a “Go Anywhere”, “Get Anything” URL address because the server name must be resolved using a DNS (Domain Name Service). And because if you know the Domain, then you’re working locally and you can use the much faster File:// URL.

Before we move off this topic, let’s look at one more Http:// URL.

http://servername/exchange/georgewashington/inbox

Can you guess what the above URL targets? Right! George Washington’s Inbox for Outlook/Exchange. But don’t get too excited because it ain’t that easy! First, old George is dead and besides to get access to his Inbox, you will need to login as George (or as someone who has read permissions for George’s inbox). What I’m trying to say is, although it’s easy to build a URL, getting access permissions correct is often a pain-in-the-patootie. But that’s for another article.

Schema

Let’s stop jabbering about URLs and jump back to the topic, Databases.

When I was a little boy, my daddy would grumble that Uncle Wilbur was a scheming old “S.O.B.”. So this $10 word, Schema, confused me a lot in the beginning. But I finally figured out that Schema and Scheming where different animals.

Relational Database Schema

Think about a Relational Database Table. It has columns and rows. Each column contains a tidbit of data. That tidbit may be an integer, a string, a currency value, or maybe something even more exotic like an embedded OLE object or a BLOB (binary large object) such as a photograph. In a relational database, the details about column name, column type, column size, column format, etc., are referred to as a table’s Schema, and have nothing to do with Uncle Wilbur.

So the Schema for the above relational database table would look like:

Column Name

Column Type

Column Size

Column Format

SSN

String

9

###-##-####

Person

String

20

None

Age

Integer

n/a

###

Photo

OLE Object

2 gigabytes

GIF, JPG, BMP

And the above Schema would be stored in the database’s system tables.

Web Storage Schema

So, if each node in the hierarchical Web Storage is like a Relational Database Table, then where is the Schema stored? The Schema for each node is normally stored in a hidden child node usually named _schema.

Gosh Dang! Hold your horses! We were talking about relational tables in a hierarchical database. What the heck is the above picture? File Explorer? Yep, you can bet your boots! This is a good time to confuse you a little more!

File Explorer and the M: drive

Remember earlier I mentioned the similarity between the hierarchical database and the file system did not escape the Microsoft designers? Well, here’s how those varmints tied everything together and succeeded in confusing the daylights out of me.

The above File Explorer screen shot was taken from a computer running Windows 2000 Server and Exchange 2000. Since the Web Storage, by it very nature, is so hierarchical, the Microsoft designers decided to FAKE a hard drive (which automatically grabs drive M:) and show each TLH node as a Folder and each child node as folders. Then, to confuse matters even more, inside each node (or folder or table, or whatever the heck you wanna call them), they decided to show each database record as a crazy FILE!

So even though the above “looks” like a file system, IT IS NOT!

In reality, here is what you’re looking at is:

Now remember, this is a screen shot from a Windows 2000 Server running Exchange 2000. If you turn off the Exchange engine, the M: drive disappears!

I’ve never had the bravery to create an M: drive partition and THEN turn on Exchange 2000. I’m not sure what would happen, because Exchange 2000 automatically uses the M: drive. But it might be a fun thing to try late some night when everyone else is out of the office and I can get in my car and drive away if it goes, kaboom! J

So don’t get confused. Even though you can browse the Web Storage database using File Explorer always remember you’re looking at database tables and database records … not a file system!

Web Storage Schema & Columns and more Columns!

Sometimes I think that if the Microsoft Web Storage Designers decided to build a tractor, the tractor would end up being able to furrow corn, bail hay, fly to the moon, and make freaking coffee. Although the method used to define a column’s schema  is supremely flexible and powerful, that flexibility and power come at an extremely high learning cost.

All schema build-on and inherit other schema. No column can be created completely devoid of schema. All columns automatically inherit the BaseSchema. But what’s the BaseSchema? Well that seems to depend on whether you’re talking about Exchange 2000 version 1.0 or version 1.0 with service pack 1 or with service pack 2 or whether Portal Server is also installed, or whether it is raining outside and the price of chicken feed is above $1 a pound! If I seem frustrated, you’re right! Web Storage Schema is so complex it’s a joke.

But let’s see if old Farmer Fred can make it understandable.

 

 

Webstore is just a danged database!

Page 1 | Page 2


Disclaimer: Your use of the information contained in these pages is at your sole risk. All information on these pages is provided "as is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Stephen Bryant or Pro Exchange. OutlookExchange.Com, Stephen Bryant and Pro Exchange shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.

Copyright Stephen Bryant 2008