How ASP.NET Profile Properties are serialized in the database using Sql Profile Provider

I have been configuring an application, and something which I have never noticed struck me, and its only small but it gave me ideas and some critisms.  If you use the Sql Profile Provider, then you are no doubt defining properties inside the web.config file for example:

    <profile defaultProvider="ProfileProvider">
      <providers>
        <add name="ProfileProvider" connectionStringName="EmailSqlServer" applicationName="EmailApplicationServer" type="System.Web.Profile.SqlProfileProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
      </providers>
      <properties>
        <add allowAnonymous="false" name="ApplicationID" type="int"/>
        <add allowAnonymous="false" name="SmtpServer" type="string"/>
        <add allowAnonymous="false" name="Port" type="int"/>
        <add allowAnonymous="false" name="EmailUsername" type="string"/>
        <add allowAnonymous="false" name="Password" type="string" serializeAs="Binary"/>
      </properties>
    </profile>

Once this is done and you save this information against a user, it is then stored in the database.  It is this part which surprised me, in that I was simply unaware of its methodology.  To begin with you can serialize your properties in the following ways:

  • Binary
  • Xml
  • String
  • ProviderSpecific

Next the dbo.aspnet_Profile table in SQL has the following columns:

  • UserID
  • PropertyNames
  • PropertyValuesString
  • PropertyValuesBinary
  • LastUpdatedDate

So if we look at at PropertyNames in the database which corresponds to the above Web.Config section we see this:

SmtpServer:S:0:18:Port:S:18:2:Password:B:0:48:ApplicationID:S:20:1:EmailUsername:S:21:15:

Brilliant, so simple yet perfect.  Here we have the following sections, take SmtpServer for instance:

Property Name : SmtpServer

Property Type : string (S) <-- Or this could be the Serialize As Type

Property Start Index : 0

Property String Length : 18

This now corresponds to the next column in the database table, which is PropertyValuesString, which again for the above Web.Config section contains the following:

pop.abcdefgh.co.uk257abcdefghij-abcd

Just one long string, which given the first set of information, we can navigate very easily.  We have the Start Index of the string and the length.

 

Cheers,

 

Andrew

Published Tuesday, March 04, 2008 3:44 PM by REA_ANDREW
Filed under:

Comments

# re: How ASP.NET Profile Properties are serialized in the database using Sql Profile Provider

Tuesday, March 04, 2008 12:33 PM by rrobbins

I don't like how the profile information is stored. I think it is poor database design. You will be unable to query the profile information for a specific value using regular SQL.

# re: How ASP.NET Profile Properties are serialized in the database using Sql Profile Provider

Tuesday, March 04, 2008 1:01 PM by REA_ANDREW

I do agree, but on the other hand it is geared towards dynamic values.  You could argue that XML would be better suited.

Cheers

Andrew

# re: How ASP.NET Profile Properties are serialized in the database using Sql Profile Provider

Saturday, May 10, 2008 4:53 AM by Theme

How get a single value from PropertyValuesString via c# ?

# re: How ASP.NET Profile Properties are serialized in the database using Sql Profile Provider

Friday, May 16, 2008 11:58 AM by REA_ANDREW

Inside the property names we have three bits of info to use to identify the correct value. For example

Port:S:18:2

This is port.  It starts at position 18 and is 2 characters in length.

Cheers,

Andrew

# re: How ASP.NET Profile Properties are serialized in the database using Sql Profile Provider

Tuesday, April 12, 2011 5:33 AM by Gareth

Great info, thanks Andrew.  Just got me out of a fix in the early days of testing a new web project, we had put incomplete data in the PropertyNames column and this post gave me the fix

I agree though, it's not the best way to store data - 1 row per property with a composite PK on UserId and PropertyName (or a surrogate identity key) and a FK relationship with the Users table would be preferable

Anyway, sorry for dragging up an old post but wanted to convey my appreciation for sharing this knowledge.

Leave a Comment

(required) 
(required) 
(optional)
(required)